RE: [RT] Implementing Cocoon Blocks

["Hunsberger, Peter" <Pe...@stjude.org>]

Geoff Howard <co...@leverageweb.com> 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....

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

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard <co...@leverageweb.com>]

Hunsberger, Peter wrote:

> Geoff Howard <co...@leverageweb.com> 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?

Geoff

Re: [RT] Implementing Cocoon Blocks

[Geoff Howard <co...@leverageweb.com>]

Reinhard Poetz wrote:

> From: Hunsberger, Peter
> 
> 
>>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.)
> 
> 
> I would really like to see some EJB examples in Cocoon. IMO we should
> create an "ejb-samples" block that contains them. Additionally we can
> create a "j2ee-container" target for Ant that prepares everything (.ear
> file) for deployment. We can't ship JBoss because of its license.
> 
> What do you think?

Perfect.

Geoff

RE: [RT] Implementing Cocoon Blocks

[Reinhard Poetz <re...@apache.org>]

From: Hunsberger, Peter

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

I would really like to see some EJB examples in Cocoon. IMO we should
create an "ejb-samples" block that contains them. Additionally we can
create a "j2ee-container" target for Ant that prepares everything (.ear
file) for deployment. We can't ship JBoss because of its license.

What do you think?

Reinhard

Re: [RT] Implementing Cocoon Blocks

[Stefano Mazzocchi <st...@apache.org>]

On Monday, Sep 1, 2003, at 16:59 Europe/Rome, Hunsberger, Peter wrote:

> Geoff Howard <co...@leverageweb.com> 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.

you are noting convergence of applying the same patterns onto two 
different domains. all operating systems have a file system, but this 
doesn't make them all the same thing.

> The more I watch the Aspects discussion go by the
> more I feel like Cocoon is reinventing JBoss.

same convergence again. all server side environments have crosscutting 
concerns, that will require similar solutions.

> Too bad JBoss isn't a
> container that we can just pick up for Cocoon and count on....

I would be very glad to use something that already exists rather than 
reinventing the wheel. but I really see no way on making cocoon work on 
top of jboss and apply its modularization facility to polymorphic block 
deployment and its AOP framework on allow our continuation-based 
flowscript to be interceptable.

if you have any idea on how to do this, I'm all ears. even if the point 
is academic since we can't ship jboss with cocoon.

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

we can't ship jboss since it's LGPLed. this is not going to change in 
the future.

we can wait for Geronimo to get real.

--
Stefano.