geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: GBeans representing separately persistent data
Date Mon, 12 Jun 2006 19:52:34 GMT

Dain Sundstrom wrote:
> 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.  

Yep...kinda-sorta.  But its not limited.  The GBean integration that I
put together attempted to make the Tomcat components, or use of them, as
flexible as possible.  This is the "initParams" attribute in nearly all
of our GBean wrappers and the ability to declare the class name as a
string that is passed to the wrapping GBean.   The initParams allows us
to pass name/value pairs to the GBean of any arbitrary kind that matches
up with the class. Its "almost" as flexible as digester.

The "inflexible" part was forcing types on the GBeans.  Example are the
different connector GBeans.  The ConnectorGBean is the most flexible allows you to declare any kind of connector.  But in order to
do the management with the console, folks started creating hardened
attributes and extending the ConnectorGBean to HttpConnector..etc.
This, IMHO, made it much more inflexible. I understand why it was leverage the console administration...but this helped cause
the pain of keeping the GBeans up-to-date with the Tomcat attributes/API.

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

I couldn't agree more ;-)


View raw message