Return-Path: 
 <dev-return-73263-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 80833 invoked from network); 13 Apr 2005 13:42:32 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 13 Apr 2005 13:42:32 -0000
Received: (qmail 21062 invoked by uid 500); 13 Apr 2005 13:42:26 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 21039 invoked by uid 500); 13 Apr 2005 13:42:26 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 21021 invoked by uid 99); 13 Apr 2005 13:42:26 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Received: from smtp004.mail.ukl.yahoo.com (HELO smtp004.mail.ukl.yahoo.com)
 (217.12.11.35)
  by apache.org (qpsmtpd/0.28) with SMTP; Wed, 13 Apr 2005 06:42:24 -0700
Received: from unknown (HELO ?192.168.1.31?) (reinhard?poetz@62.178.239.20
 with plain)
  by smtp004.mail.ukl.yahoo.com with SMTP; 13 Apr 2005 13:42:20 -0000
Message-ID: <425D21BA.50100@apache.org>
Date: Wed, 13 Apr 2005 15:42:18 +0200
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Directory structure of blocks
References: <20050409083134.46541.qmail@minotaur.apache.org>
 <425A36D5.4010809@nada.kth.se> <425A3A7B.5030203@apache.org>
 <425A6B42.1040009@nada.kth.se> <425A7094.8040906@apache.org>
 <425A8A7A.1030203@nada.kth.se> <425A8EAF.7090502@apache.org>
 <255a9c1e1ee0934507a1f5447f3ef066@betaversion.org>
 <425BDF4B.8040705@apache.org>
 <3e1766b0f6774aa2f9b7a26a729043ae@betaversion.org>
 <425D1B51.4070100@apache.org>
In-Reply-To: <425D1B51.4070100@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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

Have you tried integrating Hibernate with 2.2 using the new sitemap classloader?

-- 
Reinhard P�tz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------