cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Classloading in blocks [was; Binaries for next releases]
Date Sun, 09 Oct 2005 11:33:33 GMT
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).


* I/we know, it's unofficial so far as it hasn't been discussed on the mailing list.


Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:

View raw message