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] Some notes about the "Real Blocks" issue
Date Fri, 15 Oct 2004 14:22:28 GMT
Ugo Cei <> writes:

> Il giorno 13/ott/04, alle 18:59, Ugo Cei ha scritto:
> >     - [ ] Geronimo/JMX?
> >               This thread:
> >                
> >
> >               might provide some suggestions re the
> >               implementation of the kernel.
> I just came upon this interview with Aslak Hellesoy on The 
> Server Side  
> < 
> textFull.html>. It was published a few days ago but I hadn't seen it  
> yet. I'll paste a brief quote:
> "[The Geronimo developers] have been thinking about this 
> since they've  
> been writing the thing, that if you think about Geronimo as 
> the outer  
> container, if you think of it as a bucket. They have a lot of 
> goodies  
> in that bucket, like connection pooling, transaction management,  
> integration with messaging systems and all that. And if you think of  
> that bucket in a classical J2EE container, in order to benefit from  
> these things, you have to stick in something that looks like a J2EE  
> component.
> What they are actually doing is, they are sticking a smaller bucket  
> inside that, that sort of acts as a glue between Pico and 
> Geronimo. So  
> let us say I am writing this component that needs, for example, a  
> connection pool. Now what I can do, I can write my class and I could  
> say in constructor, I could say I want a connection pool. I 
> can drop it  
> inside Pico, which is inside Geronimo now, and Geronimo will give it  
> the connection pool, so it is simple."
> I find this is very similar to what we're trying to do with the new  
> kernel. And it works with Spring as well as with Pico.
> Now the question is: can a Cocoon block be a GBean? And if it can,  
> should we either:
> 1. Borrow some ideas from Geronimo and do our own thing?
> 2. Borrow some code from Geronimo and adapt it to our needs?
> 3. Build a "lightweight" version of Geronimo (no J2EE stuff, just  
> servlets) to use as our kernel?
> 4. None of the above?

Not sure of the answer to you question, but it seems to me that if
someone wants J2EE capabilities then they should just be running inside
a J2EE container.  

What would be interesting is if there was a way Cocoon to adopt to any
form of external container.  For Jboss you've got Mbeans and Geronimo
you've got Gbeans.  Basically, you'd need an container adaptor for each
container. Presumably, then you could build a version of CLI that worked
the same way. At that point, some of the issues discussed in this thread
could become external concerns: if you want hot deployment you'd have to
be using an external container that supported such and had a mechanism
for signaling back to Cocoon (Eg, Jboss and Mbeans, if not others) when
a related component was deployed.

Doing this for multiple external containers is probably way too much
generalization for the real needs of Cocoon, but as has been pointed out
before, everyone everywhere is attacking portions of this problem and
inventing a Cocoon only solution seems a bit counter productive.  The
lessons of Avalon shouldn't be forgotten, but the communities building
containers have matured a lot in the last couple of years.  Maybe I'm
just too optimistic in believing there should be container
implementations mature enough for Cocoon to depend on?

View raw message