Hi Felix, Thanks for the links - I could have search for a long time in my jackrabbit-dev-list archive ;)
>>> 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). Right. Well, essentially, I don't care *where* it is, as long as I can, one way or another, use it and possibly contribute. I'm not looking into using in the short-term, though, so I'm not even sure right now if it'd what I need or not at all, but it sure looks like it. Worse come to worse, I could also fork 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. Hmmm, obscure stuff to me. Any chance you'd have a pointer to a page, document, email, ... outlining what that's all about ? Just curious to see if that has anything to do with what I'm after. At the moment, I'm looking at a jcr-classloader as some sort of virtual filesystem where I could store/load jars/classes, and indeed possibly reloaded when updated. OSGi is still quite a big dark box to me. Cheers, -g ps: fwiw, I patched the classloader from https://svn.apache.org/repos/asf/jackrabbit/commons/classloader/trunk/ to use JCR 2.0 and remove the Jackrabbit dependencies (except for testing, of course). Is there any interest in such a patch on the Jackrabbit side... now ?
