Discussions

News: ObjectWeb prepares eXo JCR 1.0 RC1, a JCR implementation

  1. The eXo Platform team is happy to announce the release of eXo JCR 1.0 RC1, an Open Source implementation of the Java Content Repository (JCR).

    This implementation is based on the final draft 2 of the JCR specification.

    This release candidate contains all the mandatory features required by the specification for level 1 and level 2 JCR implementation, and includes several optional and implementation-specific features such as:
    • session supporting, JAAS based user login
    • retrieval and traversal of nodes and properties
    • adding and removing nodes and properties
    • writing the values of properties
    • transient and persistent namespace discovering and changes
    • export to XML
    • import from XML
    • assigning node types to nodes
    • XPath querying
    • multiple workspaces and node references
    • node same name sibling
    • observation
    • repositories, workspaces, namespaces and node types management facility
    • simple API for Workspace's data storage pluggability
    The distribution contains a WAR file and all the libraries needed to run the JCR in a servlet environment as well as standalone. The implementation back end is made on top of any popular database such as Oracle, MySQL, or DB2. (HSQLDB is embedded by default).

    The implementation back end is made on top of any popular database such as Oracle, MySQL, DB2...(hsqldb is embeded by default).

    This implementation is based on the current final draft of JSR-170, and will go final after adding the optional features of JSR-170 and passing the compatibility tests.
  2. interesting work, it's good to get a db-backed implementation because the jack-rabbit (JR) implementation doesn't strike me a very sensible solution. a db implementation would make magnolia a more viable option as a cms, i don't think it is currently because of the weakness of JR.
  3. This implementation has been distributed as a standalone product but is also included in the whole eXo Portal and CMS product.

    Actually it is bundled in the eXo Platform 1.1 (currently in development but the src are available on the ObjectWeb subversion site) and will provide the basis for our new CMS product (integrated in the portal). Stay tuned...
  4. interesting work, it's good to get a db-backed implementation because the jack-rabbit (JR) implementation doesn't strike me a very sensible solution. a db implementation would make magnolia a more viable option as a cms, i don't think it is currently because of the weakness of JR.
    Jackrabbit does have a hibernate persistance manager (the orm-persistence contrib). It might not be top-notch at the moment though (the author is buzy with some other stuff).

    So what will be the main differences between this eXo JCR and Jackrabbit? The license?
  5. So what will be the main differences between this eXo JCR and Jackrabbit? The license?

    Our implementation is based on our IoC service architecture and leverages some of the existing service of the eXo platform such as:
    * the indexing service (based on lucene search engine) that is mount on top of the specification,
    * the organization service (which allows a simple swap from database store for the users or an LDAP implementation),
    * the security service (JAAS management when embeded in an application server),
    * the remote service (for the clusterable cache),
    * the backup service (for backup of the organization model, aka users and groups)...

    The license is also not the same as we are GPL and our company (eXo Platform SARL) will provide a dual license for ISV and OEM as well as service and support.

    Finally, as a comment I would say that the more implementation we have (Open Source or not) the faster the specification will be adopted. Competition is always good if it is a fair one and in that case it is the case (I wish all our competitors were as nice guys as David Nuescheler (Spec Lead, Day Software, Inc.) is.
  6. We Magnolians for one are happy to have another player on the field - thats what standards are all about. Not only will it be possible to use the exo-jcr implementation as an alternative to Jackrabbit (Apache) and Magnolia Power Pack (proprietary + support + maintainance), but also it should be straightforward to access content of other systems (in that case, access Magnolia content from exo and vise versa) easily.

    Congrats to the exo team!

    Boris Kraft
    http://www.magnolia.info
  7. Indeed Boris, the switch should be quite simple especially that the lookup relies on JNDI.

    Here is the code to get the JCR Session:

      InitialContext jndiContext = new InitialContext();
      Repository repository = (Repository)jndiContext.lookup("db1");

      Credentials credentials = new SimpleCredentials("exo", "exo".toCharArray());
      Session jcrSession = repository.login(credentials, "ws");

    You can also use the IoC lookup but that way is totally independant of eXo classes. For sure there will be some configuration work but not too much.
  8. hi benjamin,

    my late but nevertheless very sincere congratulations.

    i appreciate all the effort that you guys put
    into making this happen.
    i would also like to hear what application vendors say
    about compatibility between the exo repository
    and jackrabbit. i think we could even make sure that
    the two are compatible beyond the spec (let's say
    around things like access control, nodetype creation
    etc..)

    again, thanks and two thumbs up.

    regards,
    david
  9. To me it makes no sense to offer an jcr-src download which doesn't contain the jcr services and other dependencies. Yes I read the README... And it is just inconvenient to hunt through the code and find out which dependencies you need from the platform. Don't put everything in the platform! Small modules which you can use or not would be better...
  10. Hi Mickael

    We though that the maven project.xml dependencies or the WAR/WEB-INF/lib would be easy enough to find the sources in the platform but seems we were wrong, sorry for that.

    For the next RC we will extract the te src directories that are just needed for the JCR build and not the other part of the platform.

    Btw we now have a maven repository at ObjectWeb http://maven.objectweb.org if you want to build and install just the servlet war with your modification and not the platform.

    Thx for the feedback
  11. Java Content Repositories are mostly used (or to be used) in CMS applications. But I'm wondering whether we could use it for prototyping small applications. It wouldn't probably scale well for big webapps, but it'd be interesting to see if JCR's API could be used as a lightweight persitence framework.

    I'm looking forward to play with this promising JCR implementation! Thanks to the eXo team!
  12. Hey Guillaume

    Just as a sidenote, the JCR is built on top of the service container kernel which allows you to register Groovy objects in the container.

    For example you could implement, in Groovy, a Listener object as defined in the JSR 170 specification (Observation chapter) and send an email to the administrator of the site each time a node is added. Of course as this is written in Groovy you will not need to build if you modify the code (well I know it is a trivial example :-) )
  13. WebDAV access to JCR[ Go to top ]

    Does it make sense for eXo JCR to provide WebDAV interface to the repository?
  14. WebDAV access to JCR[ Go to top ]

    Yes it makes a lot of sense. It is on our TODO list for an upcoming release but the work for that has not started yet and will only when the other functionnalities of the spec are implemented unless someone wants to contribute :)
  15. WebDAV access to JCR[ Go to top ]

    there are at least two generic webdav layers on top of jsr-170 as part of jackrabbit.
    happy hunting in svn ;)

    regards,
    david