logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy McBride" <andy.mcbr...@pcmsgroup.com>
Subject RE: close() an Appender vs shutdown() a Receiver
Date Wed, 10 Nov 2004 16:49:43 GMT
Hi, 

> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch] 
> Sent: 09 November 2004 11:43
> To: Log4J Developers List
> Subject: Re: close() an Appender vs shutdown() a Receiver
> 
> 
> 
> Hello Mark,
> 
> I also prefer close() instead of shutdown().
> 
> Anyway, there were a number of simplifications to the Plugin and 
> PluginRegistry code earlier this year. Otherwise, the code 
> has remained the 
> same since last year.
> 
> At 07:59 AM 11/9/2004, Mark Womack wrote:
> >Andy,
> >
> >The api for the Receiver is still open to changes.  I need to refresh
> >myself, but I believe it inherits the shutdown() method 
> signature from the
> >Plugin interface where "shutdown" makes more contextual 
> sense than "close".
> >At least I thought so at the time of the design.


I personally thought that "shutdown" made more sense in both appender
and receiver as I tend to view an appender more as a log4j 'plugin' than
the traditional 'output destination' view, but I thought it would be a
bit more tricky to change the appender method (at least until log4j 2.0
:-) 


> >While they are mirrors in functionality, I don't know if it 
> is strictly
> >required that they follow the exact same api.  But I can be convinced
> >otherwise.  


I also don't think it should be strictly required for them to have an
identical api or common interface, 
just that similarity where possible between the two may aid existing
log4j developers to adopt the receiver framework.  
It's a trade-off between contextual clarity and commonality and in this
case I thought commonality would be more favourable. 


> >Are there other aspects of the api that you 
> would consider
> >changing?  I am open to review/suggestions.  I plan to do a 
> more thorough
> >pass in the near future.


I've only had chance to have a quick look through the receiver api, not
used it in anger yet.  

One thing I did notice was that the javadoc for PluginSkeleton states
that subclasses are required to implement the isActive() method from the
Plugin interface but PluginSkeleton provides a perfectly good active
property along with an implementation of the isActive() method.  

Some existing receiver classes follow the javadoc and provide redundant
implementations of both property and method whereas others just use the
inherited ones.  

I suggest amendment of the javadoc in PluginSkeleton and removal of the
isActive() method and associated property in the following classes:

JMSReceiver
MulticastReceiver
PluginTestCase.PluginTester
SocketHubReceiver
XMLSocketReceiver


Cheers

Andy


> >
> >thanks,
> >-Mark
> >
> >----- Original Message -----
> >From: "Andy McBride" <andy.mcbride@pcmsgroup.com>
> >To: <log4j-dev@logging.apache.org>
> >Sent: Monday, November 08, 2004 5:20 PM
> >Subject: close() an Appender vs shutdown() a Receiver
> >
> >
> > > Hi,
> > >
> > > As the Receiver performs the mirror function of the
> > > Appender, would there be merit in striving to make the two
> > > API's as similar as possible?
> > >
> > > When writing an appender you have to implement the close()
> > > method, but when writing a Receiver you have to implement
> > > shutdown() but I believe the intended purpose to be the
> > > same.
> > >
> > > It may ease the introduction of Receivers in 1.3 if the
> > > API were familiar to existing appender developers.
> > >
> > > As 1.3 seems to be considered an alpha release, is it too
> > > late to simply rename the shutdown() method in
> > > org.apache.log4j.plugins.Plugin to close()?
> > >
> > > I can supply a patch for the current cvs tip if a
> > > committer would like to pursue this.
> > >
> > > Kind Regards
> > >
> > > Andy
> > > The information contained in this e-mail is intended only 
> for the person
> >or
> > > entity to which it is addressed and may contain 
> confidential and/or
> > > privileged material.  If You are not the intended 
> recipient of this
> >e-mail,
> > > the use of this information or any disclosure, copying or 
> distribution is
> > > Prohibited and may be unlawful.  If you received this in 
> error, please
> > > contact the sender and delete the material from any 
> computer.  The views
> > > expressed in this e-mail may not necessarily be the views 
> of The PCMS
> >Group
> > > plc and should not be taken as authority to carry out any 
> instruction
> > > contained.
> > >
> > >
> > > 
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> > >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 
> -- 
> Ceki Gülcü
> 
>       For log4j documentation consider "The complete log4j manual"
>       http://www.qos.ch/shop/products/eclm/  
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message