[
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
