jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chetan Mehrotra (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3420) Improving Jackrabbit integration within OSGi and other managed environment
Date Thu, 06 Sep 2012 11:37:09 GMT

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

Chetan Mehrotra commented on JCR-3420:

Couple of points around the implementation

1. Introducing new attribute 'factoryType' - In order to allow the BeanFactory implementation
to decide whether a particular class instance should be created directly or should be obtained
through other mechanism (from OSGi ServiceRegistry, Spring BeanFactory) I require a marker
attribute. Hence introduced this attribute. It acts as a hint to BeanFactory. Its default
value is 'simple'. Now one impl like OSGiBeanFactory would check if the value of this attribute
is 'osgi' then it would obtain the impl from OSGi SR otherwise it would create it via SimpleBeanFactory

2. BeanConfigVisitor - This interface is currently not used in the poc. I was working on another
OSGiBeanFactory implementation where the factory can determine in advance that what all service
dependencies are involved. Based on that it would wait for all such services to be available
and after that only it would create the Repository. So BeanConfigVistor would be used in parsing
phase to collect such information. This would take some time ... would publish the change
once it gets done.

3. Backward Compatibility - The config change logic ensures backward compatibility. If the
new attribute is not present its value is considered to be 'simple'.

4. BeanConfig creation - The custom BeanFactory instance is being inject in o.a.j.core.config.ConfigurationParser#parseBeanConfig.
However there are couple of places (1 so far) where BeanConfig is created directly like in
o.a.j.core.config.RepositoryConfigurationParser#getQueryHandlerFactory. This would need to
be seen

5. Direct Instance Creation - Most of the places the instances are being created via BeanConfig.newInstance
method. However there some places where Class.forName is directly used (16 total). Such cases
would be missed by BeanFactory logic. Out of that majority are around Lucene logic which I
think is managed  separately through different config. Some of the other cases might need
to be refactored tto use BeanFactory if possible
> Improving Jackrabbit integration within OSGi and other managed environment
> --------------------------------------------------------------------------
>                 Key: JCR-3420
>                 URL: https://issues.apache.org/jira/browse/JCR-3420
>             Project: Jackrabbit Content Repository
>          Issue Type: New Feature
>          Components: config, jackrabbit-core
>    Affects Versions: 2.5.1
>            Reporter: Michael Dürig
>         Attachments: JCR-3420-osgi-factory.patch
> While using jackrabbit in managed environment like Sling, Spring etc
> its easy for other components to access the Repository service.
> However its tricky to use managed components of those env within
> Jackrabbit as it creates the instances on its own. To simplify such
> integration it would be helpful if JR exposes a factory service which
> is used to create the various beans from the JR configuration.
> See http://markmail.org/message/johbo2dnepwtjogm for Chetan's initial proposal and POC

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message