Ceki, Nicko, et al, I have checked in an initial pass at the Plugin design as propsoed/discussed. I have also checked in a PluginRegistry to keep track of all the plugins (by LoggerRepository).
As a test of the Plugin design, I implemented a Receiver base class, and a specific SocketReceiver class. I need to do more testing, but I wanted to get the code into cvs so everyone could review. I am especially interested in reviews of PluginRegistry and SocketReceiver, as that is where the meat is. Next steps: - modify DOMConfigurator to support Plugin configuration per repository. - modify LoggerRepository.shutdown() to call PluginRepository.stopAllPlugins()? - create Receiver subclasses for SocketHubReceiver and JMSReceiver. -Mark > -----Original Message----- > From: Nicko Cadell [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 06, 2002 3:00 AM > To: '[EMAIL PROTECTED]' > Subject: RE: Receiver Implementation > > > I like your idea for a Receiver. I have some comments to make about the > suggested implementation. > > First of all the Receiver uses the framework, the framework does > not need to > know about the Receiver. This is unlike the Appenders etc. etc. which are > used directly by the framework. > > The aim of the receiver is to load some arbitrary code specified in the > config file, and bind it to the LoggerRepository. The LoggerRepository and > the rest of log4j does not need to know that it is a receiver. > > I have removed the doPost() method form the interface as this > should just be > a helper method on the ReceiverSkeleton and should not be exposed through > the interface. > > This is the base interface that this all boils down to: > > public interface Plugin implements OptionHandler { > public String getName(); > public void setName(String _name); > > public LoggerRepository getLoggerRepository(); > public void setLoggerRepository(LoggerRepository _repository); > > public void shutdown(); > } > > Note that this is now the Plugin interface as it has no receiver specific > functionality. Obviously trivial implementations of PluginSkeleton and > ReceiverSkeleton would be needed (ReceiverSkeleton adds back the doPost() > method. > > A Plugin is a class that uses the LoggerRepository to do something. The > class is initialised by calling the OptionHandler method and is shutdown() > when the LoggerRepository is shutdown. The advantage of a plugin > aproach is > that it is not limited to receivers, I'm sure that we will think of some > other plugins that can be written. > > Any thoughts? > Nicko > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
