Community
Participate
Working Groups
Build Identifier: According to the logback documentation at [1] and [2] it is possible to change the configuration at runtime. Maybe it would be nice to have a feature to be able to change the logging configuration at runtime w/o the need to restart Virgo. However I did some tests with Equinox and [1] in the past and found it quite unreliable. Most of the time it either didn't recognize any changes within the defined interval or it didn't recognize changes at all. Even worse once there was an error in the configuration it completely stopped logging without throwing an exception. Therefore I switched to [2] which worked perfectly fine for me. Another thought that came to my mind is the following: If I'm not mistaken there will be multiple atomic (user) regions available in the next Virgo release (please correct me if I'm wrong). I wonder if it would be possible to have different (dynamic) logging configurations for each of these regions. [1] http://logback.qos.ch/manual/configuration.html#autoScan [2] http://logback.qos.ch/manual/configuration.html#joranDirectly Reproducible: Always
Thanks for raising this enhancement. Multiple user regions are *not* planned for the 3.0 release. Although the underlying machinery is likely to be present, we won't have time to introduce the necessary externals as these are likely to be tricky to make usable.
I propose that the Virgo Medic project is the place to start: we should add Mxbeans to manipulate the logback configuration at runtime. This can then become the basis of Equinox console and web admin console UIs for changing the logback configuration at runtime. Of course, one major consideration is whether to persist any changes so they survive a warm restart. Initially, I would avoid that complication as it can be added later if necessary.
The medic code is available in its own git repository and it should be possible to clone one of the existing integration tests there to provide a suitable test setup for changing logback configuration at runtime. This is an extremely small and well-focussed project and so can be worked on without much understanding of the rest of Virgo. If someone wants to take a crack at this, please see [1] for the medic git repository. Clone it onto git hub and then hack away, consulting virgo-dev for advice and help as necessary. [1] http://wiki.eclipse.org/Virgo/Source
Ric Klaren observed the following in the foru thread: >Adding a <jmxConfigurator /> tag to the serviceability.xml does work (partially). > >You'll find the configuration in the bean: > >ch.qos.logback.class/default/ch.logback.classic.jmx.JMXConfi gurator. > >setLoggerLevel/getLoggerLevel work, reloadDefaultConfiguration and reloadByFileName do not work. > >So for small tweaks you can use JMX.
Thank you for the link. I did some testing on my own (see http://www.eclipse.org/forums/index.php?t=msg&th=204177) and with the reloadByFileName method I was able to change the logging config on the fly w/o restarting Virgo. You wrote that such a method could be the basis for some enhancements of the different management agents (Equinox and web UI console). Should I focus on that now or what do you have in mind on how to proceed from here?
I think the next step is to create one or more MXBeans in the medic component which use the technique you have discovered to tweak logback configuration on the fly. The steps to surface the MXBeans to the Equinox console and web admin UI will then be relatively straightforward. I think the most difficult part will be deciding on the scope/capability of the MXBeans, so I would recommended keeping it simple to start with and model the simplest configuration changes. That way we are pretty sure to be able to integrate any patch you send in. If you go off the deep end and define a very complex set of MXBeans, then there's less chance of integrating the change. If you want to proposed MXBean interfaces, you can do that here or, for greater visibility, on virgo-dev. (I ventured into JMX for the first time the other day and added some MXBeans to the Virgo kernel. See kernel commit fef119308fa171b51f38b1b4f188c50074437dc4 if you are interested. There are also JMX tutorials available from Oracle if you are new to JMX.)
*** Bug 342717 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > *** Bug 342717 has been marked as a duplicate of this bug. *** Just wanted to tell you that I still want to help you out with this bug. Unfortunately we had a change in priorities lately which took most of my time but I am positive that by the end of next week this is done and I will be able to start working on this bug.
(In reply to comment #8) > (In reply to comment #7) > > *** Bug 342717 has been marked as a duplicate of this bug. *** > > Just wanted to tell you that I still want to help you out with this bug. > Unfortunately we had a change in priorities lately which took most of my time > but I am positive that by the end of next week this is done and I will be able > to start working on this bug. Thanks Frieder - any help gratefully received. This would be a good feature and would plug a hole relative to Karaf's feature set.
(In reply to comments #2 and #6) I would be very interested by this feature, I think it could help to use more efficiently all Logback capabilities. But for me the simplest way would be to make the "scan" and "scanPeriod" attributes work (that is using Logback as it is designed for). Did I miss something which made you take the MXBean approach?
(In reply to comment #10) > (In reply to comments #2 and #6) > > I would be very interested by this feature, I think it could help to use more > efficiently all Logback capabilities. > > But for me the simplest way would be to make the "scan" and "scanPeriod" > attributes work (that is using Logback as it is designed for). > > Did I miss something which made you take the MXBean approach? Supporting scanning for configuration changes may be reasonable in a development environment, but some shops may object to it in production. When diagnosing production problems, it could be more natural to tweak the logback configuration using JMX without editing the configuration to be used on startup. Then if Virgo is restarted, the logback configuration will be back in a "good" state. Perhaps we should consider both options when we explore how to implement this enhancement: scan to pick up "persistent" loback configuration changes and allow JMX to tweak the logback configuration in a non-persistent way.
(In reply to comment #11) > allow JMX to tweak the logback configuration in a non-persistent way. If there are no objections I'm going to enable the logback JMXConfigurator [1] by default then we can expose it with the web console so it can be used also from there not only with jconsole. What do you think? Violeta [1] http://logback.qos.ch/manual/jmxConfig.html
Sounds good to me Violeta and I agree with the proposal in comment #11 I don't if it will be possible to get this functionality ready in the admin console in time for 3.6.0 though.
(In reply to comment #12) +1
Fixed with commits packaging - 0de0e00b9243c884195224ddde4511edbe2d8690 apps - 17cfb82a985eac883c9e9022196c36f33549788e web - 31c516dfe914727027dd258b11be89d559f648a9 snaps - dc08fafab55a596cb9c6336b74af798b6a0a5b56 kernel - 3fb2b503983ddb2c5ae89c844f77b49c1a70a9a2 documentation is pending
documentation commit id 0c64347a038bf434f99b5a0fd3846d4f4859783a
