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 one...it 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 done...to leverage the console administration...but this helped cause the pain of keeping the GBeans up-to-date with the Tomcat attributes/API. >> With that said...it 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 ;-) Jeff
