Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4263E96B.9070504@nada.kth.se>
Date: Mon, 18 Apr 2005 19:07:55 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Java components in blocks
References: <20050409083134.46541.qmail@minotaur.apache.org>
 <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>
 <425D0549.80401@apache.org>
 <9c28f5a45d1ec41b74503c823fa64351@betaversion.org>
 <425D5202.6050001@reverycodes.com>
 <c7fe51acb43d85bc70f9d75149201807@betaversion.org>
 <425E34D8.1070800@nada.kth.se>
 <394529d891516efa895dc2746c77cf58@betaversion.org>
 <425E8B81.3040105@apache.org> <425E8D37.7030106@dslextreme.com>
 <0f996695454c3cc853208a9a66041284@apache.org> <4260FA7A.8030001@apache.org>
 <42610B89.4060208@nada.kth.se>
 <ff2f18d8a42fe961c0daccbc0f090379@betaversion.org>
 <42628446.9000502@dslextreme.com> <42629EB8.4050500@nada.kth.se>
 <42634FE1.3030503@dslextreme.com> <4263A29B.2060804@nada.kth.se>
 <b1cf4e13caa35058211bb8e4bc16a47b@hard-bop.co!
 m>
In-Reply-To: <b1cf4e13caa35058211bb8e4bc16a47b@hard-bop.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Glen Ezkovich wrote:

>
> On Apr 18, 2005, at 7:05 AM, Daniel Fagerstrom wrote:
>
>>>
>>> The portal definition files define how individual portlets are 
>>> invoked and rendered.  As I stated before, ideally these would be 
>>> separate blocks. However, since many will contain java code, it 
>>> sounds like many portlets would have to be a block with a matching 
>>> bundle.
>>
>>
>> A block can contain code. It is just (at least in the first step) not 
>> allowed to expose components. So if the portlet components need to be 
>> accessible from other parts of the system you need both a bundle and 
>> a block. But if the components only are needed internally and the 
>> portlet can expose all its functionality as pipeline functionality, 
>> it is enough with a block.
>
>
> Sorry to be late to the party, but I was unsure where this discussion 
> was headed and choose to keep my mouth shut. I'm glad to see to that 
> blocks can have code again.;-)  I think the issue of exposing 
> components is a non issue.

Did you read 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111339143403364&w=2 ?

> We are after all talking about java byte code, if some one wants to 
> use the jar/class file it just needs to be on the classpath.

Sure, but what if two blocks contain different versions of a jar?

> The issue here is one of deployment, where to locate the class and 
> which ClassLoader will load the class. It seems to me that if we have 
> two component deployment levels, global and sitemap, we can pretty 
> much accomplish the same thing as exposing or not exposing components.

If all jars from all blocks are put in a global sitemap it just don't 
scale. It is hard enough to keep jars in different blocks in synch 
whithin the Cocoon SVN. When external developers start to develop and 
distribute their own blocks it will stop working.

Because of that classloader isolation is needed so that a block only is 
exposed to the classes it actually depend on from its parent 
classloader. And that is complicated stuff, if you don't think so you 
can take a look at kernel in whiteboard. Things get more complicated and 
creates IMO unnecessary dependencies between blocks when you combine it 
with sitemap functionallity. Because of that complexity Pier and I 
prefer to separate the problems.

/Daniel