Hi, I think the best way for you would be to embed the classes in question in your bundle - we do this in some occasions as well.
I think we should not make the implemntations publically available or add any other mechanism. Regards Carsten Markus Joschko wrote > Hi, > > we have to implement two slightly opposing sets of requirements: > > 1a) Create notification e-mails with links to resources > 1b) Allow external systems to store references to resources and to > retrieve resource data through that reference at a later date > > and > > 2) Moving resources within the tree based on business processes > > By moving a resource, the path would naturally change, which would > render any e-mail URL or external reference useless. For this reason, > it would be desirable to be able to use the node's UUID or, in cases > where the node was created by an external system, an immutable > property of the node which contains an externally created Id. Any URL > or reference based on this information would therefore remain valid > regardless of where the node is in the tree. > > Our proposed solution is to implement a new ResourceProvider, mounted > in the virtual tree (under /uuid for example), which would process > URLs such as /uuid/e07a566f-9099-4859-bcdb-aadf76275bf2.tidy.json and > invoke the javax.jcr.Session.getItem method with [<uuid>] (e.g. > [e07a566f-9099-4859-bcdb-aadf76275bf2]) as the argument. > > This works and it is possible to retrieve a JCR node with this > implemention. However, it is not currently possible to reuse > JcrNodeResource, as this class is a package private class in a private > package (bundle: org.apache.sling.jcr.resource). We do not wish to > implement our own JcrNodeResource. > > Would it be possible to make these classes (namely JcrItemResource, > JcrPropertyResource and JcrNodeResource) available to other bundles, > either directly or through a public factory class? > > Thanks in advance > -- Carsten Ziegeler [email protected]
