RE: Receiver Implementation

[mw...@apache.org]

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:nicko@Neoworks.com]
> Sent: Tuesday, August 06, 2002 3:00 AM
> To: 'log4j-dev@jakarta.apache.org'
> 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:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>