cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: [RT] Implementing Cocoon Blocks
Date Mon, 01 Sep 2003 16:06:02 GMT
Geoff Howard <cocoon@leverageweb.com> writes:

<snip/>

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

I don't think there is a complete set of solutions out there.  It's just
that things like automatic deployment, EAR/WAR/JAR expansion and
management, mechanisims for interpackage communications and aspect
interception are already part of JBoss.  It's a powerful set of
capabilities.  Also I suspect, but don't know for sure, that some of
what we want to do with blocks is probably easier if you have complete
interception capabilities, though perhaps that would mean turning the
concept of blocks inside out: inserting interceptions into code to gain
capabilities instead of looking up libraries to gain capabilities...

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

Yes.  I think what we'd provide initially would be JBoss compatible.  It
might run with other containers, but if so, that's only because we'd be
basic EJB 2.x compatible.

The problem with something like JBoss is that you can't simple add a
library to Cocoon and be done with it (like SAP).  Rather, you've got to
deploy Cocoon under JBoss, which, although somewhat simple, would likely
be best done with a new build target?  Something I'm not going to be
able to do at the moment...



Mime
View raw message