[jira] [Commented] (JCR-3420) Improving Jackrabbit integration within OSGi and other managed environment

["Chetan Mehrotra (JIRA)" <ji...@apache.org>]

    [ 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 implementation. 

--
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