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 http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111339143403364&w=2 ?
Yes
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 hard-bop.com
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
