cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Java components in blocks
Date Sat, 16 Apr 2005 12:56:41 GMT
Torsten Curdt wrote:
>>Reading these discussions after the fact, having Blocks provide only
>>sitemap components seems to make a lot of sense
> ...not to me - sorry. But maybe I just missed something.
> Pier is totally right: we have two different concerns.
> One is the pipeline services interface and one is the
> component interface of a block.
> But reducing a block just to it's pipeline services basically
> gives us virtual sitemap components on steroids. What about
> its dependencies? Well, IIUC one argument in this discussion
> was that the dependency will be satisfied through a pipeline
> service - not through a component.
> Block A:
>  provides: a pipeline service to transform xml
>  requires: a pipeline service to transform xml with a STX stylesheet
> Block B:
>  provides: a pipeline service to transform xml with a STX stylesheet
> So block B does not provide the component with
> hint "stx" but a service that could be anything
> doing the job satisfying the dependency. Ok.
> Now what about the component dependencies? Let's
> say in order to implement the "transform-via-stx"
> service block B requires a component of hint "stx".
> Since the block B has its own component manager
> and the component "stx" being declared in the block's
> sitemap all is left is a java class level dependency
> to the stx implementation. Now the question is - will
> the block B provide the stx jar? Let's say yes for the
> moment.
> So what if the "transform-via-stx" component needs
> another component? We could list all the required
> component in the components section for that very block.
> ...but still the classes need to be available!
> What if the classes are in a different block?
> Essentially this means to me: As long as we don't want
> to ship every block with every component it requires
> I cannot see how we can get around of having blocks
> also expose component services.

The idea is that if you have a component that you want to be able to use 
in several places, you package it in a certain way. Then the improved 
component handling system that Pier feel the itch to build can found its 
jar in some repository somwhere, reolve its dependencies and offer a 
shielded parent classloader with the depndencies you have asked for.

I don't know the exact details about Pier's vison about this, but you 
can take a look at the kernel in whiteboard for part of it and Maven is 
also a part of the equation for downöloading and dependency reolution.

Then the responsibility for blocks is to deliver sitemap functionality 
rather than components. A block declare what components it depend on and 
the component system takes care of that part for it. It will, at least 
in my vision, be possible to put Java code and components within the 
block that only is intended for block internal usage.

                        --- o0o ---

So the situation rigth now is that Pier have the itch to start integrate 
improved component handling with classloader shielding ito Cocoon. And I 
have the itch to start building the sitemap part of the original blocks 
proposal (actually I have even started on it although nothing is 
committed yet).

For the time beeing we are going to *assume* that is is separate 
concerns, although the blocks system will use the component system. In 
this way we reduce the complexity to a point where we feel comfortable 
to actually do things, and get experince from that, instead of spending 
a couple of more years on just discussing them.

In a next step, anyone who feel that it is necessary can integrate the 
two parts as it was intended originally. My hope is that we don't feel 
the need, as it IMHO is mixing two different architectural levels and 
it, according my current state of knowledge, means that we are creating 
a complexity nightmare for ourselves.

Also letting the block depend on each other in the way that they can 
export any interface and jar, means that they get a very tight coupling 
and all kinds of version problems. I can't see that it is scaleable to 
the level where different organizations develop blocks independently, 
that users easily can integrate.

                        --- o0o ---

But this is just my view, if you feel that it is FUD and that is is much 
easier than I say, it is just to go ahead and propose better ideas and 
maybe even implement them ;)


View raw message