RE: Receiver Implementation

[Nicko Cadell <ni...@Neoworks.com>]

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>

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>