You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2012/09/06 12:55:08 UTC
[jira] [Created] (JCR-3420) Improving Jackrabbit integration within
OSGi and other managed environment
Michael Dürig created JCR-3420:
----------------------------------
Summary: 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
Reporter: Michael Dürig
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
[jira] [Commented] (JCR-3420) Improving Jackrabbit integration
within OSGi and other managed environment
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454066#comment-13454066 ]
Chetan Mehrotra commented on JCR-3420:
--------------------------------------
Thanks Michael!! Would now follow up on Sling DL to see if this feature can be put to use.
> 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
[jira] [Updated] (JCR-3420) Improving Jackrabbit integration within
OSGi and other managed environment
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dürig updated JCR-3420:
-------------------------------
Resolution: Fixed
Fix Version/s: 2.6
Assignee: Michael Dürig
Status: Resolved (was: Patch Available)
Fixed at revision 1383976
> 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
> Assignee: Michael Dürig
> Fix For: 2.6
>
> 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
[jira] [Commented] (JCR-3420) Improving Jackrabbit integration
within OSGi and other managed environment
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449795#comment-13449795 ]
Michael Dürig commented on JCR-3420:
------------------------------------
The patch looks quite good to me.
> 1. Introducing new attribute 'factoryType'...
Is this really necessary? Shouldn't a custom factory just delegate to its predecessor? I.e. when you do parser.setBeanFactory(beanFactory) couldn't that register the new factory in a way such that when it can't create an instance it would automatically delegate instance creation to the previous factory?
Otherwise, 'factoryClass' instead of 'factoryType' might be an option. That way there is no need to invent additional "type names" for the factory.
> 2. We should maybe leave this out of the initial patch until it is used.
> 3. and 4.
We can address those separately as we go. For now I think this is a good start.
> 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
[jira] [Comment Edited] (JCR-3420) Improving Jackrabbit integration
within OSGi and other managed environment
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (JCR-3420) Improving Jackrabbit integration
within OSGi and other managed environment
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454015#comment-13454015 ]
Chetan Mehrotra commented on JCR-3420:
--------------------------------------
ya thinking more about it we can get rid of extra attribute. So the logic would be
1. Check for all the classNames as part of BeanConfigVisitor.
a) If the class object corresponding to that className is an interface then corresponding instance for that bean MUST be obtained via factory.
b) If the class object is not an interface then no DI would be done and bean instance would be directly instantiated as per current logic.
2. Once all such dependencies are determined use that to control when the repository should be started
3. When newInstance call is done look for a service from managing container (like Service Registry in OSGi) which implements that interface and use that. If no such service is found fail the startup.
In current JR impl all such cases involve interfaces and such an approach should work fine
> 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
[jira] [Comment Edited] (JCR-3420) Improving Jackrabbit integration
within OSGi and other managed environment
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454015#comment-13454015 ]
Chetan Mehrotra edited comment on JCR-3420 at 9/13/12 1:09 AM:
---------------------------------------------------------------
ya thinking more about it we can get rid of extra attribute. So the logic would be
1. Check for all the classNames as part of BeanConfigVisitor.
a) If the class object corresponding to that className is an interface or an abstract class then corresponding instance for that bean MUST be obtained via factory.
b) If the class object is not an interface then no DI would be done and bean instance would be directly instantiated as per current logic.
2. Once all such dependencies are determined use that to control when the repository should be started
3. When newInstance call is done look for a service from managing container (like Service Registry in OSGi) which implements that interface and use that. If no such service is found fail the startup.
In current JR impl all such cases involve interfaces and such an approach should work fine
was (Author: chetanm):
ya thinking more about it we can get rid of extra attribute. So the logic would be
1. Check for all the classNames as part of BeanConfigVisitor.
a) If the class object corresponding to that className is an interface then corresponding instance for that bean MUST be obtained via factory.
b) If the class object is not an interface then no DI would be done and bean instance would be directly instantiated as per current logic.
2. Once all such dependencies are determined use that to control when the repository should be started
3. When newInstance call is done look for a service from managing container (like Service Registry in OSGi) which implements that interface and use that. If no such service is found fail the startup.
In current JR impl all such cases involve interfaces and such an approach should work fine
> 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
[jira] [Commented] (JCR-3420) Improving Jackrabbit integration
within OSGi and other managed environment
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454037#comment-13454037 ]
Michael Dürig commented on JCR-3420:
------------------------------------
Applied the patch with modifications as described at revision 1383976.
I suggest to resolve this issue as fixed and follow up with new issues if necessary.
> 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
[jira] [Commented] (JCR-3420) Improving Jackrabbit integration
within OSGi and other managed environment
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449857#comment-13449857 ]
Chetan Mehrotra commented on JCR-3420:
--------------------------------------
>>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
[jira] [Updated] (JCR-3420) Improving Jackrabbit integration within
OSGi and other managed environment
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chetan Mehrotra updated JCR-3420:
---------------------------------
Affects Version/s: 2.5.1
Status: Patch Available (was: Open)
Patch file based on diff between the Github fork https://github.com/chetanmeh/jackrabbit/tree/osgi-factory
> 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
[jira] [Commented] (JCR-3420) Improving Jackrabbit integration
within OSGi and other managed environment
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449784#comment-13449784 ]
Chetan Mehrotra commented on JCR-3420:
--------------------------------------
For #2 - An implementation which is generic and make use of BeanConfigVisitor is now available at [1]. This implementation makes use of the visitor to find out all the dependencies and then manages its OSGi config based on those dependencies. This implementation is generic
[1] https://github.com/chetanmeh/sling/compare/osgi-factory-adv#L1R134
> 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
[jira] [Comment Edited] (JCR-3420) Improving Jackrabbit integration
within OSGi and other managed environment
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449795#comment-13449795 ]
Michael Dürig edited comment on JCR-3420 at 9/7/12 3:45 AM:
------------------------------------------------------------
The patch looks quite good to me.
> 1. Introducing new attribute 'factoryType'...
Is this really necessary? Shouldn't a custom factory just delegate to its predecessor? I.e. when you do parser.setBeanFactory(beanFactory) couldn't that register the new factory in a way such that when it can't create an instance it would automatically delegate instance creation to the previous factory?
Otherwise, 'factoryClass' instead of 'factoryType' might be an option. That way there is no need to invent additional "type names" for the factory.
> 2. We should maybe leave this out of the initial patch until it is used.
> 4. and 5.
We can address those separately as we go. For now I think this is a good start.
was (Author: mduerig):
The patch looks quite good to me.
> 1. Introducing new attribute 'factoryType'...
Is this really necessary? Shouldn't a custom factory just delegate to its predecessor? I.e. when you do parser.setBeanFactory(beanFactory) couldn't that register the new factory in a way such that when it can't create an instance it would automatically delegate instance creation to the previous factory?
Otherwise, 'factoryClass' instead of 'factoryType' might be an option. That way there is no need to invent additional "type names" for the factory.
> 2. We should maybe leave this out of the initial patch until it is used.
> 3. and 4.
We can address those separately as we go. For now I think this is a good start.
> 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
[jira] [Updated] (JCR-3420) Improving Jackrabbit integration within
OSGi and other managed environment
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chetan Mehrotra updated JCR-3420:
---------------------------------
Attachment: JCR-3420-osgi-factory.patch
> 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
> 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
[jira] [Commented] (JCR-3420) Improving Jackrabbit integration
within OSGi and other managed environment
Posted by "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
[jira] [Commented] (JCR-3420) Improving Jackrabbit integration
within OSGi and other managed environment
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453978#comment-13453978 ]
Michael Dürig commented on JCR-3420:
------------------------------------
> -- factoryType attribute - To use that as marker to collect such dependencies in visitor without attempting to created them
If we attempt to load the class, can we then get rid of the factoryType attribute? What is the drawback of attempting to load the class? I'd love to get rid of this extra configuration complexity and just have the factory try to create the instance and delegate to its predecessor if this fails.
> 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
[jira] [Commented] (JCR-3420) Improving Jackrabbit integration
within OSGi and other managed environment
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454021#comment-13454021 ]
Michael Dürig commented on JCR-3420:
------------------------------------
Ok, great. If no one objects, I'll apply your patch with the factoryType attribute removed. If it turns out later on, that we need something like this we can still introduce it then.
> 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