Discussions

News: Content Repository API (JSR-170) posts Final Draft

  1. The expert group of JSR-170, the Java Content Repository (JCR), has posted their Final Draft of the specification. JCR specifies "content services" such as: author based versioning, full textual searching, fine grained access control, content categorization and content event monitoring. As such, this could be how enterprise applications are recommended to manage raw content.

    Changes to the specification itself were fairly minor, but as this is a Final Draft, this could be considered the finishing touches for JCR.

    The specification includes sourcecode for javax.jcr.*, as well as javadoc and the specification itself.

    Jackrabbit, an open source implementation of the Content Repository, in available via the Apache Incubator project.

    Threaded Messages (11)

  2. I have a few questions on JSR-170 and not sure where I should ask. I did not see a feedback link on JCP web page. So I post my question to TSS. Hope some one could help me with some answers.

    JSR-170 offers a very generic object model that capture all types objects.

    1) My first question is related to this generic vs. concret model. As we know, the more general and abstract the model is, the more object types and cases it can cover; but at the same time, it usually become less efficient than the concret model that address the specific needs. With such a generic repository model, is JSR-170 going to performan adequtely in the real-world application ? are there to many bagage to carry for each node with it's node types and properties ?

    2) Unless I totally mis-understood this and please correct me if I did, IMHO JSR-170's API is heavily lean to hierachical repository storage and weigh a bit too much on XML syntax. This causes API to be less generic and have some artificial restrictions. I think the API should be agonostic of the underline technology and repository type. But the current specification (even though tried) but still very much leaning to a hiearchical repository and XML implementation. Is JSR-170 trying to cover too much here ?

    For example,

    public Node addNode(String relPath) throws ItemExistsException, PathNotFoundException, VersionException, ConstraintViolationException, LockException, RepositoryException;

    ItemExistsException:
     If an item at the specified path already exists
     (and same-name siblings are not allowed).
    PathNotFoundException:
    If the specified path implies intermediary nodes that do not exist.
    RepositoryException:
    If the last element of relPathhas an index or if another error occurs.

    Since addNode requires a path, the AddNode() method have to throw above mentioned exceptions. Many of them are artifact of this API requries a hierachical repository and relative path rather than the real requirements of the respository.

    For example, if the repository is not implemented as hiearchical, ie. it is flat respoitory and items are all identified by UUIDs.

    addNode() should be simply means assign a node (Asset representing .jpg file) to another Node (representing a folder Structure), and the child of the Folder Node is another node referring Asset node or the same Asset Node has an reference pointer.

    In this case, weather the ItemExistsException is thrown should depend on repository policy or option that weather repository's should implement same item checking.

    And the weather two items are the same or not should not depending on the name. As matter of fact, it is very important to allow same name items to be in the same folder.
    This could cause a lot of pain for user if we have the non-same-name restriction. For instance, if user 1 does not have read permission on Document doc1.doc owned by user 2. User1 then can't see doc1.doc. He will think that there is no doc1.doc in the given folder. But when he tries to add doc1.doc into the folder, the ItemExistsException will be thrown.

    The only system would same-name restriction is WebDAV.

    JSR-170 should cover this case, but should not make the rare case (WebDAV, in my opinion) to be used in general case.

    PathNotFoundException:
    If the specified path implies intermediary nodes that do not exist.

    In flat repository, assign Asset node to Folder does not matter if the intermidiary nodes exists or not.

    RepositoryException:
    If the last element of relPathhas an index or if another error occurs.

    Similarly here, assign asset to an folder should be an user action to organize data, it should not throw repository exception.


    Assign Asset to folder with AddNode() could simply be

    addNode(String uuid, int index, Map options) throws ItemNotFoundException, DuplicateNameException

    Where ItemNodeFoundException is thrown when uuid is invalid uuid and can't locate valid item;
    DuplicateNameException is only thrown then the option in repository or options argument specifies that name must be the same.

    3) The example in database implementation is also a bit worrysome to me. Here the properties such as DATE, TEXT etc. are implemented as tables. Since the properties are usually are type of metadata. If they are implemented as Table then means that once they are created, they are unlikely to change (Unless one implements alter table). This is not so nice to end user: you define a metadata type, make a mistake, you can't change it. you have to delete it (drop the table) and re do it. If the metadata type already associated with items, then .....


    I am still digesting the JSR-170, so my questions/comments could be off the mark due to my ignorance. Please correct me if I am wrong. Thanks.


    Chester
  3. Feedback on JSR-170[ Go to top ]

    To send feedback to the JSR, from the JSR page:
    Please direct comments on this JSR to: jsr-170-comments at jcp dot org
  4. Feedback on JSR-170[ Go to top ]

    I somehow missed that. Thanks. I will email to them directly.

    Chester
  5. For example, public Node addNode(String relPath) throws ItemExistsException, PathNotFoundException, VersionException, ConstraintViolationException, LockException, RepositoryException;ItemExistsException

    ...

    Assign Asset to folder with AddNode() could simply be:

    addNode(String uuid, int index, Map options) throws ItemNotFoundException, DuplicateNameException

    I don't even need to see the spec to see there are problems with your interpretation. Your suggested replacement isnt' at all general. Have you designed or used an SPI interface, ever?

    This is like InputStream shouldn't throw IOException because you want to use ByteArrayInputStream.

    Implementations of an interface cannot add [checked] exceptions, but need NOT ever throw (or declare) all the ones declared by the interface.

    Thus an SPI must declare a set of exceptions that is sufficient for all resonable implemetations - a rule of thumb is that you should have a seperate exception for every case that the client code could resonably distinguish.

    The whole concept of a Service Provider Interface is that the implemetation is interchangeable, so declaring all exceptions is perfectly resonable. If you want to be tied down to only one implementation you can usually use the implementation class, which will only declare those exceptions it uses. Or better, if you know you will never get an exception just trivially catch it:

     catch(NeverHappensException e){ log.error("This shouldn't have happend", e);}
  6. This is like InputStream shouldn't throw IOException because you want to use ByteArrayInputStream.

    No, more like "InputStream shouldn't throw FileNotFoundException because you want to use ByteArrayInputStream." Have *you* designed or used an SPI interface, ever? :-)

    It seems to me that Chester's complaint is just that the "Content Repository API" is more of a "Hierarchical Content Repository API", when he would want to use a non-hierarchical repository implementation. With java.io, there's a whole variety of sub-exceptions of IOException used by different implementations; FileNotFoundException for the FileInputStream, java.net.NoRouteToHostException for SocketInputStreams, etc. So if PathNotFoundException was likewise a subclass of RepositoryException, say, it wouldn't need to be declared explicitly on the addNode method, but could still be used by a hierarchical implementation in order to provide additional information about the problem. Whether or not the JSR should cater for non-hierarchical repositories is, of course, up to the expert group...
  7. This is like InputStream shouldn't throw IOException because you want to use ByteArrayInputStream.
    No, more like "InputStream shouldn't throw FileNotFoundException because you want to use ByteArrayInputStream." Have *you* designed or used an SPI interface, ever? :-)It seems to me that Chester's complaint is just that the "Content Repository API" is more of a "Hierarchical Content Repository API", when he would want to use a non-hierarchical repository implementation.
    But the original comment clearly wanted a non-hierachical only API - like I said providers don't have to use all the exceptions. I so nearly put in a paragraph about exception subclass hierachies, but the post was long enough as it was. In the case of IO the IOExceptions are sensibly grouped - all are closely related in nature. In the post I was responding to a number of exceptions that where obviously not related in this way were eliminated (grouped?).
    And the generic RepositoryException was used in the original and OMITTED from the suggested replacement.
    Class hierachies should be based on real relationships, not line lengths - one fundamental distinction lost in the reductions discussed is that beween exceptions where retry is a vaid responce and those where it isn't.

    That said, I will admit that DuplicateName exception is a better name ItemExistsException in this context.
  8. slide[ Go to top ]

    I'm looking forward to see a jsr-170 compatible slide client!
  9. what's the relations[ Go to top ]

    what's the relations between jsr-170 and WebDAV
  10. what's the relations[ Go to top ]

    A content repository can have many different client applications: such as a web client, a java desktop client or WebDAV client. Of course, the WebDAV server side need to be implemented to access the content repository. As several applications such as Windows Explorer, Adobe Product already implemented the WebDAV client, user, theoretically, can directly browse the content repository from their desktop or their favoirate applications. In reality, the picture is not so rosy. As not all applications follow the WebDAV spec closely and try to get all the WebDAV clients to work is really not easy.

    Chester
  11. Is there one?
  12. Minor correction, it is the:
    "Proposed Final Draft 2"

    Submission for final approval ballot is not very far out anymore.

    regards,
    david