<font size=2 face="sans-serif">Thank you for the reply.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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). </font>
<br>
<br><font size=2 face="sans-serif">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...</font>
<br><font size=2 face="sans-serif">        1.
End user submits request for change in logging level on some logger (which
is received by server 1)</font>
<br><font size=2 face="sans-serif">        2.
Application code uses Logback API to make the desired changes at runtime</font>
<br><font size=2 face="sans-serif">        3.
Application code uses Logback API to save the current runtiime configuration
back to logback.xml (still on server 1)</font>
<br><font size=2 face="sans-serif">        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.</font>
<br>
<br>
<br><font size=2 face="sans-serif">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: </font>
<br>
<br><tt><font size=2>mbean = javax.management.JMX.newMBeanProxy(mbs, objectName,
JMXConfiguratorMBean.class, true);</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>Here is the excerpt from the Javadoc:</font></tt>
<br>
<p><font size=3>This method behaves the same as </font><a href="http://docs.oracle.com/javase/6/docs/api/javax/management/JMX.html#newMBeanProxy%28javax.management.MBeanServerConnection,%20javax.management.ObjectName,%20java.lang.Class%29"><tt><font size=3>newMBeanProxy(MBeanServerConnection,
ObjectName, Class)</font></tt></a><font size=3>, but additionally, if </font><tt><font size=3>notificationBroadcaster</font></tt><font size=3>
is </font><tt><font size=3>true</font></tt><font size=3>, then the MBean
is assumed to be a </font><a href=http://docs.oracle.com/javase/6/docs/api/javax/management/NotificationBroadcaster.html><tt><font size=3>NotificationBroadcaster</font></tt></a><font size=3>
or </font><a href=http://docs.oracle.com/javase/6/docs/api/javax/management/NotificationEmitter.html><tt><font size=3>NotificationEmitter</font></tt></a><font size=3>
and the returned proxy will implement </font><a href=http://docs.oracle.com/javase/6/docs/api/javax/management/NotificationEmitter.html><tt><font size=3>NotificationEmitter</font></tt></a><font size=3>
as well as </font><tt><font size=3>interfaceClass</font></tt><font size=3>.
A call to </font><a href="http://docs.oracle.com/javase/6/docs/api/javax/management/NotificationBroadcaster.html#addNotificationListener%28javax.management.NotificationListener,%20javax.management.NotificationFilter,%20java.lang.Object%29"><tt><font size=3>NotificationBroadcaster.addNotificationListener(javax.management.NotificationListener,
javax.management.NotificationFilter, java.lang.Object)</font></tt></a><font size=3>
on the proxy will result in a call to </font><a href="http://docs.oracle.com/javase/6/docs/api/javax/management/MBeanServerConnection.html#addNotificationListener%28javax.management.ObjectName,%20javax.management.NotificationListener,%20javax.management.NotificationFilter,%20java.lang.Object%29"><tt><font size=3>MBeanServerConnection.addNotificationListener(ObjectName,
NotificationListener, NotificationFilter, Object)</font></tt></a><font size=3>,
and likewise for the other methods of </font><a href=http://docs.oracle.com/javase/6/docs/api/javax/management/NotificationBroadcaster.html><tt><font size=3>NotificationBroadcaster</font></tt></a><font size=3>
and </font><a href=http://docs.oracle.com/javase/6/docs/api/javax/management/NotificationEmitter.html><tt><font size=3>NotificationEmitter</font></tt></a><font size=3>.</font>
<br><font size=3>Type Parameters:</font>
<br><tt><font size=3>T</font></tt><font size=3> - allows the compiler to
know that if the </font><tt><font size=3>interfaceClass</font></tt><font size=3>
parameter is </font><tt><font size=3>MyMBean.class</font></tt><font size=3>,
for example, then the return type is </font><tt><font size=3>MyMBean</font></tt><font size=3>.</font>
<br><font size=3>Parameters:</font>
<br><tt><font size=3>connection</font></tt><font size=3> - the MBean server
to forward to.</font>
<br><tt><font size=3>objectName</font></tt><font size=3> - the name of
the MBean within </font><tt><font size=3>connection</font></tt><font size=3>
to forward to.</font>
<br><tt><font size=3>interfaceClass</font></tt><font size=3> - the management
interface that the MBean exports, which will also be implemented by the
returned proxy.</font>
<br><tt><font size=3>notificationBroadcaster</font></tt><font size=3> -
make the returned proxy implement </font><a href=http://docs.oracle.com/javase/6/docs/api/javax/management/NotificationEmitter.html><tt><font size=3>NotificationEmitter</font></tt></a><font size=3>
by forwarding its methods via </font><tt><font size=3>connection</font></tt><font size=3>.
</font>
<br><font size=3>Returns:</font>
<br><font size=3>the new proxy instance.</font>
<br>
<br>
<br><font size=2 face="sans-serif">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?</font>
<br>
<br>
<br><font size=2 face="sans-serif"><br>
Thanks,<br>
-Chris<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">ceki <ceki@qos.ch></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">logback users list
<logback-user@qos.ch></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">05/30/2012 03:39 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [logback-user]
JMX on a WebSphere clustered environment</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">logback-user-bounces@qos.ch</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2><br>
Chris,<br>
<br>
Would sharing the configuration file by all instances be a possibility?
<br>
If yes, you could probably get by with the auto-scan feature.<br>
<br>
-- <br>
Ceki<br>
</font></tt><a href=http://twitter.com/#!/ceki><tt><font size=2>http://twitter.com/#!/ceki</font></tt></a><tt><font size=2><br>
<br>
On 30.05.2012 20:50, Christopher.White@bbh.com wrote:<br>
><br>
><br>
> Hi,<br>
><br>
> I'm trying to use Logback JMX in my application to allow me to change<br>
> the configuration at runtime.<br>
><br>
> I've created client code that can retrieve the JMX bean, and am able
to<br>
> invoke the JMX bean to get/set logging levels.<br>
><br>
> This works just fine on one single server. However, my application
is<br>
> deployed on a cluster of two servers. When invoking the JMXConfigurator,<br>
> it only modifies the logging configuration on the particular server
that<br>
> I happened to connect to for that http request, but does not modify
the<br>
> configuration on the other clustered server.<br>
><br>
> Am I missing something, or is there no way to have one JMX call update<br>
> the logback configuration on all clustered servers? Am I perhaps<br>
> retrieving the JMX bean incorrectly for a clustered environment? Any<br>
> help would be greatly appreciated.<br>
><br>
><br>
><br>
> Here is the client code I am using to access the JMX bean:<br>
><br>
> String contextName = "myContextName";<br>
> String objectNameStr =<br>
> ch.qos.logback.classic.jmx.MBeanUtil.getObjectNameFor(contextName,<br>
> JMXConfigurator.class);<br>
> javax.management.ObjectName objectName = new<br>
> javax.management.ObjectName(objectNameStr);<br>
> javax.management.MBeanServer mbs =<br>
> java.lang.management.ManagementFactory.getPlatformMBeanServer();<br>
> mbean = javax.management.JMX.newMBeanProxy(mbs, objectName,<br>
> JMXConfiguratorMBean.class, true);<br>
> mbean.setLoggerLevel("myLogger", "debug");<br>
><br>
><br>
><br>
><br>
> Thanks,<br>
> -Chris<br>
<br>
_______________________________________________<br>
Logback-user mailing list<br>
Logback-user@qos.ch<br>
</font></tt><a href="http://mailman.qos.ch/mailman/listinfo/logback-user"><tt><font size=2>http://mailman.qos.ch/mailman/listinfo/logback-user</font></tt></a><tt><font size=2><br>
</font></tt>
<br>

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