I wonder whether we could use some Bean introspection mechanism to detect those Plugin's that support a pause operation (and perhaps other future optional operations).
Paul -----Original Message----- From: Mark Womack To: 'Log4J Developers List' Sent: 6/21/03 9:06 AM Subject: RE: Latest Receiver/Plugin commits to sandbox I can look into adding a "pause" feature for plugins or receivers specifically. Starting and stopping will shutdown all the receiver connections, something I guess you want to avoid if you plan to just "pause" it. -Mark > -----Original Message----- > From: Paul Smith [mailto:[EMAIL PROTECTED] > Sent: Friday, June 20, 2003 3:54 PM > To: 'Log4J Developers List' ' > Subject: RE: Latest Receiver/Plugin commits to sandbox > > > That seems like a reasonable idea, but I'm hoping for some way for an > external client, like Chainsaw to be able to 'pause' a > plugin, rather than > start/stop. (stop disconnects sockets). > > If you can describe a way to do this through PluginRegistry I > can make it > happen. I've just realised the added advantage of going through > PluginRegistry is because of the usage of listeners. > > cheers, > > Paul > > -----Original Message----- > From: Mark Womack > To: 'Log4J Developers List' > Sent: 6/21/03 2:24 AM > Subject: RE: Latest Receiver/Plugin commits to sandbox > > Paul, > > I'll have to review the setActive() change. I don't think I > wanted that > public. I'd rather callers use start/stop. > > I will be spending some time this Saturday looking at this and other > plugin > related stuff (like using the ReadWriterLock class in PluginRegistry). > > -Mark > > > -----Original Message----- > > From: Paul Smith [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 19, 2003 10:01 PM > > To: Log4j-Dev (E-mail) > > Subject: Latest Receiver/Plugin commits to sandbox > > > > > > I'd appreciate it people could take a peek at my latest > > Plugin/Receiver > > commits that I've made to the sandbox. > > > > Since Chainsaw needs to manage the state of the Receiver > > style plugins at > > the moment and not to preclude it's ability to manage any > > Plugin, I have > > exposed the setActive() method at the Plugin interface level, > > and modified > > the PluginSkeleton to provide this facility without > burdening the sub > > classes. This involved a little tidy up here and there. > > > > SocketReceiver has been tweaked a little bit more though, as > > I attempted to > > get the recycling of the receiver to tidy up it's > > connections, and ensure > > that restart wouldn't hang, or think it's paused. Have > > tested it under a > > number of scenerios. > > > > My intent here is that if the Reciever is not active, it acts > > as if the > > Threshold has been set to OFF. If we do add Threshold's to > > receivers, and I > > hope we do, the difference between !isActive() and Threshold > > == OFF will be > > almost indistinguishable. Is this ok? Or cludgy? > > > > It would be good to properly discuss and define the semantics > > of the Active > > property of a Plugin. > > > > cheers, > > _________________________ > > Paul Smith > > Lawlex Compliance Solutions > > phone: +61 3 9278 1511 > > email: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
