On 16 Sep 2010, at 06:42, Justin Edelson wrote: > On 9/15/10 4:36 PM, Ian Boston wrote: >> >> On 15 Sep 2010, at 05:01, Justin Edelson wrote: >> >>> FYI - Created JCR-2748 and submitted a patch to provide a simple way to >>> disable anonymous access to the security workspace. >>> >>> Ian - have you looked at turning the Sakai server bundle into a fragment >>> attached to the Sling JCR Jackrabbit Server bundle? I do that with a >>> custom FileSystem and DataSource implementation and it seems to work OK. >>> Having this as a fragment would make it easier for other projects to >>> consume, although I understand if that isn't really the point of Sakai. >> >> Justin, >> Thanks for the tip. >> I havent looked into it, but I know I should, Sakai would like to feel its >> contributing back. >> At the moment we are pushing for a release on 1 Oct, and have feature >> frozen, so I am probably going to have to wait until after that release. >> Ian >> >> >> > I poked around the code a bit. I think you'd probably want to > restructure the code to move the security API into a separate bundle as > well as repackage everything. I'll be happy to try to help with this > after your release (good luck with that!)
Had a quick look at this and there may be some issues. IIUC in the OSGi R4 spec 3.14.2 "A host bundle’s class path is searched before a fragment’s class path" And we need to override the Activator as well as some other classes like patching some of the core index classes. BundleActivator cant exist in a fragment (afaict) The other problem might be the RuleAclModifier class needs to bind to protected packages internal to Jackrabbit and so have to be in the same classloader, so have to be in a modified server bundle or possibly in a fragment subject to the impl of the bundle protection. Still looking at it. Ian > > From the Sling side, I think we should be trying to ensure that these > types of extensions are possible and easy to do without rebundling. > Sakai is a good test bed for this capability. > > Justin
