[jira] [Commented] (JCR-2608) Making Jackrabbit content repo usable from OSGi

["Jukka Zitting (JIRA)" <ji...@apache.org>]

    [ 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