Re: Use cases for bundle-based Jackrabbit customizations?
2009/5/6 Bertrand Delacretaz bdelacre...@apache.org: In an ideal world, I think it should be possible to use separate bundles to provide classes for all elements of the repository.xml configuration that have a class attribute. Hear, hear! [...] Could people give a quick description of their use cases that require customizing these things? Please also briefly indicate if/how that works now. I need some custom AccessManager logic, therefore I created the PluggableAccessManager, see SLING-880 [1]. This patch provides an interface that can be implemented by custom bundles. The interface is really a simplified version of AccessManager. This again was inspired by a tip from Rory Douglas [2], who pointed me to PluggableDefaultLoginModule. The PluggableAccessManager works for me, but being able to plugin a real Jackrabbit AccessManager, would sure be nice. It would also be useful if DefaultAccessManager could be exported, as it is much easier to override certain methods in that, than to implement the interface from scratch. [1] https://issues.apache.org/jira/browse/SLING-880 [2] http://markmail.org/thread/wlqm3yjpbyokwcvy -- Vidar S. Ramdal vi...@idium.no - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
Re: Use cases for bundle-based Jackrabbit customizations?
On Wed, May 6, 2009 at 2:49 PM, Ian Boston i...@tfd.co.uk wrote: At the moment we (Sakai) would might want to customze LoginModule and WorkspaceAccessmanager and need to customize SecurityManager so that we can get a custom DefaultAccessManager. ...At the moment, we have a big patch on the jackrabbit-server bundle, which IMHO is not sustainable. I think this might really be an issue for Jackrabbit rather than Sling. Happy to create a patch if it would help explain the detail I agree that this is more an issue for Jackrabbit in the end, but as several people seemed to have issues with that in Sling I thought here might be a good place to collect requirements. Creating a patch might be a good idea - even if it's supposed to go into Jackrabbit eventually, I think clarifying the issues here would be good. -Bertrand
Re: Use cases for bundle-based Jackrabbit customizations?
Ok will do, For Sling I need to do it against JR15, we have done this already in the jackrabbit-server bundle, ideally the extension mechanism should go into JR so that will patches against the 1.x branch and trunk. I haven't had a chance to see where trunk has gone with 20, but will do. Ian On 7 May 2009, at 10:49, Bertrand Delacretaz wrote: Creating a patch might be a good idea - even if it's supposed to go into Jackrabbit eventually, I think clarifying the issues here would be good.
Re: Use cases for bundle-based Jackrabbit customizations?
Hi, On Wed, May 6, 2009 at 11:33 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: I'm trying to get an overview of the current issues related to customizing an embedded Jackrabbit repository using Sling bundles. Note that the current Jackrabbit configuration mechanism requires direct access to all the *implementation* classes configured in the repository.xml file. I'm not sure how this could best be made to work with the cross-bundle class loading restrictions in an OSGi environment. There's an ongoing effort in Jackrabbit to make the configuration handling more flexible (JCR-1438), with the ultimate goal of being able to configure Jackrabbit using OSGi services or an IoC container. I've already been able to implement parts of the issue (see the related commits in Jackrabbit), but there's still quite a lot of work remaining with the more complex configuration entries. BR, Jukka Zitting
Re: Use cases for bundle-based Jackrabbit customizations?
On Thu, May 7, 2009 at 12:46 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
...On Wed, May 6, 2009 at 11:33 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
I'm trying to get an overview of the current issues related to
customizing an embedded Jackrabbit repository using Sling bundles.
Note that the current Jackrabbit configuration mechanism requires
direct access to all the *implementation* classes configured in the
repository.xml file. I'm not sure how this could best be made to work
with the cross-bundle class loading restrictions in an OSGi
environment...
One way that should work (didn't work before the recent upgrade of the
Felix framework) is to provide the customization classes in fragment
bundles that are attached to the jackrabbit server bundles. This makes
those classes available to that bundle exactly as if they were part of
the bundle.
Another option is to use dynamic imports in the jackrabbit server
bundle, and have the customization bundles export the implementation
classes.
Both the above solutions are suboptimal, but should allow Jackrabbit
extensions to come from different bundles.
I've had a look at https://issues.apache.org/jira/browse/JCR-1438
which is about using factories to instantiate the pluggable Jackrabbit
components, and I'm wondering if a central customizing method would
help, something like:
interface Customizer {
T getCustomizableComponentInstance(
Class T componentType, MapString, String options
}
Where standard Jackrabbit would use Class.forName() based on a
property in the options, and in an OSGi environment you'd plugin a
Customizer that grabs the appropriate OSGi service based on the type T
and options. Not sure if Jackrabbit requires Java 1.5 already, but it
not the idea can also work without generics.
-Bertrand
Use cases for bundle-based Jackrabbit customizations?
Hi, I'm trying to get an overview of the current issues related to customizing an embedded Jackrabbit repository using Sling bundles. I tried to find the info in our archives but I'm not quite sure what the current status is. In an ideal world, I think it should be possible to use separate bundles to provide classes for all elements of the repository.xml configuration that have a class attribute. With the jackrabbit 1.5 repository.xml DTD, that would be the FileSystem, SecurityManager, LoginModule, WorkspaceAccessManager, PersistenceManager, SearchIndex, Journal, ISMLocking and DataStore. Now, in practice we might not need all of these things to come from separate bundles, as some customizations are not often needed. Could people give a quick description of their use cases that require customizing these things? Please also briefly indicate if/how that works now. The intention is to identify changes that we might need to make to the Jackrabbit bundles to enable those customizations. -Bertrand [1] http://jackrabbit.apache.org/jackrabbit-configuration.html
Re: Use cases for bundle-based Jackrabbit customizations?
At the moment we (Sakai) would might want to customze LoginModule and WorkspaceAccessmanager and need to customize SecurityManager so that we can get a custom DefaultAccessManager. The difficulty is less that we cant replace these items as we already customize the repository.xml, the problem is more that without putting code in specific packages eg org.apache.jackrabbit.core we cant extend the existing functionality in DefaultAccessManager. So in our immediate use case, the need is 2 fold. 1) To have some of the core parts of org.apache.jackrabbit.core exposed via provider interfaces and extendable classes. 2) To have some of that exported from the jackrabbit-server bundle or another suitable bundle to make it possible to package the bundles in a separate bundle. At the moment, we have a big patch on the jackrabbit-server bundle, which IMHO is not sustainable. I think this might really be an issue for Jackrabbit rather than Sling. Happy to create a patch if it would help explain the detail. Ian On 6 May 2009, at 10:33, Bertrand Delacretaz wrote: Hi, I'm trying to get an overview of the current issues related to customizing an embedded Jackrabbit repository using Sling bundles. I tried to find the info in our archives but I'm not quite sure what the current status is. In an ideal world, I think it should be possible to use separate bundles to provide classes for all elements of the repository.xml configuration that have a class attribute. With the jackrabbit 1.5 repository.xml DTD, that would be the FileSystem, SecurityManager, LoginModule, WorkspaceAccessManager, PersistenceManager, SearchIndex, Journal, ISMLocking and DataStore. Now, in practice we might not need all of these things to come from separate bundles, as some customizations are not often needed. Could people give a quick description of their use cases that require customizing these things? Please also briefly indicate if/how that works now. The intention is to identify changes that we might need to make to the Jackrabbit bundles to enable those customizations. -Bertrand [1] http://jackrabbit.apache.org/jackrabbit-configuration.html
