cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [RT] Implementing Cocoon Blocks
Date Mon, 15 Sep 2003 15:16:21 GMT
Stefano Mazzocchi <> writes:

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

My comments where more wistful/rhetorical than anything else.   However,
the one thing we might want to look at is how JBoss implements
interceptions.  In particular, it has an XML configuration file that can
be used to specify how any Java code running under it is intercepted
(and in fact the interception engine is independent of JBoss).  Even if
we can't use the JBoss code perhaps we can support the same format for
configuring interceptions?

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

Given how slowly getting permission to release our code is crawling
along that might actually happen first (sigh)...

View raw message