Chris, Since you are using websphere you could use the Dynamic cache
to push the logging levels around to all the servers in the cluster.
You would need to implement a LoggerContextListener to update the
Dynamic cache when a log level changes. Something like this:
public class LogbackContextListener implements LoggerContextListener {
private static final String LOG_ID = "LBLOG:";
public void onLevelChange(Logger logger, Level level) {
if (DynamicCacheAccessor.isCachingEnabled()) {
DistributedMap map = DynamicCacheAccessor.getDistributedMap();
map.put(LOG_ID + logger.getName(),
level,1,60,60,EntryInfo.SHARED_PUSH, null); //Update dynamic cache
and push to other servers
}
}
and a Dynamic Cache ChangeListener, something like this:
public class LogbackCacheChangeListener implements ChangeListener {
public void cacheEntryChanged(ChangeEvent changeEvent) {
if (ChangeEvent.LOCAL != changeEvent.getSourceOfChance()) {
//Level not changed on this server then nothing to do
if
(changeEvent.getId().toString().startswith(LogbackContextListener.LOG_ID))
{ //Log level changed in cache?
LoggerContext lc = (LoggerContext)
LoggerFactory.getILoggerFactory();
String loggerName =
changeEvent.getId().toString().substring(LogbackContextListener.LOG_ID.length());
Logger logger = lc.getLogger(loggerName);
logger.setLevel((Level)changeEvent.getValue());
//set logger level on server to what was pushed in cache.
}
}
}
Sorry for any typos...
Roy
On Wed, May 30, 2012 at 5:00 PM, <[email protected]> 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.
>
> 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 <[email protected]>
>
> To: logback users list <[email protected]>
> Date: 05/30/2012 03:39 PM
> Subject: Re: [logback-user] JMX on a WebSphere clustered environment
> Sent by: [email protected]
> ________________________________
>
>
>
>
> 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, [email protected] 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
> [email protected]
> 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.
> ********************************************************************************
>
>
> _______________________________________________
> Logback-user mailing list
> [email protected]
> http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-user
