jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-2608) Making Jackrabbit content repo usable from OSGi
Date Tue, 05 Apr 2011 17:36:05 GMT

    [ https://issues.apache.org/jira/browse/JCR-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016031#comment-13016031

Jukka Zitting commented on JCR-2608:

I've now moved the draft repository bundle from the sandbox into Jackrabbit trunk. This jackrabbit-bundle
component is roughly equivalent to the webapp, JCA and standalone deployment packagings we
already have. In other words it simply takes all our existing components like core, spi, etc.
and packages them into one big bundle that can be easily deployed to an OSGi container.

Currently the bundle just needs the JCR and a few logging APIs as dependencies and basically
just runs out of the box when deployed together with those dependencies. There's also a simple
integration test in test/jackrabbit-bundle-it that verifies that the repository gets correctly
started and exposed as a service in those circumstances.

Some things still need to be worked on:

1. The bundle currently embeds and exports the Jackrabbit API extensions. Not sure if it would
be better to have the API as a separate bundle that the repository bundle just depends on.
That might be a bit troublesome as generally the API needs to match the version of the repository.

2. The bundle currently depends both on the slf4j and commons-logging APIs for logging. That
shouldn't be a problem as AFAIUI most OSGi logging services provide bindings for both those
APIs. Alternatively we could also embed jcl-over-slf4j inside the repository bundle so that
only the slf4j API would be imported from outside.

3. There is currently no configuration for the kind of repository that the bundle starts when
activated. It would be nice if you could configure zero or more repository URLs and the bundle
would automatically make those repositories available as services.

4. The current bundle packaging contains tika-core but none of the Tika parsers. I was thinking
of removing also tika-core from the bundle and instead adding a mandatory dependency to the
Tika API as exposed by the similar Tika bundle package.

5. No extension points or other OSGi modularity is currently supported by this bundle. We'll
probably want to add those as the need arises, ideally in a way that doesn't require adding
OSGi dependencies to jackrabbit-core or other components.

> Making Jackrabbit content repo usable from OSGi
> -----------------------------------------------
>                 Key: JCR-2608
>                 URL: https://issues.apache.org/jira/browse/JCR-2608
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-spi-commons
>    Affects Versions: 1.6.1
>         Environment: Ubuntu 10.04, 64-bit, Fuse 4.2 (Equinox-based ServiceMix)
>            Reporter: Samuel Cox
>            Priority: Minor
> I have been using home-grown, Jackrabbit OSGi bundles for the past year in Fuse 4.0 (Felix
based).  For the most part, I put everything in an uber-bundle represented by jackrabbit-core.
 However, the service lookup process used in jackrabbit-spi-commons (META-INF/services) started
failing when we moved to Fuse 4.2 (Equinox based).  I have not had time to try your new 2.0
bundles.  Also, I realize this is probably an OSGi-SMX problem as opposed to yours.  I just
thought I'd let you know because it looks like you're making an effort to provide bundles.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message