cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Classloading in blocks [was; Binaries for next releases]
Date Sun, 09 Oct 2005 16:31:13 GMT
Shouldn't we make these decisions on this list in the public? Not every
committer was at the GT and took part in the discussions.


Reinhard Poetz wrote:
> Niclas Hedhman wrote:
>>On Sunday 09 October 2005 01:43, Reinhard Poetz wrote:
>>>I'm working on the classloader
>>>part so that a block can come with its own classes.
>>Curious to know what this is... or if it is a matter of lack of understanding 
>>of the OSGi classloader.
>>Is there any additional classloading needs that can't be satisfied with the 
>>OSGi classloader mechanism?? Would indeed be interesting to know for the 
>>Felix development as well.
> At the GT we had some kind of agreement, at least after Daniels presentation on 
> blocks, that we go for a two-step roadmap to get 'real' blocks*:
> - Cocoon 2.2 will not use OSGi but will support blocks as far as possible:
>    - blocks protocol (= sitemap blocks)
>    - a block gets its own component manager that contains all local components
>      and gets the block component managers of all wired blocks as parent.
>    - we use M2 as build and deployment tool (needs some special M2 plug-ins
>      for the deployment part)
>    - blocks are *not* spread over different directories during deployment
>    - a block can contain classes in [block]/BLOCK-INF/classes that are added
>      to the context classloader
>    --> this means that everything, that real blocks promise, works except the
>        shielding of Java classes.
> - Cocoon 3.0 will use OSGi
> So the answer to your question: We need this classloading only to load classes 
> from within 2.2 blocks. 3.0 will make this 2.2 classloading stuff obsolete 
> (hehe, my favorite word these days).

Carsten Ziegeler - Open Source Group, S&N AG

View raw message