On 14 Apr 2005, at 13:32, Daniel Fagerstrom wrote:
<snip/>
After having read your mails I agree that we at least for the time being, should consider component management with classloader isolation, a separate concern. By _assuming_ independence between blocks and component management, anyone who feel the itch can start working on class loader isolation right away. Then we can integrate the component management stuff in the blocks later if we feel the need. And if we don't, we saved ourself from considerable complexity.
I have that itch,
I hoped so :)
Does anyone have problems if I wipe the current "kernel" in SVN? I want to try and synchronize it with the changes I've made locally (and try to sort out a few hacks we've had to introduce in our local copy)
and to tell you the truth, the kernel in SVN _already_ does a some level of classloader isolation. Thing is, I use it on a daily basis for an XML repository we have (in house) at VNU, and the more I use it, the more I see the problems of the _current_ approach.
I hit a dead end with the implementation in CVS last week when I wanted to upgrade JAXP from 1.2 to 1.3, running on a 1.4 JVM, but _not_ using the -Djava.endorsed.dirs JVM flag. I can't tell you the issues on trying to isolate the JAXP 1.3 contract and kernel plug-in from the underlying JVM, but with a bit of luck, I found what's wrong, and we should be up and running with the new kernel (here at VNU) in a week-or-so...
Same here, as long as you tell us what you are planning to do, so that especially Carsten and Sylvain can say if it works with their plans, you have my big +1.
My problem is that I'm not "paid" to work on Cocoon, so I kinda "hide" all this work behind changes that are required for our in-house XML-repository. And some of the hacks that are in our current code are definitely something I don't want to add to the Cocoon SVN.
Is it based on the whiteboard kernel?
Yup... It's basically that, but I've spotted a few problems using it :-(
In that case I would be interested in geting a short description of the involved concepts and how they cooperate. I'm thinking of: Block, Contract, Extension, Library, Module and Plugin.
I'm actually thinking about renaming those as I feel that the naming convention might be extremely misleading.
I'll try to Wikify some thoughs over the weekend (If I can log-in on MoinFrigginMoin)
<snip2/>
Pier
