Pier Fumagalli wrote:
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)
no problems for me.
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)
awesome.
I'm starting to like this separation more and more.
--
Stefano.