Inline: Jeff Genender wrote:
The config.xml allows us to declare new GBeans and override references and attributes of already existing Gbeans. But there is a missing configuration item here, which is the ability to *remove* a reference or attribute value from the configuration. Currently there is no way to do this.Matt Hogstrom and I ran into this when trying to remove a logging reference in one of the GBeans. An example of this is the TomcatValveChain on the TomcatEngine. As it stands, our default implementation installs an AccessLogValve into the TomcatValveChain reference. We wanted to shut off logging to test different performance numbers and found that there was no way to "clear" or remove a reference that was set in the car plan via the config.xml, without rebuilding the car from the source. On further discussion with David J and Dain, we came up with a new xml attribute to place on refs and attribute tags. You would use: empty="true" Example: You want to remove the access logger to improve web container performance, you would declare the following in the config.xml, which would remove the TomcatValveChain from the TomcatEngine: ... <configuration name="geronimo/tomcat/1.1-SNAPSHOT/car"> ... <gbean name="FirstValve" load="false"/> <gbean name="TomcatEngine"> <reference name="TomcatValveChain" empty="true"/> </gbean> ... </configuration> ... You would do the same for attributes that needed to be removed.
I'm not sure I get the relevance of empty=true. For instance, in the current config.xml there is no reference to the FirstValve as it is added when the car is built at assembly time. As a consequence, the end user (in this case me) had no idea that the FirstValve existed. So in the above exmple I think specifying load=false should be sufficient to disable the logging.
As a second note, if there had been several items in the ValveChain (some of which were created at assembly time) would the empty=true mean that all entries in the chain would be invalidated (and the FirstValve one also) would not be loaded?
From a user perspective we would want to expose this configuration attribute "logging" as a checkbox in the console so one could avoid editing the config.xml if possible. I'm probably missing something in how this all is wired together so apologies in advance if I'm on the same planet but a different world.
This fixes the problem we have with logging Jeff and this is awesome. As we talked this attribute will probably double our WebContainer performance. I think we need to go back through these configuration options and get them into the console. I'd volunteer but my plated overfloweth with good ideas and unfinished projects. Probably should add this to the what can I do list.
I have this all coded up and ready to check in, but wanted to get any feedback or issues before I went ahead and did it. Comments? Jeff
