jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Sling's use of Jackrabbit
Date Mon, 30 Nov 2009 09:02:45 GMT

Guo Du schrieb:
> On Sat, Nov 28, 2009 at 6:22 PM, Felix Meschberger <fmeschbe@gmail.com> wrote:
>> That's what we currently do in the Sling embedded repository bundle [1]
> Hi Felix,
> Thanks for the reply during weekend:)
> I saw all dependencies jars are embedded to jackrabbit-server bunlde.

Yes, this was for simplicity and "speed". I am currently trying to
migrate the jackrabbit-server bundle to Jackrabbit 2 (beta3) and went a
different route:

   * I moved the derby library out thus leveraging Derby as a bundle
   * As of Jackrabbit 2 Tika is used for text extraction (and other
     tasks). Tika already comes partially bundleized and I am working
     on a patch to create a "Tika Full" bundle.

This leaves just xerces and lucene (and a few smaller libraries) inside
the jackrabbit-bundle. Lucene is ok, because Jackrabbit IIRC is closes
knitted with Lucene. And Xerces, well, this is a nasty beast which can
probably not easily be turned into a bundle, not to speak of versioning

I will post some information on my progress to the Sling wiki shortly.

> Bundle-ClassPath: .,jackrabbit-jcr-rmi-1.4.1.jar,jackrabbit-core-1.6.0
>  .jar,jackrabbit-jcr-commons-1.6.0.jar,jackrabbit-spi-commons-1.6.0.ja
>  r,jackrabbit-spi-1.6.0.jar,lucene-core-2.4.1.jar,derby-,c
>  oncurrent-1.3.4.jar,jackrabbit-text-extractors-1.6.0.jar,pdfbox-0.7.3
>  .jar,jempbox-0.2.0.jar,fontbox-0.1.0.jar,poi-3.2-FINAL.jar,poi-scratc
>  hpad-3.2-FINAL.jar,nekohtml-1.9.7.jar,xercesImpl-2.8.1.jar
> This is a good workaround for libs which isn't OSGified, I did the
> similar way by generate jar file contain all none OSGfied classes.
>           <instructions>
>             <DynamicImport-Package>*</DynamicImport-Package>
>             <Export-Package>foo.bar.jcr*</Export-Package>
>             <Private-Package>
>                 org.apache.jackrabbit*,
>                 org.apache.derby*,
>                 org.apache.tika*,
>                 org.apache.lucene*,
>                 org.apache.commons.io*,
>                 org.apache.commons.pool*,
>                 org.apache.commons.collections*,
>                 org.apache.xerces*,
>                 org.pdfbox*,
>                 org.textmining*,
>                 EDU*,
>                 META-INF.services*
>             </Private-Package>
>             <Import-Package>
>               javax.jcr*;version="[2.0,3.0)",
>               org.apache.derby.jdbc;resolution:=optional,
>               com.mysql.jdbc;resolution:=optional,
>               *;resolution:=optional
>             </Import-Package>
>           </instructions>
> But I have to say that it's not a beautiful way to work in OSGi
> environment. We should use proper OSGi header for all jackrabbit jars
> for long run. Eventually, all dependencies could be provided by OSGi.
> In short term, there could be a bundle to provide all none OSGified
> packages, in sling case, it could be at jackrabbit-server bundle.

Agreed. See above.

> The repository management is key part of jcr based solutions, so I
> expect most of users will do something configuration/coding to meet
> their special operation requirement. So embedded private jackrabbit
> packages leave little space to do that.
> What problem can you see to just add OSGi headers in jackrabbit
> project? By this way, I didn't see any reason for users to repackage
> jackrabbit for OSGi deployment.

We have done that for a few projects already: Jackrabbit API, Jackrabbit
JCR Commons, Jackrabbit JCR RMI. For others it is not that easy, and
Jackrabbit Core is one of those.

The problem of Jackrabbit Core is, that apart from implementing the
Jackrabbit API (which is imported in the bundle), it has its internal
API (for example the PersistenceManager interface or others). This
internal API is not properly separated (in terms of Java Packages) from
implementation classes, which should not leak into the exported package

So what we have done in Sling is define additional API, which may be
used as service interfaces and which is bridged into the Repository.
This also allows for some configuration flexibility.

One of the major issues still remaining is providing persistence
managers as OSGi bundles. The only feasible, yet not very clean
approach, would be to use fragment bundles.

Anyway, this is also fragile, because the Jackrabbit core implementation
is not currently built to support dynamic arrival and departure of
persistence managers ... A solution here would probably also be to
provide some bridging.


View raw message