[
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
