我正在构建一个基于JSF-Spring-Hibernate的应用程序，它需要将内容存储为pdf、MS-Office文件等。我正在考虑为它提供JCR功能，添加Jackrabbit或Modeshape，但是我仍然有一些疑问。
实际上，我们将内容作为原始文件存储在文件系统中，并将引用添加到MySql数据库中。DB表还保存有关修改、版本等的信息。这样做可以很容易地检索每个组、每个用户等上传文件的数据。使用JCR API是否如此直接？此外，是否有可能保持文件在文件系统中的原样，并将元数据信息存储到MySQL中，就像我们实际使用JCR一样？
created by-updated by字段实际上存储在DB表中，并引用我的应用程序中的系统用户，但是JCR实现似乎有自己的身份验证系统。我想这里的方法是在JCR实现中创建一个新用户，系统的每个用户都创建了？密码更新怎么办？建议将用户系统密码与存储库中的密码保持同步吗？还是应该对存储库中的每个用户使用相同的密码就足够了？
我们经常用多种语言处理相同的文档。在这种情况下，文档版本相同，但文件之间的语言不同。我已经看到规范中有一个jcr:language属性，可以用它吗？
我可以看到的另一个可能的问题是，例如，我们目前没有控制组名中的名称重复。可能有两个相等的组名，要将它们的目录区别到文件系统中，我们将使用它们的DB id附加到目录路径中的名称。我不知道这是否真的是一个最佳实践，我们如何通过JCR实现来管理它。。。
PD:我的servlet容器是Tomcat6。
集思广益！
最佳答案
您已经声明，您已经依赖Hibernate和MySQL来存储大部分数据并将文件存储在文件系统上。你希望JCR能带来什么？Hibernate、MySQL和/或文件系统有哪些不足之处？您当前的体系结构是否难以扩展或群集？你在写同一个文件时有并发问题吗？你的实体类有限制吗你是一个层次结构的实体吗，因为Hibernate和关系数据库通常很难做到这一点？
一定有一些原因让您考虑改变当前的体系结构，以添加全新的数据存储技术。
假设您只想将文件内容存储在JCR存储库中，而不是文件系统中。是的，这是可行的，它可能会简化您的应用程序一点，使它更容易与更少的代码。但是，这种好处是否值得在应用程序中添加JCR实现的复杂性呢？（只有你才能回答。）
或者你也在考虑使用JCR而不是Hibernate。有些人发现这很难想象，但在某些情况下（尤其是当您的实体大多是类似于映射的数据结构时），JCR实际上可以比Hibernate更干净地存储信息。
将数据存储在JCR中意味着每个“实体”都由一个节点和属性（可能还有更复杂实体的子节点）表示，并且这些实体将存储在层次结构中。您可以在使用泛型节点类型（如nt:unstructured）时执行所有这些操作，也可以选择为每种实体类型定义节点类型。使用MIXIN类型和剩余属性定义，您甚至可以允许单个类型实体的节点在它们所持有的信息种类上有所不同：所有的客户节点可能包含客户ID、名字、姓氏和其他一些信息，但一些客户有附加信息（成员ID、成员身份、等等），您只需要添加到适当的客户节点。随着您的需求随着时间的推移而变化，存储在节点上的数据可以很容易地随它发展，有时甚至不必修改节点类型（顺便说一句，这可以在不重新启动应用程序的情况下动态完成，或者如果您提前计划，而不需要更改应用程序代码）。
简而言之，使用JCR作为数据库为您提供了巨大的灵活性，甚至在您的应用程序被开发之后。它使您不必为数据实体定义具有固定字段的显式类，并且允许您的应用程序更关心哪些信息适合于特定实体实例。
总之，仅仅使用JCR来存储文件可能是过分了——听起来您已经有了存储文件元数据的实体。按照您描述体系结构的方式，您不会真正受益于JCR的任何最佳特性。这使我认为JCR根本不适合您当前的体系结构—您似乎已经自己实现了大部分功能。
关于java - 将JCR集成到我的应用程序中，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/20899099/