Hi Juanjo,

Juan José Vázquez Delgado schrieb:
> On the other hand, I think any bundle is exporting jcr packages, really?.
> This coulf be a problem if you want to have a login module and access
> manager in their own bundle. Is this true?

This is really a big problem: It is currently rather problematic to use
Jackrabbit in an OSGi environment .. and it took me quite a while to
understand, that the jcr/jackrabbit-server bundle must not export
anything :-(

On the other hand, the jcr/jackrabbit-server bundle has a

  DynamicImport-Package: *

header, which allows it to import just about everything which is
exported elsewhere, dynamically and on-demand.

This means, you could create a bundle, which exports for example your
LoginModule and the jcr/jackrabbit-server bundle could pick it up.

It gets more complicated with providing a PersistenceManager, because
there is no proper API for that, the respective interfaces and abstract
classes are intermixed with implementation classes. Thus exporting the
required packages is simply not possible.

Maybe we could make a case of this and raise the issue again in
Jackrabbit to finally get to a solution.

And finally: Jackrabbit setup is static. Jackrabbit is not prepared to
implementations going away (or being updated) at runtime. This makes
hooking in PersistenceManagers or LoginModules even more problematic.
Again, we might raise a case in Jackrabbit and try to convince them
about the issues.

Alternatively, you may create your own jackrabbit-server bundle
including your special PersistenceManager (or whatever it is). But I
agree, this is not the best of all solutions.

Regards
Felix

Reply via email to