In Chainsaw's Receivers Panel, the receiver configurations can't be changed at runtime. It only shows the configurations of the currently selected Receiver. Modifications to the table cells don't update the relevant properties of the receivers. This is something which is not still implemented. But it is really useful to change configurations at runtime when it comes to properties like 'filterExpression' and 'tailing'. And also there are some more areas in Receivers Panel, which should be improved.
Created attachment 20675 [details] Implementing ability to change receiver configurations at run time In this patch I have implemented the ability to change properties which are relevant to 'LogFilePatternReceiver' type receivers, at runtime. Those properties include 'filterExpression', 'tailing', 'name', 'logFormat', 'timestampFormat' and some others. There are some other properties which are relevant to other types of receivers. Those can be implemented in the same way later. Here I have a problem of accessing the correct log panel name which is relevant to the currently selected receiver. In the method I used here, a propertyChanged event is fired when the table is updated and it is handled at the LogUI class to update the filter. But I'm not quite sure how to get the correct log panel name which is relevant to the receiver which fired propertyChanged event, to set the new filter expression. So for the time being, I have set the new filter to the currently selected log panel and this should be fixed. According to this, the proper log panel should be selected before changing the 'filterExpression' property. Any comments on how to fix this???....
I think there's one point of confusion: in LogFilePattenrReceiver, filterExpression doesn't relate to the 'refine focus' field in logpanel - it filters events that should be processed by Chainsaw. I don't think you need to do anything to a specific logpanel. Receivers aren't tied to log panels - for example, you can define a 'custom expression logpanel' which will result in events going to 2 log panels at the same time. By the way, you could use reflection instead of instanceof and casting, since the receivers have BeanInfo classes.
(In reply to comment #2) > I think there's one point of confusion: in LogFilePattenrReceiver, > filterExpression doesn't relate to the 'refine focus' field in logpanel - it > filters events that should be processed by Chainsaw. Ok. then we don't have to make the log panels aware of the changes for the receivers panel. Thanks for correcting me.. > > I don't think you need to do anything to a specific logpanel. > > Receivers aren't tied to log panels - for example, you can define a 'custom > expression logpanel' which will result in events going to 2 log panels at the > same time. I didn't realize this fact before as I haven't work with this custom expression log panels. So we can handle all the property changes at ReceiverPanel level without coming to LogUI.. > > By the way, you could use reflection instead of instanceof and casting, since > the receivers have BeanInfo classes. Ok. I'll change it and submit a new patch.. > In addition to this, can you add some comments about saving the receiver configurations and loading them back? can we handle this within the PluginPropertyEditorPanel??..
Loading a receiver configuration file from inside Chainsaw will be very useful. On the receiver configuration creation side, we need to generate a log4j xml config file with each receiver serialized as a 'plugin' node with 'param' children elements representing the receiver's properties. Chainsaw does have a dependency on XStream, so you could use its APIs if you'd like to build the xml configuration file, or you could do it by hand.
Ooops...... I think what I was trying to do is already done through PropertyDescryptors. It updates the configurations of the receivers. I didn't concentrate on those PropertyDescryptors and thought that this functionality is not working. So please omit the previous patch (which I have made obsolete) and it's not going to add any new functionality.
What isn't there currently is the ability to save the changes back to the xml config file and load a new one.
Created attachment 20677 [details] Adding ability to save receiver configs within Chainsaw In this patch I have implemented the ability to save receiver configurations to a log4j XML file from within Chainsaw. At the shutdown time, all the current receivers are written into a configuration file. I have added a new option to the NoReceiversWarningPanel such that the saved configuration file can be loaded and all the saved receivers are restarted. I have used the org.w3c.dom API (because otherwise there is no way to write the configuration file in the required format) to build the log4j XML configuration file and this functionality is added as a method in ReceiversPanel. The file is saved in .chainsaw directory and it is loaded when the user selects the option to load it at next Chainsaw startup. Still there may be some improvements to be done. Check this and add your comments..
Some comments: 1) If there has been no previously saved XML file with the plugins defined, the radio button in the No Receiver panel should be greyed out. It's of no use until you have saved at least once. 2) Rather than LogUI call the receiverPanels save config method, shouldn't the ReceiverPanel implement the SettingsListener interface and have LogUI register it as a listener? That would appear cleaner IMHO. 3) In the try block when saving, the error log does not include the exception. Unfortunately since this method is also called during exit of the process, you never see the problem. I wonder if the (*gasp*) Exception.printStackTrace() should be used instead? I'm actually having trouble getting it to save anything, I don't see any receiver-configs.xml file in the .chainsaw directory? I added a local e.printStackTrace() and see this: java.lang.ClassCastException: org.apache.log4j.chainsaw.zeroconf.ZeroConfPlugin at org.apache.log4j.chainsaw.receivers.ReceiversPanel.saveReceiverConfigurations(ReceiversPanel.java:596) at org.apache.log4j.chainsaw.LogUI.exit(LogUI.java:1418) at org.apache.log4j.chainsaw.osx.OSXIntegration$1.invoke(OSXIntegration.java:57) at $Proxy0.handleQuit(Unknown Source) at com.apple.eawt.Application$6.run(Application.java:396) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:461) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) You're casting all Plugins to the Receivers class type, but that's a big assumption. Not every Plugin registered is a Receiver.
Created attachment 20687 [details] Saving receiver configs - modified patch This patch contains all the modifications proposed by paul....
(In reply to comment #8) > Some comments: > > 1) If there has been no previously saved XML file with the plugins defined, the > radio button in the No Receiver panel should be greyed out. It's of no use > until you have saved at least once. yes. it's nice to have that. this is implemented in the new patch > > 2) Rather than LogUI call the receiverPanels save config method, shouldn't the > ReceiverPanel implement the SettingsListener interface and have LogUI register > it as a listener? That would appear cleaner IMHO. Initially i didn't use it as there's nothing to load in ReceiversPanel. But yes it is nice to do it in the standard way. Fixed in the new patch. > > 3) In the try block when saving, the error log does not include the exception. > Unfortunately since this method is also called during exit of the process, you > never see the problem. I wonder if the (*gasp*) Exception.printStackTrace() > should be used instead? I'm actually having trouble getting it to save Added a e.printStackTrace() > anything, I don't see any receiver-configs.xml file in the .chainsaw directory? > I added a local e.printStackTrace() and see this: > > java.lang.ClassCastException: org.apache.log4j.chainsaw.zeroconf.ZeroConfPlugin > at > org.apache.log4j.chainsaw.receivers.ReceiversPanel.saveReceiverConfigurations(ReceiversPanel.java:596) > at org.apache.log4j.chainsaw.LogUI.exit(LogUI.java:1418) > at > org.apache.log4j.chainsaw.osx.OSXIntegration$1.invoke(OSXIntegration.java:57) > at $Proxy0.handleQuit(Unknown Source) > at com.apple.eawt.Application$6.run(Application.java:396) > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:461) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > You're casting all Plugins to the Receivers class type, but that's a big > assumption. Not every Plugin registered is a Receiver. Sorry about this, I just forgot the ZeroConf. Anyway I think we have to save only the receivers. Used an instanceof and fixed it in the new patch..
Fixed in 568852 THX.