Hi, On 27.01.2010 20:50, Grégory Joseph wrote: > Hi Carsten, > > On Jan 25, 2010, at 9:02 AM, Carsten Ziegeler wrote: >> I think we briefly discussed this topic some time ago: the Jackrabbit >> 1.x versions provide a repository classloader which is not available >> anymore in 2.0. > > Can't find any related thread. Any pointer ?
http://markmail.org/message/et5dux6y4hufeij6 is the message from Jukka regarding the option to move the classloader from Jackrabbit to Sling and http://markmail.org/thread/vechl274bewkh4o6 is the thread. > >> In Sling we provide a complete scripting framework based on top of the >> repository and we're using the Jackrabbit classloader code and extended it. >> >> As Jackrabbit is not using the code anymore, but Sling is, I think it >> makes perfectly sense to move/copy the code to Sling. > > As far as I can tell, it's in the "commons" folder [1] - it's an optional > component that's indeed not bundled with Jackrabbit. TBH, I haven't looked at > it very closely, but I'd it is/could/should be independent of Jackrabbit, i.e > rely on the JCR API alone. > >> So I would like to copy the classloader code into the Sling repo in the >> next days and modifiy it to suit Sling's needs a little bit more. This >> has no impact on Jackrabbit as 2.0 does not contain the code at all and >> it still remains in the 1.x branch. > > Again - afaict, it's not in either branch, it's a separate component. > >> Basically this is more a FYI as no legal steps etc are involved :) But >> before doing this I want to be sure that there are zero objections. > > I'm only answering because I'd like to have a close look at it one of these > days, and hopefully use/improve it, too. If it stays repository- and > application-neutral. If it becomes tied to Sling, not so much. Well, if Sling would take over maintenance of the classloader, the existing functionality would probably have to be preserved. Yet, of course, we would enhance it to support Sling's requirements. For now, Carsten has just been copying the class loader to Sling and stripped it down to remove stuff, which we deem useless for Sling (so he essentially forked it). > > What kind of changes/improvements are you looking into ? Mainly the requirements for Sling in terms of "dynamic class laoding infrastructure" to support Sling's support for dynamic code changes in the repository and in the OSGi framework. Regards Felix
