cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: [RT] Implementing Cocoon Blocks
Date Mon, 01 Sep 2003 15:51:03 GMT
Hunsberger, Peter wrote:

> Geoff Howard <> writes:
> <snip/>
>>But this brings up another point - what to do if the wiring.xml and 
>>others is deleted?  Presumably, all blocks are "uninstalled" in this 
>>state, but what does this do to persistence requirements.
>>Also, how to recreate the deploy step efficiently?  For example:
>>You deploy a block with some dependencies and configuration.  
>>The block 
>>deploy process walks you through setting configs and resolving 
>>dependencies.  You then have no record of these deployment choices 
>>except in wiring.xml which is not meant for human 
>>consumption.  Perhaps 
>>it would be good to record these human-step deployment time 
>>configurations in a conf file which could be easily reprocessed to 
>>easily re-deploy all blocks to their last configuration.
> The more I  watch this discussion go by the more I feel like Cocoon is
> reinventing JBoss. The more I watch the Aspects discussion go by the
> more I feel like Cocoon is reinventing JBoss.  Too bad JBoss isn't a
> container that we can just pick up for Cocoon and count on....

Maybe, but is there really anything (reusable) out there for such an 
amorphous thing as a block?  It's not (just) classloading or 
component/service location because some of the things a block can expose 
is a file or more generic "behavior" which will in some cases be very 
specific to Cocoon.  This assumption should of course be challenged - 
anyone see places we are unnecessarily reinventing the wheel?

> BTW, On the same issue more or less: I don't think you ever responded to
> my question on what to do for a container for EJB samples supplied with
> Cocoon?  (Still trying to get permission to contribute our code.)

Sorry, must have missed that.  Can you remind me - were we talking about 
how to deal with the fact that an EJB example would rely on an EJB 
container which we don't provide?

Off the top of my head I'd say it's just like the SAP and other 
component(s) which rely on external dependencies we can't or don't ship. 
  If the examples can be provided in a container-neutral way, that's the 
best option of course.  Assuming that's not practical, I'd say start 
with what we have and over time perhaps we can accumulate 
container-specific versions.  If we have to tailor to one at the start, 
JBOSS is probably the best as it's at least available to everyone.

Am I on the right discussion?


View raw message