cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <>
Subject Re: Java components in blocks
Date Tue, 19 Apr 2005 14:45:33 GMT

On Apr 18, 2005, at 12:07 PM, Daniel Fagerstrom wrote:

> 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 
> ?


>> 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?

I admit that this is a problem. The way I see this, is that if a block 
developer is using a jar that may have multiple versions deployed in 
the cocoon environment they should make sure to deploy that jar local 
to a sitemap.

>> 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.

Agreed. Certain jars should be available cocoon wide and others not. 
Unfortunately, this must be left up to the blocks developer to decide 
how a particular jar gets deployed. Just as it is now.

> 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.

I know so. I didn't say it would be easy.

> Things get more complicated and creates IMO unnecessary dependencies 
> between blocks when you combine it with sitemap functionallity.

How so? What is the alternative? Have blocks that have no component 
dependencies? If a block depends on a component it depends on a 
component. If a sitemap uses a component it uses a component.

> Because of that complexity Pier and I prefer to separate the problems.

If you separate the problems thats fine with me, but to consider this a 
complete solution to the total problem which is to have real blocks is 
a mistake. When I deploy an app, I usually have a custom component or 
two and a bunch of POJOs. If I want to package an app as a block I 
would need to package the sitemap and associated files as a block and 
package the jars as a bundle. A block at the very least should include 
the bundle. As an app developer I want to have a single deployment 
solution.  As a sys admin, I want to ensure that I don't have 30 copies 
of identical jars hanging around.

I understand that this is a complex problem and breaking it up into 
smaller pieces is a wise thing to do. My basic points are that to have 
real blocks you need a single deployment and that there are two levels 
to deploy Java components, global and sitemap, parent sitemaps 
included. Initially, to have the choice of deploying Cocoon wide or 
sitemap wide solves some basic issues. The ultimate solution is much 
more difficult because of the multiple dependencies a block may have. 
It may be that it is impossible to solve all possible scenarios. I 
don't know.

Glen Ezkovich
HardBop Consulting
glen at

A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow

View raw message