cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: Java components in blocks
Date Fri, 15 Apr 2005 13:04:23 GMT

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 

> <snip2/>


View raw message