You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Chetan Mehrotra (JIRA)" <ji...@apache.org> on 2012/10/18 07:48:06 UTC
[jira] [Created] (SLING-2624) Improving Jackrabbit integration with
OSGi Service Registry
Chetan Mehrotra created SLING-2624:
--------------------------------------
Summary: Improving Jackrabbit integration with OSGi Service Registry
Key: SLING-2624
URL: https://issues.apache.org/jira/browse/SLING-2624
Project: Sling
Issue Type: New Feature
Components: JCR
Reporter: Chetan Mehrotra
Current Sling integration with Jackrabbit (JR) allows for simpler access to Repository services from other bundles via the OSGi Service Registry (SR). However to make use of OSGi services within JR is tricky. Some integration is done wrt security but for other areas one needs to use fragments.
To simplify such integration recently a new feature was added to JR (JCR-3420) [1] which allows for registering a custom BeanFactory with JR. This would allow usage of services from service registry within JR. Refer to Mail thread [5] for relevant discussion
Feature Details
===============
This feature builds up on the new module org.apache.sling.jcr.jackrabbit.base proposed with SLING-2623.
OsgiBeanFactory
---------------
This is an implementation for the JR BeanFactory extension and acts as a bridge between OSGi and JR. It uses a custom BeanConfigVisitor to collect all the dependency information i.e. details about services which need to be pulled from SR. Then it uses a ServiceTracker to track avialability of all such services. Once all the required dependencies are found it registers itself with SR.
Once it is registered the SlingServerRepository can start
* Note - This feature has not much dependency on SLING-2623. Just that git fork is based on the base of SLING-2623
SlingServerRepository Integration
---------------------------------
OsgiBeanFactory needs to know the repository configuration which would be used to create the repository. Current fork impl uses one way to determine the config (which would need to be revisited). Further SlingServerRepository now has a reference for BeanFactory and would only be activated upon registration of BeanFactory
Note - The current SlingServerRepository is configured as component factory which would require a 1..1 mapping to BeanFactory. Such mapping is bit tricky to achieve. However in most cases a Sling server has only one SlingServerRepository. So the proposed approach *assumes* that there is a single repository instance configured
Sample Usage
============
To demonstrate the use of such a feature I took the usecase of externalizing the AuthorizableAction [2] in Sling env. So it should be possible to use an OSGi service which implements the AuthorizableAction within JR. An implementation of that is available at [4]. In the JR repository.xml we would have an entry like show below
<AuthorizableAction class="org.apache.jackrabbit.core.security.user.action.AuthorizableAction" />
Then the OSGiBeanFactory would obtain the instance of AuthorizableAction from Service Registry and provide that to JR. Now any bundle can register an instance of AuthorizableAction with SR and it would be invoked for various callbacks from JR UserManager!!
Note about patch
===============
The patch builds up on the SLING-2623 fork. Once we have consensus upon the approach I can extract relevant parts and propose a new patch
[1] https://issues.apache.org/jira/browse/JCR-3420
[2]
http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/core/security/user/action/AuthorizableAction.html
[3] https://github.com/chetanmeh/sling/compare/osgi-factory4
[4] https://github.com/chetanmeh/sling/compare/chetanmeh:jaas-osgi-adv...chetanmeh:osgi-factory4
[5] http://markmail.org/thread/3nnkygzef5dvzxod
--
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] (SLING-2624) Improving Jackrabbit integration with
OSGi Service Registry
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chetan Mehrotra updated SLING-2624:
-----------------------------------
Attachment: SLING-2624-initial-proposal.diff
Initial patch based on proposed approach
> Improving Jackrabbit integration with OSGi Service Registry
> -----------------------------------------------------------
>
> Key: SLING-2624
> URL: https://issues.apache.org/jira/browse/SLING-2624
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Chetan Mehrotra
> Attachments: SLING-2624-initial-proposal.diff
>
>
> Current Sling integration with Jackrabbit (JR) allows for simpler access to Repository services from other bundles via the OSGi Service Registry (SR). However to make use of OSGi services within JR is tricky. Some integration is done wrt security but for other areas one needs to use fragments.
> To simplify such integration recently a new feature was added to JR (JCR-3420) [1] which allows for registering a custom BeanFactory with JR. This would allow usage of services from service registry within JR. Refer to Mail thread [5] for relevant discussion
> Feature Details
> ===============
> This feature builds up on the new module org.apache.sling.jcr.jackrabbit.base proposed with SLING-2623.
> OsgiBeanFactory
> ---------------
> This is an implementation for the JR BeanFactory extension and acts as a bridge between OSGi and JR. It uses a custom BeanConfigVisitor to collect all the dependency information i.e. details about services which need to be pulled from SR. Then it uses a ServiceTracker to track avialability of all such services. Once all the required dependencies are found it registers itself with SR.
> Once it is registered the SlingServerRepository can start
> * Note - This feature has not much dependency on SLING-2623. Just that git fork is based on the base of SLING-2623
> SlingServerRepository Integration
> ---------------------------------
> OsgiBeanFactory needs to know the repository configuration which would be used to create the repository. Current fork impl uses one way to determine the config (which would need to be revisited). Further SlingServerRepository now has a reference for BeanFactory and would only be activated upon registration of BeanFactory
> Note - The current SlingServerRepository is configured as component factory which would require a 1..1 mapping to BeanFactory. Such mapping is bit tricky to achieve. However in most cases a Sling server has only one SlingServerRepository. So the proposed approach *assumes* that there is a single repository instance configured
> Sample Usage
> ============
> To demonstrate the use of such a feature I took the usecase of externalizing the AuthorizableAction [2] in Sling env. So it should be possible to use an OSGi service which implements the AuthorizableAction within JR. An implementation of that is available at [4]. In the JR repository.xml we would have an entry like show below
> <AuthorizableAction class="org.apache.jackrabbit.core.security.user.action.AuthorizableAction" />
> Then the OSGiBeanFactory would obtain the instance of AuthorizableAction from Service Registry and provide that to JR. Now any bundle can register an instance of AuthorizableAction with SR and it would be invoked for various callbacks from JR UserManager!!
> Note about patch
> ===============
> The patch builds up on the SLING-2623 fork. Once we have consensus upon the approach I can extract relevant parts and propose a new patch
> [1] https://issues.apache.org/jira/browse/JCR-3420
> [2]
> http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/core/security/user/action/AuthorizableAction.html
> [3] https://github.com/chetanmeh/sling/compare/osgi-factory4
> [4] https://github.com/chetanmeh/sling/compare/chetanmeh:jaas-osgi-adv...chetanmeh:osgi-factory4
> [5] http://markmail.org/thread/3nnkygzef5dvzxod
--
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] (SLING-2624) Improving Jackrabbit integration
with OSGi Service Registry
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482232#comment-13482232 ]
Carsten Ziegeler commented on SLING-2624:
-----------------------------------------
Thanks for the last patch, Chetan. I've applied it - except the jaas configurations. I think having this applied makes it a little bit easier to further discuss the stuff
> Improving Jackrabbit integration with OSGi Service Registry
> -----------------------------------------------------------
>
> Key: SLING-2624
> URL: https://issues.apache.org/jira/browse/SLING-2624
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Chetan Mehrotra
> Attachments: org.apache.sling.jcr.jackrabbit.base-0.0.1-SNAPSHOT-src.tar.gz, SLING-2624-3-no-jaas.diff, SLING-2624-initial-proposal.diff, SLING-2624-svn-compat.diff
>
>
> Current Sling integration with Jackrabbit (JR) allows for simpler access to Repository services from other bundles via the OSGi Service Registry (SR). However to make use of OSGi services within JR is tricky. Some integration is done wrt security but for other areas one needs to use fragments.
> To simplify such integration recently a new feature was added to JR (JCR-3420) [1] which allows for registering a custom BeanFactory with JR. This would allow usage of services from service registry within JR. Refer to Mail thread [5] for relevant discussion
> Feature Details
> ===============
> This feature builds up on the new module org.apache.sling.jcr.jackrabbit.base proposed with SLING-2623.
> OsgiBeanFactory
> ---------------
> This is an implementation for the JR BeanFactory extension and acts as a bridge between OSGi and JR. It uses a custom BeanConfigVisitor to collect all the dependency information i.e. details about services which need to be pulled from SR. Then it uses a ServiceTracker to track avialability of all such services. Once all the required dependencies are found it registers itself with SR.
> Once it is registered the SlingServerRepository can start
> * Note - This feature has not much dependency on SLING-2623. Just that git fork is based on the base of SLING-2623
> SlingServerRepository Integration
> ---------------------------------
> OsgiBeanFactory needs to know the repository configuration which would be used to create the repository. Current fork impl uses one way to determine the config (which would need to be revisited). Further SlingServerRepository now has a reference for BeanFactory and would only be activated upon registration of BeanFactory
> Note - The current SlingServerRepository is configured as component factory which would require a 1..1 mapping to BeanFactory. Such mapping is bit tricky to achieve. However in most cases a Sling server has only one SlingServerRepository. So the proposed approach *assumes* that there is a single repository instance configured
> Sample Usage
> ============
> To demonstrate the use of such a feature I took the usecase of externalizing the AuthorizableAction [2] in Sling env. So it should be possible to use an OSGi service which implements the AuthorizableAction within JR. An implementation of that is available at [4]. In the JR repository.xml we would have an entry like show below
> <AuthorizableAction class="org.apache.jackrabbit.core.security.user.action.AuthorizableAction" />
> Then the OSGiBeanFactory would obtain the instance of AuthorizableAction from Service Registry and provide that to JR. Now any bundle can register an instance of AuthorizableAction with SR and it would be invoked for various callbacks from JR UserManager!!
> Note about patch
> ===============
> The patch builds up on the SLING-2623 fork. Once we have consensus upon the approach I can extract relevant parts and propose a new patch
> [1] https://issues.apache.org/jira/browse/JCR-3420
> [2]
> http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/core/security/user/action/AuthorizableAction.html
> [3] https://github.com/chetanmeh/sling/compare/osgi-factory4
> [4] https://github.com/chetanmeh/sling/compare/chetanmeh:jaas-osgi-adv...chetanmeh:osgi-factory4
> [5] http://markmail.org/thread/3nnkygzef5dvzxod
--
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] (SLING-2624) Improving Jackrabbit integration
with OSGi Service Registry
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481313#comment-13481313 ]
Carsten Ziegeler commented on SLING-2624:
-----------------------------------------
Hi Chetan,
could you please provide an svn based patch?
Thanks
> Improving Jackrabbit integration with OSGi Service Registry
> -----------------------------------------------------------
>
> Key: SLING-2624
> URL: https://issues.apache.org/jira/browse/SLING-2624
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Chetan Mehrotra
> Attachments: SLING-2624-initial-proposal.diff
>
>
> Current Sling integration with Jackrabbit (JR) allows for simpler access to Repository services from other bundles via the OSGi Service Registry (SR). However to make use of OSGi services within JR is tricky. Some integration is done wrt security but for other areas one needs to use fragments.
> To simplify such integration recently a new feature was added to JR (JCR-3420) [1] which allows for registering a custom BeanFactory with JR. This would allow usage of services from service registry within JR. Refer to Mail thread [5] for relevant discussion
> Feature Details
> ===============
> This feature builds up on the new module org.apache.sling.jcr.jackrabbit.base proposed with SLING-2623.
> OsgiBeanFactory
> ---------------
> This is an implementation for the JR BeanFactory extension and acts as a bridge between OSGi and JR. It uses a custom BeanConfigVisitor to collect all the dependency information i.e. details about services which need to be pulled from SR. Then it uses a ServiceTracker to track avialability of all such services. Once all the required dependencies are found it registers itself with SR.
> Once it is registered the SlingServerRepository can start
> * Note - This feature has not much dependency on SLING-2623. Just that git fork is based on the base of SLING-2623
> SlingServerRepository Integration
> ---------------------------------
> OsgiBeanFactory needs to know the repository configuration which would be used to create the repository. Current fork impl uses one way to determine the config (which would need to be revisited). Further SlingServerRepository now has a reference for BeanFactory and would only be activated upon registration of BeanFactory
> Note - The current SlingServerRepository is configured as component factory which would require a 1..1 mapping to BeanFactory. Such mapping is bit tricky to achieve. However in most cases a Sling server has only one SlingServerRepository. So the proposed approach *assumes* that there is a single repository instance configured
> Sample Usage
> ============
> To demonstrate the use of such a feature I took the usecase of externalizing the AuthorizableAction [2] in Sling env. So it should be possible to use an OSGi service which implements the AuthorizableAction within JR. An implementation of that is available at [4]. In the JR repository.xml we would have an entry like show below
> <AuthorizableAction class="org.apache.jackrabbit.core.security.user.action.AuthorizableAction" />
> Then the OSGiBeanFactory would obtain the instance of AuthorizableAction from Service Registry and provide that to JR. Now any bundle can register an instance of AuthorizableAction with SR and it would be invoked for various callbacks from JR UserManager!!
> Note about patch
> ===============
> The patch builds up on the SLING-2623 fork. Once we have consensus upon the approach I can extract relevant parts and propose a new patch
> [1] https://issues.apache.org/jira/browse/JCR-3420
> [2]
> http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/core/security/user/action/AuthorizableAction.html
> [3] https://github.com/chetanmeh/sling/compare/osgi-factory4
> [4] https://github.com/chetanmeh/sling/compare/chetanmeh:jaas-osgi-adv...chetanmeh:osgi-factory4
> [5] http://markmail.org/thread/3nnkygzef5dvzxod
--
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] (SLING-2624) Improving Jackrabbit integration with
OSGi Service Registry
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chetan Mehrotra updated SLING-2624:
-----------------------------------
Attachment: SLING-2624-svn-compat.diff
svn compatible diff. If applying through eclipse select the reverse option
> Improving Jackrabbit integration with OSGi Service Registry
> -----------------------------------------------------------
>
> Key: SLING-2624
> URL: https://issues.apache.org/jira/browse/SLING-2624
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Chetan Mehrotra
> Attachments: SLING-2624-initial-proposal.diff, SLING-2624-svn-compat.diff
>
>
> Current Sling integration with Jackrabbit (JR) allows for simpler access to Repository services from other bundles via the OSGi Service Registry (SR). However to make use of OSGi services within JR is tricky. Some integration is done wrt security but for other areas one needs to use fragments.
> To simplify such integration recently a new feature was added to JR (JCR-3420) [1] which allows for registering a custom BeanFactory with JR. This would allow usage of services from service registry within JR. Refer to Mail thread [5] for relevant discussion
> Feature Details
> ===============
> This feature builds up on the new module org.apache.sling.jcr.jackrabbit.base proposed with SLING-2623.
> OsgiBeanFactory
> ---------------
> This is an implementation for the JR BeanFactory extension and acts as a bridge between OSGi and JR. It uses a custom BeanConfigVisitor to collect all the dependency information i.e. details about services which need to be pulled from SR. Then it uses a ServiceTracker to track avialability of all such services. Once all the required dependencies are found it registers itself with SR.
> Once it is registered the SlingServerRepository can start
> * Note - This feature has not much dependency on SLING-2623. Just that git fork is based on the base of SLING-2623
> SlingServerRepository Integration
> ---------------------------------
> OsgiBeanFactory needs to know the repository configuration which would be used to create the repository. Current fork impl uses one way to determine the config (which would need to be revisited). Further SlingServerRepository now has a reference for BeanFactory and would only be activated upon registration of BeanFactory
> Note - The current SlingServerRepository is configured as component factory which would require a 1..1 mapping to BeanFactory. Such mapping is bit tricky to achieve. However in most cases a Sling server has only one SlingServerRepository. So the proposed approach *assumes* that there is a single repository instance configured
> Sample Usage
> ============
> To demonstrate the use of such a feature I took the usecase of externalizing the AuthorizableAction [2] in Sling env. So it should be possible to use an OSGi service which implements the AuthorizableAction within JR. An implementation of that is available at [4]. In the JR repository.xml we would have an entry like show below
> <AuthorizableAction class="org.apache.jackrabbit.core.security.user.action.AuthorizableAction" />
> Then the OSGiBeanFactory would obtain the instance of AuthorizableAction from Service Registry and provide that to JR. Now any bundle can register an instance of AuthorizableAction with SR and it would be invoked for various callbacks from JR UserManager!!
> Note about patch
> ===============
> The patch builds up on the SLING-2623 fork. Once we have consensus upon the approach I can extract relevant parts and propose a new patch
> [1] https://issues.apache.org/jira/browse/JCR-3420
> [2]
> http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/core/security/user/action/AuthorizableAction.html
> [3] https://github.com/chetanmeh/sling/compare/osgi-factory4
> [4] https://github.com/chetanmeh/sling/compare/chetanmeh:jaas-osgi-adv...chetanmeh:osgi-factory4
> [5] http://markmail.org/thread/3nnkygzef5dvzxod
--
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] (SLING-2624) Improving Jackrabbit integration with
OSGi Service Registry
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chetan Mehrotra updated SLING-2624:
-----------------------------------
Attachment: SLING-2624-3-no-jaas.diff
Attempt 3 - Updated patch which removes hard dependency on new Felix JAAS API support for now. This patch has all the other changes (including JAAS ones) but does not require new Felix JAAS bundle to be present. Some other changes compared to previous patches
-- Removes the Sample classes which demonstrate the new pluggable AuthorizableAction support
-- Moved the pluggable AuthorizableAction support to the base bundle
patch file name SLING-2624-3-no-jaas.diff
Git fork diff https://github.com/chetanmeh/sling/compare/osgi-factory-nojaas
> Improving Jackrabbit integration with OSGi Service Registry
> -----------------------------------------------------------
>
> Key: SLING-2624
> URL: https://issues.apache.org/jira/browse/SLING-2624
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Chetan Mehrotra
> Attachments: org.apache.sling.jcr.jackrabbit.base-0.0.1-SNAPSHOT-src.tar.gz, SLING-2624-3-no-jaas.diff, SLING-2624-initial-proposal.diff, SLING-2624-svn-compat.diff
>
>
> Current Sling integration with Jackrabbit (JR) allows for simpler access to Repository services from other bundles via the OSGi Service Registry (SR). However to make use of OSGi services within JR is tricky. Some integration is done wrt security but for other areas one needs to use fragments.
> To simplify such integration recently a new feature was added to JR (JCR-3420) [1] which allows for registering a custom BeanFactory with JR. This would allow usage of services from service registry within JR. Refer to Mail thread [5] for relevant discussion
> Feature Details
> ===============
> This feature builds up on the new module org.apache.sling.jcr.jackrabbit.base proposed with SLING-2623.
> OsgiBeanFactory
> ---------------
> This is an implementation for the JR BeanFactory extension and acts as a bridge between OSGi and JR. It uses a custom BeanConfigVisitor to collect all the dependency information i.e. details about services which need to be pulled from SR. Then it uses a ServiceTracker to track avialability of all such services. Once all the required dependencies are found it registers itself with SR.
> Once it is registered the SlingServerRepository can start
> * Note - This feature has not much dependency on SLING-2623. Just that git fork is based on the base of SLING-2623
> SlingServerRepository Integration
> ---------------------------------
> OsgiBeanFactory needs to know the repository configuration which would be used to create the repository. Current fork impl uses one way to determine the config (which would need to be revisited). Further SlingServerRepository now has a reference for BeanFactory and would only be activated upon registration of BeanFactory
> Note - The current SlingServerRepository is configured as component factory which would require a 1..1 mapping to BeanFactory. Such mapping is bit tricky to achieve. However in most cases a Sling server has only one SlingServerRepository. So the proposed approach *assumes* that there is a single repository instance configured
> Sample Usage
> ============
> To demonstrate the use of such a feature I took the usecase of externalizing the AuthorizableAction [2] in Sling env. So it should be possible to use an OSGi service which implements the AuthorizableAction within JR. An implementation of that is available at [4]. In the JR repository.xml we would have an entry like show below
> <AuthorizableAction class="org.apache.jackrabbit.core.security.user.action.AuthorizableAction" />
> Then the OSGiBeanFactory would obtain the instance of AuthorizableAction from Service Registry and provide that to JR. Now any bundle can register an instance of AuthorizableAction with SR and it would be invoked for various callbacks from JR UserManager!!
> Note about patch
> ===============
> The patch builds up on the SLING-2623 fork. Once we have consensus upon the approach I can extract relevant parts and propose a new patch
> [1] https://issues.apache.org/jira/browse/JCR-3420
> [2]
> http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/core/security/user/action/AuthorizableAction.html
> [3] https://github.com/chetanmeh/sling/compare/osgi-factory4
> [4] https://github.com/chetanmeh/sling/compare/chetanmeh:jaas-osgi-adv...chetanmeh:osgi-factory4
> [5] http://markmail.org/thread/3nnkygzef5dvzxod
--
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] (SLING-2624) Improving Jackrabbit integration with
OSGi Service Registry
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chetan Mehrotra updated SLING-2624:
-----------------------------------
Attachment: org.apache.sling.jcr.jackrabbit.base-0.0.1-SNAPSHOT-src.tar.gz
Just the source files for the base bundle
> Improving Jackrabbit integration with OSGi Service Registry
> -----------------------------------------------------------
>
> Key: SLING-2624
> URL: https://issues.apache.org/jira/browse/SLING-2624
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Chetan Mehrotra
> Attachments: org.apache.sling.jcr.jackrabbit.base-0.0.1-SNAPSHOT-src.tar.gz, SLING-2624-initial-proposal.diff, SLING-2624-svn-compat.diff
>
>
> Current Sling integration with Jackrabbit (JR) allows for simpler access to Repository services from other bundles via the OSGi Service Registry (SR). However to make use of OSGi services within JR is tricky. Some integration is done wrt security but for other areas one needs to use fragments.
> To simplify such integration recently a new feature was added to JR (JCR-3420) [1] which allows for registering a custom BeanFactory with JR. This would allow usage of services from service registry within JR. Refer to Mail thread [5] for relevant discussion
> Feature Details
> ===============
> This feature builds up on the new module org.apache.sling.jcr.jackrabbit.base proposed with SLING-2623.
> OsgiBeanFactory
> ---------------
> This is an implementation for the JR BeanFactory extension and acts as a bridge between OSGi and JR. It uses a custom BeanConfigVisitor to collect all the dependency information i.e. details about services which need to be pulled from SR. Then it uses a ServiceTracker to track avialability of all such services. Once all the required dependencies are found it registers itself with SR.
> Once it is registered the SlingServerRepository can start
> * Note - This feature has not much dependency on SLING-2623. Just that git fork is based on the base of SLING-2623
> SlingServerRepository Integration
> ---------------------------------
> OsgiBeanFactory needs to know the repository configuration which would be used to create the repository. Current fork impl uses one way to determine the config (which would need to be revisited). Further SlingServerRepository now has a reference for BeanFactory and would only be activated upon registration of BeanFactory
> Note - The current SlingServerRepository is configured as component factory which would require a 1..1 mapping to BeanFactory. Such mapping is bit tricky to achieve. However in most cases a Sling server has only one SlingServerRepository. So the proposed approach *assumes* that there is a single repository instance configured
> Sample Usage
> ============
> To demonstrate the use of such a feature I took the usecase of externalizing the AuthorizableAction [2] in Sling env. So it should be possible to use an OSGi service which implements the AuthorizableAction within JR. An implementation of that is available at [4]. In the JR repository.xml we would have an entry like show below
> <AuthorizableAction class="org.apache.jackrabbit.core.security.user.action.AuthorizableAction" />
> Then the OSGiBeanFactory would obtain the instance of AuthorizableAction from Service Registry and provide that to JR. Now any bundle can register an instance of AuthorizableAction with SR and it would be invoked for various callbacks from JR UserManager!!
> Note about patch
> ===============
> The patch builds up on the SLING-2623 fork. Once we have consensus upon the approach I can extract relevant parts and propose a new patch
> [1] https://issues.apache.org/jira/browse/JCR-3420
> [2]
> http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/core/security/user/action/AuthorizableAction.html
> [3] https://github.com/chetanmeh/sling/compare/osgi-factory4
> [4] https://github.com/chetanmeh/sling/compare/chetanmeh:jaas-osgi-adv...chetanmeh:osgi-factory4
> [5] http://markmail.org/thread/3nnkygzef5dvzxod
--
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