Bugzilla – Full Text Bug Listing
| Summary: | Make the logging configuration dynamic so it's possible to change the config at runtime w/o restarting Virgo | ||
|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Frieder Heugel <frieder.heugel> |
| Component: | runtime | Assignee: | Violeta Georgieva <milesg78> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | eclipse, glyn.normington, milesg78, roland.hauser, thomas.gillet.2 |
| Version: | unspecified | ||
| Target Milestone: | 3.6.0.M05 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 391637 | ||
|
Description
Frieder Heugel
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 |