geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: GBeans representing separately persistent data
Date Mon, 12 Jun 2006 18:09:46 GMT
On Jun 12, 2006, at 10:44 AM, Jeff Genender wrote:

> Dain Sundstrom wrote:
>> I think the problem here is the GBean framework is not flexible  
>> enough
>> to support this.  The integrations of Tomcat, Spring, ServiceMix, and
>> ActiveMQ have been extremely painful and have resulted in (no  
>> offense)
>> very limited integrations.
> No offense taken.  Painful is an understatement ;-) But, what's  
> limited
> about them?  From the Tomcat perspective, I believe we support nearly
> all Tomcat objects as well as have enhanced features, such as the
> ability to run 2+ full Tomcat containers at the same time under one  
> house.

My knowledge of the Tomcat integration is limited, but from what I  
understand the integration is limited to what we put in out GBean  
wrappers.  From you statements, it sounds like we have full Tomcat  
support, but every time they add a new feature we have to update the  
wrappers.  In the case of AMQ, the integration is very limited.  AMQ  
supports configuration from the very simple (what G supports) to very  
very complex.  The complexity scale is sliding based on how much  
detail you put in your spring.xml file.  It is also very easy to  
extend their broker using standard spring concepts.

> Do you have suggestions on what can be done to make the  
> integrations better?

Yep.  It is mostly the list of stuff Hiram has been asking for for 2  

- No proxy
- No GBeanInfo
- No Serialization

and a few I have been thinking about

o Factory bean support
o Infinitely complex configurations (a.k.a nested GBeans or spring-like)
o Module contract which allows for multiple module types (not just  
Geronimo's current Configuration class)
     - Pluggable class loader creation
     - Pluggable life cycle
     - Pluggable construction
     - Pluggable management

> With that has been difficult having the GBean wrappers
> up-to-date with changes in the Tomcat APIs.  I would have much rather
> plugged in the container and leveraged Tomcat as much as  
> possible...but
> I digress...

Nope, that is my point.  GBeans are simply too inflexible and we need  
to plot a path out of here :)

>> The approach Aaron has laid out is in my mind the best given the  
>> current
>> technology, but I'd rather not see us go down the path of adding more
>> deployers.  The deployers are the major thing holding back  
>> integration
>> of XBean (this is why I rearchitected OpenEJB deployment in  
>> dead-1.2).
>> Then again, if I were you, I don't think I would believe that a XBean
>> integration is ever coming.
> Again, as long as his Job GBeans do not prevent one from using the
> generic Quartz API to create jobs, then I am fine with it.

I want out framework to be able to support Services like the Quartz  
Job.  You should be able to expose the Job to the kernel so it can  
participate in livecycle, management, and references, but that should  
not come at the cost of giving up construction, or managing your own  

Anyway, with the current technology, I don't think the Job service  
should be a GBean.


View raw message