<font size=2 face="sans-serif">Thank you for these great ideas! I will
take a look at both of these options in more detail.</font>
<br>
<br><font size=2 face="sans-serif">I'm not a fan of tying myself to WebSphere,
but I do like the idea of using a common cache mechanism over making manual
modifications to an xml file (and having to make sure that the single xml
file is available to both servers...which would require a significant change
to how our applications are packaged and deployed).</font>
<br>
<br><font size=2 face="sans-serif">I think I am also going to investigate
the possibility of creating an external application that will allow me
to connect to any remote JMX MBeanServer and change the logging as needed.
The user will have to provide the connection information, but will be ok
as long as they can access any server they want from this single application
(providing our company's infrastructure will allow and support this).</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif"><br>
Thanks,<br>
<br>
Christopher White<br>
Sr. Programmer<br>
1-617-772-2403<br>
Christopher.White@bbh.com<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/31/2012 07:16 AM</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>On 31.05.2012 13:07, ceki wrote:<br>
><br>
> You could separate appender configuration and logger level configuration<br>
> into separate files [1]. The main file would define appenders and
would<br>
> include the logger level file which you could maintain programmatically<br>
> (just dump the logger level settings to the logger level config file<br>
> upon change).<br>
<br>
When the user makes a level change using the UI you provide, make the <br>
level change programmatically and then dump the current logger state <br>
into the config file reserved for setting logger levels. The other <br>
instances will pickup the change in the included config file (reserved
<br>
for setting logger levels).<br>
<br>
Dumping the current state should be as easy as iterating over all the <br>
loggers and then writing XML elements such as<br>
<br>
<logger name="a" level="INFO"/><br>
<br>
I'd be happy to help if you wish to go along this route.<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>
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.
********************************************************************************