[
https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449857#comment-13449857
]
Chetan Mehrotra edited comment on JCR-3420 at 9/7/12 4:53 AM:
--------------------------------------------------------------
>>Otherwise, 'factoryClass' instead of 'factoryType' might be an option. That
>>way there is no need to invent additional "type names" for the factory.
I am fine with that. See next note below on why such an attribute is required
>> 2. We should maybe leave this out of the initial patch until it is used.
As noted in previous comment I have updated the implementation to use visitor
class. Have a look at DepFinderBeanConfigVisitor at [1]. This factory
(OsgiBeanFactory) is a generic implementation compared to previous one which
was aware about AuthorizableAction. This impl uses the visitor to pre compute
the dependencies at parsing phase itself. It then uses that information to
determine the OSGi service dependencies. Based on that it would wait for
availability of dependent services before proceeding to create repository. With
such an implementation we would not have to modify the JR Server bundle if we
need to change factoryType for any other service from 'simple' to 'osgi'.
For such an impl both are required
-- Visitor - To collect the dependency information
-- factoryType attribute - To use that as marker to collect such dependencies
in visitor without attempting to created them
Also have a look at discussion at [2]
>>We can address those separately as we go. For now I think this is a good
>>start.
Agreed
[1]
https://github.com/chetanmeh/sling/blob/osgi-factory-adv/bundles/jcr/jackrabbit-server/src/main/java/org/apache/sling/jcr/jackrabbit/server/impl/OsgiBeanFactory.java
[2]
https://github.com/chetanmeh/sling/commit/422381cfe89bcd801e4104b8f24a14f3d4e558b1#commitcomment-1818143
was (Author: chetanm):
>>Otherwise, 'factoryClass' instead of 'factoryType' might be an option.
That way there is no need to invent additional "type names" for the factory.
I am fine with that. See next note below on why such an attribute is required
>> 2. We should maybe leave this out of the initial patch until it is used.
As noted in previous comment I have updated the implementation to use visitor
class. Have a look at DepFinderBeanConfigVisitor at [1]. This factory
(OsgiBeanFactory) is a generic implementation compared to previous one which
was aware about AuthorizableAction. This impl uses the visitor to pre compute
the dependencies at parsing phase itself. It then uses that information to
determine the OSGi service dependencies. Based on that it would wait for
availability of dependent services before proceeding to create repository. With
such an implementation we would not have to modify the JR Server bundle if we
need to change factoryType for any other service from 'simple' to 'osgi'.
For such an impl both are required
-- Visitor - To collect the dependency information
-- factoryType attribute - To use that as marker to collect such dependencies
in visitor without attempting to created them
>>We can address those separately as we go. For now I think this is a good
>>start.
Agreed
[1]
https://github.com/chetanmeh/sling/blob/osgi-factory-adv/bundles/jcr/jackrabbit-server/src/main/java/org/apache/sling/jcr/jackrabbit/server/impl/OsgiBeanFactory.java
> 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
