cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Java components in blocks
Date Fri, 15 Apr 2005 13:38:33 GMT
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)


I'm starting to like this separation more and more.


View raw message