JSR 170 Content Repository for Java Proposed Final Draft Out

Home

News: JSR 170 Content Repository for Java Proposed Final Draft Out

  1. After a period of incorporating all the excellent feedback that we received during public review and the usual bit of licensing discussions, I (JSR 170 Spec Lead) am happy to report on behalf of the JSR-170 Expert Group that the "Content Repository API for Java Technology" Specification has made the next important step towards its completion.

    The Proposed Final Draft of JSR-170 can be downloaded at:
    http://jcp.org/aboutJava/communityprocess/pfd/jsr170/index.html

    Many of today's (web) applications are interacting with a content repository in various ways. Every content repository vendor currently implements their own proprietary API. JSR-170 proposes a standard, implementation independent, API to access content bi-directionally on a granular level within a content repository. A Content Repository is a high-level information management system that is a superset of traditional data repositories. A content repository implements "content services" such as: advanced versioning, dealing with both structured and unstructured information, query & full-text searching, fine grained access control, event monitoring, etc. It is these "content services" that differentiate a Content Repository from a Data Repository.

    The JSR-170 Spec, TCK and RI will be licensed completely under "Apache Style Licenses".

    The next steps according to JCP 2.6 are to complete the "Reference Implementation" (RI) and the "Technology Compatibility Kit" (TCK) which are both under development in the Apache Jackrabbit project currently under incubation at:
    http://incubator.apache.org/jackrabbit/

    I would like to invite everybody to give us feedback with respect to inconsistencies or other deficiencies of the specification that come up during the implementation, or the development of the TCK, and send those to the expert-group:
    jsr-170-comments at jcp dot org

    Any feedback will be considered and is very welcome.

    During the completion of the TCK and RI we will publish specification updates containing minor fixes honouring public and EG-internal feedback.

    TSS kindly invited me to present JSR-170 at TSSJS, so i am looking forward to seeing as many of you as possible in Las Vegas.
    http://www.theserverside.com/symposium/schedule.html
  2. Congratulation David,

    That is almost the achievement of a great work that will see a new specification that will change a lot of things in the CMS market even if it is not a simple spec to grasp.

    The new draft is even better than the previous one and much more detailed (now it is 254 pages :) )

    This is the third specs (JSR and Oasis) we implement (at eXo Platform) and I have to say the quality of the writing is by far the best, you could almost publish it...and I don't speak of the content but the NodeType feature is by far my favorite...

    So once again congratulation and good luck to you and Stefan for the TCK and RI end of implementation now.

    Cheers
  3. Great stuff. But such a slow mover! Why does it have to take such a long time to get it over with... I lost quite some resources a year ago by gambling on 170 too early :|
  4. Congratulations from the Magnolia[1] team, David! We have been building the Magnolia CMS following the specs changes for 2 years now, and the fact that our rewriting is finally coming to an end is very welcome!

    I think it is fantastic that the spec, RI & TCK will be available ander an Apache style license - this will make a wide adoption even more likely, which is essential to bring the major benefits that JCR has the potential to deliver.

    For those that are at LOTS[2] this week come and meet us at the Magnolia booth and meet the first open source Content Management system *based* on JCR (or simply download from [1])

    [1] http://www.magnolia.info
    [2] http://www.lots.ch


    Regards
    Boris Kraft
  5. I've played for a little while with Apache JCR implementation and found it to be quite useful: as opposed to plain relational persistence not to say JDBC, to drive content-oriented websites, as well as wiki-like knowledge sharing systems and other intranet apps.

    It seems like in the nearest future it could be faster and indeed more flexible to use one or another JCR implementation together with some templating engine (like Velocity/WebMacro/...) at frontend (where you need it fast/cached/webspider-indexable) and something like Tapestry/JSF at backend (where you need a lot of forms and widgets but performance/indexability is not an issue), rather than use full-fledged content management system where you often end up doing quasi-programming in a nasty mouse-clicking manner (no offence, though) and there's no easy way to add your own Java code.

    A little thing which is in my view still missing from JCR implementation is the ability to 're-join' detached Node to Session again, like Session.lock() method in Hibernate. I was forced to do something like
    Node newNode = session.getItem(oldNode.getPath());
    which sort of works but is in my view sort of ugly.

    (I'm not sure this is correct place to propose changes to JCR spec, but I'll try here first)
  6. I've played for a little while with Apache JCR implementation and found it to be quite useful: as opposed to plain relational persistence not to say JDBC ..., rather than use full-fledged content management system where you often end up doing quasi-programming in a nasty mouse-clicking manner (no offence, though) and there's no easy way to add your own Java code.
    That sounds quite interesting.
    As an addition to that approach you could still have
    a jcr-based CMS Application running on top of the jsr-170 compliant repository, that allows your users to have all the gui-gimmicks, workflows, ... they want, without sacrificing the clear and simple architecure.
    A little thing which is in my view still missing from JCR implementation is the ability to 're-join' detached Node to Session again, like Session.lock() method in Hibernate. I was forced to do something like Node newNode = session.getItem(oldNode.getPath());which sort of works but is in my view sort of ugly.(I'm not sure this is correct place to propose changes to JCR spec, but I'll try here first)
    The right place would be jsr-170-comments at jcp dot org for comments about the spec. With the current progress it may be easier to convince the jackrabbit community of the usefulness of a feature and as a result of that establish a good usecase for jsr-170 v1.1.

    Anyhow, how did your oldNode get detached from the content repository in the first place?
  7. Anyhow, how did your oldNode get detached from the content repository in the first place?

    For example, when the list of child nodes for a given node was retrieved and then shown in web page. The session is closed, but child nodes are still alive (as an attribute within Tapestry page).
    Then, click, I'd like to go further deep with children of one of child nodes. At this moment I'd like to be able to re-join that node to new repository session, synchronising its state if necessary. And if it's stale to the point that repository doesn't know anything about it, I'm ready to deal with exception :)
  8. Anyhow, how did your oldNode get detached from the content repository in the first place?
    For example, when the list of child nodes for a given node was retrieved and then shown in web page. The session is closed, but child nodes are still alive (as an attribute within Tapestry page).Then, click, I'd like to go further deep with children of one of child nodes. At this moment I'd like to be able to re-join that node to new repository session, synchronising its state if necessary. And if it's stale to the point that repository doesn't know anything about it, I'm ready to deal with exception :)

    keeping references to Node and Property instances is not recommended as they, by design, cannot be disconnected
    from their Session.

    for example you wouldn't expect a java.sql.Resultset
    object to re-join a new connection after you closed the
    old connection.

    instead of storing Node & Property references you
    should store paths or values.
  9. I could argue a little bit :)

    I wouldn't say that the comparison between Nodes/Properties and a ResultSet is reasonable.

    ResultSet in JDBC is much like a NodeIterator in JCR, and, yes, it has little sense to keep it apart from its session.

    But Nodes and Properties (Items), on the other hand, have no direct equivalent in JDBC, for they are representations of persistent entities. If there's an Item, it corresponds 1:1 to an entity in persistence storage. Items are just like Entity Beans or Hibernate persistence-aware objects.

    So I don't see why don't you want to use Items all over your application, eventually synchronizing (reloading) them when necessary.

    Or do I probably not understand the paradigm of Session? What is it lifecycle - just like that of JDBC Connection? For a web application, should I keep my Session open all the way? or just open/close it per page request?
    If the latter, then I definitely would need to use Items beyond the Session that has created them.