That's great. My current solution is to simply unregister that MBean in
my code when I stop a server (which works but is clearly a work
around). As soon as your solution is available, I will move up to a
newer version of Jetty.
I didn't think about using an MBeanContainer for more than one server
(I guess it never occured to me because of the jetty.xml description in
the Wiki). So I would use one static MBeanContainer per Jetty instance
(i.e. VM). I will put that on my list.
Greg Wilkins schrieb:
the problem is that the MBeanContainer should not be adding the log
Note that the solution is not to have Server.destroy remove the
log bean, as jetty servers have different lifecycles to the mbean server
and the logs.
The log is static and scoped to the JVM (or classloader)
The mbean server is long lived and may live over the life/death
of many jetty servers (possible at the same time).
The jetty-jmx.xml file is only a conveniance for when you
have 1 server only. It really should not tie the lifecycles together
as it does.
So the first part of solution is to not try to restart the MBean
container over a stop/start operation. You should let it stay
running. You may need to adjust your configuration for that.
The second part of the solution, which I have implemented in
trunk, is the break the hacked association between mbean
server and log. Log object have to be explicitly added.
However, I have made the MBeanContainer a lifecycle object,
so that you can associate its lifecycle with 1 server if you
wish, and the doStop will remove all known beans.
This is recorded in http://jira.codehaus.org/browse/JETTY-530
it is only in head/trunk at the moment - and I'll only move it
to a 6.1 branch/release if I get lots of positive feedback that
it does not break anything for anybody else.
Henning Blohm wrote:
I use jetty as an embedded server in some larger context (and I am
impressed by how well it can be embedded!).
Now, when using it with JMX instrumentation, I have problems applying
a configuration change at runtime (e.g. by a changed jetty.xml) as the class
does not unregister the MBean for the stderr log (added in the
public MBeanContainer(MBeanServer server)
this._server = server;
Logger log = Log.getLog();
and I get
WARN: bean: STDERR
The way I would wish to apply new configuration is by
server.stop(), stop and destroy all handlers, server.destroy(),
create new server, apply configuration, add new handlers.
It would actually be neat if, upon server.destroy() the whole
MBeanContainer would get destroyed (and unregister all MBeans) in any
case, as (I understand), the container associated with the server would
not be reused anyway.
Any advise on how to overcome this problem would be great!
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.