[logback-user] JMX on a WebSphere clustered environment

[Christopher.White at bbh.com]

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.

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). 

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...
        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)
        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.


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:

This method behaves the same as newMBeanProxy(MBeanServerConnection, 
ObjectName, Class), but additionally, if notificationBroadcaster is true, 
then the MBean is assumed to be a NotificationBroadcaster or 
NotificationEmitter and the returned proxy will implement 
NotificationEmitter as well as interfaceClass. A call to 
NotificationBroadcaster.addNotificationListener(javax.management.NotificationListener, 
javax.management.NotificationFilter, java.lang.Object) on the proxy will 
result in a call to 
MBeanServerConnection.addNotificationListener(ObjectName, 
NotificationListener, NotificationFilter, Object), and likewise for the 
other methods of NotificationBroadcaster and NotificationEmitter.
Type Parameters:
T - allows the compiler to know that if the interfaceClass parameter is 
MyMBean.class, for example, then the return type is MyMBean.
Parameters:
connection - the MBean server to forward to.
objectName - the name of the MBean within connection to forward to.
interfaceClass - the management interface that the MBean exports, which 
will also be implemented by the returned proxy.
notificationBroadcaster - make the returned proxy implement 
NotificationEmitter by forwarding its methods via connection. 
Returns:
the new proxy instance.


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?



Thanks,
-Chris




From:   ceki <ceki at qos.ch>
To:     logback users list <logback-user at qos.ch>
Date:   05/30/2012 03:39 PM
Subject:        Re: [logback-user] JMX on a WebSphere clustered 
environment
Sent by:        logback-user-bounces at qos.ch




Chris,

Would sharing the configuration file by all instances be a possibility? 
If yes, you could probably get by with the auto-scan feature.

-- 
Ceki
http://twitter.com/#!/ceki

On 30.05.2012 20:50, Christopher.White at bbh.com wrote:
>
>
> Hi,
>
> I'm trying to use Logback JMX in my application to allow me to change
> the configuration at runtime.
>
> I've created client code that can retrieve the JMX bean, and am able to
> invoke the JMX bean to get/set logging levels.
>
> This works just fine on one single server. However, my application is
> deployed on a cluster of two servers. When invoking the JMXConfigurator,
> it only modifies the logging configuration on the particular server that
> I happened to connect to for that http request, but does not modify the
> configuration on the other clustered server.
>
> Am I missing something, or is there no way to have one JMX call update
> the logback configuration on all clustered servers? Am I perhaps
> retrieving the JMX bean incorrectly for a clustered environment? Any
> help would be greatly appreciated.
>
>
>
> Here is the client code I am using to access the JMX bean:
>
> String contextName = "myContextName";
> String objectNameStr =
> ch.qos.logback.classic.jmx.MBeanUtil.getObjectNameFor(contextName,
> JMXConfigurator.class);
> javax.management.ObjectName objectName = new
> javax.management.ObjectName(objectNameStr);
> javax.management.MBeanServer mbs =
> java.lang.management.ManagementFactory.getPlatformMBeanServer();
> mbean = javax.management.JMX.newMBeanProxy(mbs, objectName,
> JMXConfiguratorMBean.class, true);
> mbean.setLoggerLevel("myLogger", "debug");
>
>
>
>
> Thanks,
> -Chris

_______________________________________________
Logback-user mailing list
Logback-user at qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-user



*************************** IMPORTANT
NOTE*****************************-- The opinions expressed in this
message and/or any attachments are those of the author and not
necessarily those of Brown Brothers Harriman & Co., its
subsidiaries and affiliates ("BBH"). There is no guarantee that
this message is either private or confidential, and it may have
been altered by unauthorized sources without your or our knowledge.
Nothing in the message is capable or intended to create any legally
binding obligations on either party and it is not intended to
provide legal advice. BBH accepts no responsibility for loss or
damage from its use, including damage from virus.
********************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20120530/615946c2/attachment.html>