And this answer a previous question of where to commit the GBean implementation of the Logback Jetty RequestLogImpl for Geronimo. We should contribute it to Logback for inclusion in release X, then lobby Geronimo to support release X of Logback.
If GBean's are a Geronimo construct (I am unfamiliar with Geronimo) and the GBean in question just allows Logback's configuration to be dynamically updated I see no reason why this can't reside with Geronimo, unless it needs to modify existing Logback classes.
The GBean is a Geronimo construct, however if Geronimo does not bundle the Logback library in with it, then it seems ridiculous to include the GBean in Geronimo which depends on an external library not available in the Geronimo distro. Instead it makes more since to put it in the Logback distro. Logback implements the Jetty RequestLog, as RequestLogImpl. This implementation is in the Logback distro, not Jetty. Jetty does not incorporate Logback, so it would seem funny to give the implementation to Jetty unless they also agree to accept the Logback libraries into the distribution. On the other hand, if we implement a log4j version of RequestLog, that should go into the Jetty namespace, and not the Log4j namespace, as Log4j is distributed with Jetty. Overall, I agree with you. It would seem logical that the RequestLogImpl (of Logack) be distributed as part of Jetty, and the GBean wrapper for it distributed with Geronimo, but if Jetty and Geronimo do not bundle the Logback library, I do not see that as making sense. -RG