cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Java components in blocks
Date Thu, 14 Apr 2005 12:32:50 GMT
Pier Fumagalli wrote:

> On 14 Apr 2005, at 10:16, Daniel Fagerstrom wrote:
>> Pier Fumagalli wrote:

>>> As far as I've understood Cocoon blocks (and I might be _ENTIRELY_ 
>>> wrong here) Cocoon blocks do not expose (for example) an XSLT Java 
>>> transformer, but expose a transformer converting a specified format 
>>> into another.
>> AFAIU, you are entirely wrong ;)
> Ha... I read this differently, then... (Subject: Re: Planning Cocoon's 
> future)
> On 23 Nov 2004, at 19:32, Stefano Mazzocchi wrote:
>>>> Are there any reasons not to make Pier's kernel the official base 
>>>> of Cocoon 2.3? If not, Pier should have the "permission" to move 
>>>> its kernel into an offical 2.3 directory in  our SVN whenever he 
>>>> thinks it's time for it. (... I prepare a vote after the discussion)
>>> If the kernel is stable, should it really be 2.3 or can it be 2.2?
>> my suggestion would be: leave the kernel out and let's keep working 
>> on allowing us to deploy and ship the blocks in binary format.
>> classloading isolation will happen later, when the need will be 
>> impossible for people to avoid ;-)
> My mishap? Misinterpretation? Or just one of my usual brainfarts??? :-P

I interpreted it as no classloader isolation rather than total 
classloader isolation. Anyway, lets focus on what we want rather on what 
people possibly thought once. We'll get a current update of peoples 
opinons soon enough ;)

>> considering what have been discussed before. Neither the less, what 
>> you propose makes perfect sense to me. My idea was to start 
>> implementing the pipline part of the blocks management system, as we 
>> IMO understand enough about it to be able to work on that. Then add 
>> the possiblity to expose components and take care of class loader 
>> issues in a later step.
> On this you have my +1... Also because, I've been looking at a little 
> tool called "Maven" :-P That already tells us the dependancies of one 
> particular library against others... By using the (let's assume) 
> "httpclient-x.y.z.jar" from Maven, the maven descriptor file _already_ 
> tells us this "library" dependancies.
> We can wrap the library into a "block" (or proto-component), and use 
> the maven descriptor file to calculate dependancies, and use those as 
> instructions to build the classloader structure required by (but 
> separate from) blocks.

Given that you synchronize it with Reinhard who has worked on a block 
builder, you have my +1.

>> 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 :)

> 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.

Is it based on the whiteboard kernel? 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.

>>                                                     --- o0o ---
>> Ok, taking a look at the technical issues. IIUC, the problem that you 
>> describe does not depend on whether a block contains Java classes or 
>> libraries or not. The problem appears as soon as a block tries to 
>> expose a component. Then the user of the component must have get all 
>> the eposed interfaces from its parent classloader. And when we add 
>> mutual dependencies between blocks and different versions of the 
>> interfaces, it start feeling more like headache than fun.
> PRECISELY, you got this spot on...
>> So let's take a look at some different levels of block issolation, 
>> and their properties (the pipeline is exposed in all cases):
>> 1. No component exposing
>> ------------------------
>> The block doesn't expose any components at all, not even VPCs. The 
>> block can still contain as much own Java code as it want. It gets a 
>> parent classloader with the core Cocoon functionality and adds it own 
>> classes in its own classloader. The block must obviously be 
>> compatible with the Cocoon core, but there are no version 
>> interdependencies on the Java level between blocks.
>> It can even expose its classloader to extending blocks without 
>> problems. The extending block must of course be compatible at the 
>> Java level with the extended one, but still no circular dependencies.
>> We can package the VPCs as (block) web services (ws) instead with:
>> VPCReader      - Stream -> Stream ws
>> VPCGenerator   - Stream -> XML (SAX) ws
>> VPCTransformer - XML -> XML ws
>> VPCSerializer  - XML -> Stream ws
>> by making the block protocol competent enough and introducing 
>> pipeline components that talk with the corresponding ws, we get 
>> something that works like and is as efficient as VPCs.
> And this can be achieved with the running ECM+++ by Carsten, as every 
> sitemap _HAS_ its own classloader. No need to change the underlying 
> implementation until we have a final solution, right?


>> 2. Exposing VPCs only
>> ---------------------
>> Like the previous alternative but exposing VPCs. If we go for this, 
>> Sylvain's proposal about separating VPCs from other componsnts in the 
>> sitemap is preferable IMO.
> I like this approach, but should be combined with the previous one.

That was my intension.

> ECM+++ already provides isolate class loaders for sitemaps (and 
> therefore blocks). The idea of exposing VPCs only is that an XSLT 
> transformer is nothing without its stylesheet.. A I18N transformer is 
> nothing without its catalog file.
> Now, the transformers, serializers, generators, blablabla, EXPOSED by 
> a block must be _full_ components ready to implement a contract saying 
> (for example) transform an XML in the "book.dtd" into a XML in the 
> "xhtml11.dtd". You want to write it in JAva? Native C code? Xalan + 
> XSLT? That's not a problem, but what is exposed is not a class, it is 
> an implementation of the o.a.c.Transformer interface converting 
> "book.dtd" into "xhtml11.dtd".

Exactly, although I think we should do the schema part optional. In the 
end I think that blocks that declare their piplines with schemas will be 
much more robust, testable and usefull. But we don't have much 
infrastructure for that in place yet.


>> IMO, we should start simple and add functionality when needed. Remove 
>> things is much harder. Also even if we chose to go for alternative 4. 
>> an important message from Pier that we should take into account is 
>> that component exposure adds complexity. So if we go that way, we 
>> should have mechanisms that so that we can have detailed control over 
>> what components and classes a block exposes. A block that exposes 
>> much will be much more likely to create conflicts with other blocks.
> Glad that we have agreement on this! :-D



View raw message