[logback-user] JMX on a WebSphere clustered environment

[ceki]

On 30.05.2012 23:00, Christopher.White at bbh.com wrote:
> Thank you for the reply.
>
> When you say "sharing the configuration file by all instances", do you
> mean having both servers point to the same logback.xml config file? If
> this is what you meant, I'm not exactly sure how I could use this to my
> advantage, perhaps you could elaborate more on this suggestion.

Any change to that file would be automatically picked up by all 
instances. The only downside is that it would require editing by the 
admin. If the admin makes an error editing so that the resulting XML 
file is not well-formed, logback would fallback to the previous 
well-formed config.

> My ultimate goal is to give the end user of my web application (with an
> admin role) the ability to change the logging level of any logger at
> runtime (and have this change applied to both servers in my cluster).

OK.

> Is it possible, in java code, to modify the logging level of a logger,
> and then save the modifications back to the original logback.xml
> configuration file? If this is possible, then I can see how your
> suggestion could help me...

No, there is no support for editing the config file at runtime. However, 
the config separation idea could work (read below).

> 1. End user submits request for change in logging level on some logger
> (which is received by server 1)
> 2. Application code uses Logback API to make the desired changes at runtime
> 3. Application code uses Logback API to save the current runtiime
> configuration back to logback.xml (still on server 1)

You could separate appender configuration and logger level configuration 
into separate files [1]. The main file would define appenders and would 
include the logger level file which you could maintain programmatically 
(just dump the logger level settings to the logger level config file 
upon change).

[1] http://logback.qos.ch/manual/configuration.html#fileInclusion

> 4. Server 2 is also looking at the same logback.xml file (with auto-scan
> enabled). Once the file is updated, the auto-scan will trigger on server
> 2, and the logging level changes will then be applied to server 2 as well.

Right. Auto-scan works over included files as well.

> Before I go too far with the above approach, I just have a follow-up
> question to using JMX. Here is the code snippet that I am using to get
> the mbean proxy instance:
>
> mbean = javax.management.JMX.newMBeanProxy(mbs, objectName,
> JMXConfiguratorMBean.class, true);
>
> The last parameter is set to "true", which is supposed to enable
> broadcasting of the message (to other Mbeans on the MbeanServer I
> assume) if the Mbean happens to implement NotificationBroadcaster. Based
> upon some reading on other forums, I think this is how JMX can be used
> to propagate the message to all servers in the cluster.
>
> Here is the excerpt from the Javadoc:

[snip]

> Does the Logback JMX Mbean implement NotificationEmitter or
> NotificationBroadcaster? If not, do you think that if it did implement
> one of these interfaces, that my issue would be resolved?

I barely understand what you are talking about so I am unable to help.

> Thanks,
> -Chris
-- 
Ceki
http://twitter.com/#!/ceki