Why does using a threshold=off not achieve the same as "pause"? Do we really need to introduce yet another source of state to the various components? I do think that a threshold interface might be in order, and if we can use it to achieve the same as "pause", I would prefer it.
-Mark ----- Original Message ----- From: "Ceki Gülcü" <[EMAIL PROTECTED]> To: "Log4J Developers List" <[EMAIL PROTECTED]> Sent: Sunday, June 22, 2003 1:54 AM Subject: RE: Latest Receiver/Plugin commits to sandbox > Hi Paul, > > Adding Pausable interface and checking whether the Plugin supports it, is > probably simpler. > > At 08:09 AM 6/22/2003 +1000, you wrote: > >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] > > -- > Ceki For log4j documentation consider "The complete log4j manual" > ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp > > > --------------------------------------------------------------------- > 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]
