cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: Directory structure of blocks
Date Wed, 13 Apr 2005 15:12:39 GMT
On 13 Apr 2005, at 14:14, Carsten Ziegeler wrote:
> Pier Fumagalli wrote:
>> <SNIP/>
>> If on the other hand we separate entirely components and java code 
>> from
>> blocks, the implementation becomes _much_ more easy...
>> My idea would be that a block (for example, our ForrestSkin
>> implementation) _requires_ a component (not a block) that performs 
>> transformations.
>> Requiring this, it will expose (for example) a "Virtual Transformer"
>> called "document2html" which will be implemented as XSLT Transformer +
>> document2html.xslt.
>> Another skin for forrest could (at the same time), implement the same
>> interface and provide the same "document2html" transformer by 
>> requiring
>> the STX transformer and "joining it up" with "document2html.stx".
>>  From outside, the two blocks _both_ provide a transformer, which does
>> exactly the same job, but rely on the component manager underneath to
>> solve the class loading problem of providing a component with a given
>> role, add their value to it (the XSLT, STX, ... stylesheet) and expose
>> it to the users of the implemented interface.
>> And this frees up the blocks implementation from the underlying
>> component management, java, class loaders and so on... I feel this a
>> lot more cleaner in terms of separating the concerns of cocoon and
>> blocks versus the concerns of the Java platform and its classloading
>> cumbersomeness...
> Where do the components life and where are they defined?
> I'm not sure if I totally understood everything discusses so far, but
> imho we need some versioning: we recently had the following problem. In
> a cocoon application we used Hibernate that requires the version 1.4.x
> of the asm jar file. With Cocoon 2.1.7 we ship version 1.5.x which
> causes some method not found exceptions inside hibernate :( Ok, now we
> could lean back and blame the developers of asm creating incompatible
> versions, but I think this is a general issue. What if one component
> requires version 2.x of a third party lib while another one requires a
> 1.x version. Etc.
> Fortunately, we could solve this problem in our solution by just using
> asm 1.4.x as we don't need the BSF block.
> Ok, long story, short question: do we plan to support such scenaries
> with real blocks? I really hope so :)

Absolutely we do, but not in the very first phase of blocks. Blocks, in 
my view, addess separate concerns from the classes they require for the 
implementation of the virtual sitemap components that they expose to 
other blocks.

At the beginning, and that's what we agreed a couple of months ago, we 
completely disregard all those classloading issues by implementing the 
block paradigms without touching those, as those concerns will have to 
be addressed by the component manager underlying the whole systems.

But re-adding libraries and classes into the pictures, tells us that we 
do _now_ have to think about the class-loading issues, and multiple 
versions of same interfaces, multiple versions of classes and so on...

Making the whole process a load more complicated from the outset, and 
when (IMVHO) class-loading and cocoon block deployments are two 
completely separate concerns...


View raw message