You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/03/01 01:31:21 UTC

Hierarchy.java

Peter:

There was discussion on the subject of log listener related methods 
prior to the release of logkit during which it was my understanding that 
the add/remove listener was the preferred approach over a set approach.  
Could you please point me to the subsequent discussions that indicate 
the changes in opinion and consensus on this subject which have lead you 
to commit these changes? 

Cheers, Steve.



donaldp@apache.org wrote:

>donaldp     2003/02/28 14:52:53
>
>  Modified:    src/java/org/apache/log Hierarchy.java
>  Log:
>  Deprecate insanity
>  
>  Revision  Changes    Path
>  1.30      +2 -0      avalon-logkit/src/java/org/apache/log/Hierarchy.java
>  
>  Index: Hierarchy.java
>  ===================================================================
>  RCS file: /home/cvs/avalon-logkit/src/java/org/apache/log/Hierarchy.java,v
>  retrieving revision 1.29
>  retrieving revision 1.30
>  diff -u -r1.29 -r1.30
>  --- Hierarchy.java	26 Feb 2003 08:14:39 -0000	1.29
>  +++ Hierarchy.java	28 Feb 2003 22:52:53 -0000	1.30
>  @@ -202,6 +202,7 @@
>        *
>        * @throws UnsupportedOperationException if no more LoggerListeners are
>        *         permitted.
>  +     * @deprecated Deprecated and replaced by setLoggerListener(loggerListener)
>        */
>       public synchronized void addLoggerListener( final LoggerListener loggerListener )
>       {
>  @@ -225,6 +226,7 @@
>        * step before adding a new one if you want to change it.
>        *
>        * @param loggerListener the LoggerListener
>  +     * @deprecated Deprecated and replaced by setLoggerListener(null)
>        */
>       public synchronized void removeLoggerListener( final LoggerListener loggerListener )
>       {
>  
>  
>  
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
>For additional commands, e-mail: cvs-help@avalon.apache.org
>
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




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


Re: Hierarchy.java

Posted by Leo Simons <le...@apache.org>.
Pete, you're not trolling, are you? Just get a grip, move on.

we so not need this.

- LSD

Peter wrote:

>yer - much better to put shit code out and then in a few years start removing 
>it and deprecating it once they have dependencies on it. Thats the way the 
>rest of the code evolved so lets keep helping our users this way.
>


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


Re: Hierarchy.java

Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 3 Mar 2003 23:52, Berin Loritsch wrote:
> Peter, you have been presented many opportunities to present your use
> cases. 

I prefer to only add code that has a use case. If no valid use case can be 
provided don't add it. No valid use case has been provided so why add the 
complexity?

> Also, you need to think of our users.  If a method is introduced in
> one release, and then deprecated in the next--with no clear technical
> advantage--then they will start to get fed up with our stuff.  I
> personally don't want to see that happen.

yer - much better to put shit code out and then in a few years start removing 
it and deprecating it once they have dependencies on it. Thats the way the 
rest of the code evolved so lets keep helping our users this way. 

-- 
Cheers,

Peter Donald
*-------------------------------------------------*
|   An eye for eye only ends up making the whole  | 
|      world blind.  - Gandhi                     |
*-------------------------------------------------*


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


Re: Hierarchy.java

Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote, On 03/03/2003 13.52:
> Peter Donald wrote:
> 
>> On Sat, 1 Mar 2003 15:27, Stephen McConnell wrote:
>>
>>> Stephen McConnell wrote:
>>>
>>>> Peter:
>>>>
>>>> There was discussion on the subject of log listener related methods
>>>> prior to the release of logkit during which it was my understanding
>>>> that the add/remove listener was the preferred approach over a set
>>>> approach. 
>>
>> Not preferred by me. Mind numbingly stupid I thought but that is to be 
>> expected when the people who are "designing" the functionality don't 
>> even know what the use case is.
> 
> Peter, you have been presented many opportunities to present your use
> cases.  You never did.  You also circumvented the way we do things in
> Avalon.  Things like that require consensus, and I do not recall you
> even bringing it up.  I like you on many levels, but what we came up
> with was a compromise.  We need to live with it even if it is
> sub-optimal.
> 
> I highly recommend that you revert your change, because it slaps the
> community in the face.  You could have been part of the discussion
> when it was being added in a more constructive way.  I put it in there
> the way you had it--which sparked community discussion.  The community
> decided that they preferred the method that is currently there.
> 
> Also, you need to think of our users.  If a method is introduced in
> one release, and then deprecated in the next--with no clear technical
> advantage--then they will start to get fed up with our stuff.  I
> personally don't want to see that happen.
> 
> -1 to the change, esp in the manner in which it was done.

Peter, if not already done (AFAIK), please revert the changes immediately.

> Feel free to put your use cases on the table.

Then we can can discuss it and you can lobby the vetoer.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Re: Hierarchy.java

Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Sat, 1 Mar 2003 15:27, Stephen McConnell wrote:
> 
>>Stephen McConnell wrote:
>>
>>>Peter:
>>>
>>>There was discussion on the subject of log listener related methods
>>>prior to the release of logkit during which it was my understanding
>>>that the add/remove listener was the preferred approach over a set
>>>approach. 
> 
> 
> Not preferred by me. Mind numbingly stupid I thought but that is to be 
> expected when the people who are "designing" the functionality don't even 
> know what the use case is.


Peter, you have been presented many opportunities to present your use
cases.  You never did.  You also circumvented the way we do things in
Avalon.  Things like that require consensus, and I do not recall you
even bringing it up.  I like you on many levels, but what we came up
with was a compromise.  We need to live with it even if it is
sub-optimal.

I highly recommend that you revert your change, because it slaps the
community in the face.  You could have been part of the discussion
when it was being added in a more constructive way.  I put it in there
the way you had it--which sparked community discussion.  The community
decided that they preferred the method that is currently there.

Also, you need to think of our users.  If a method is introduced in
one release, and then deprecated in the next--with no clear technical
advantage--then they will start to get fed up with our stuff.  I
personally don't want to see that happen.

-1 to the change, esp in the manner in which it was done.

Feel free to put your use cases on the table.



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


Re: Hierarchy.java

Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 1 Mar 2003 16:50, Noel J. Bergman wrote:
> He is referring to me, which I find more of an amusement than anything
> else.

Actually I am referring to everyone else but you :) (or at least those who 
cast a vote). I generally think it is a good idea to design something with a 
use in mind rather than no idea what it is actually being used for.

> As far as the interface is concerned, I don't believe that he responded
> when asked for his use case from which it was clear that no one would ever
> want to have more than one listener.  I take it from your comments that you
> do have a use case for more than one listener.  Whilest we wait for his,
> would you please share yours?

I would like to hear it aswell.

-- 
Cheers,

Peter Donald
*----------------------------------------------------------*
The phrase "computer literate user" really means the person 
has been hurt so many times that the scar tissue is thick 
enough so he no longer feels the pain. 
   -- Alan Cooper, The Inmates are Running the Asylum 
*----------------------------------------------------------*


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


Re: Socket logging (was RE: Hierarchy.java)

Posted by Peter Donald <pe...@realityforge.org>.
On Sun, 2 Mar 2003 11:22, Noel J. Bergman wrote:
> Alternatively, perhaps Peter would post up his "dodgy syslog-like server."

will try to in next bit.

> OK, I've been looking at the source for SocketOutputTarget.  There appears
> to be an issue.  The constructor attempts to bind the socket.  A socket
> listener may not be available, or always available.  Seems to me that the
> class should be (re-)binding as necessary when logging the data.
>
> Comments?

In hindsigh maybe that would have been a good idea. But for backwards 
compatability reasons I would prefer a new RebindingSocketTarget or similar.

-- 
Cheers,

Peter Donald
*----------------------------------------------------*
| We must become the change we want to see. - Gandhi |
*----------------------------------------------------*


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


Socket logging (was RE: Hierarchy.java)

Posted by "Noel J. Bergman" <no...@devtech.com>.
Steven and Peter,

Thanks for the explanations.

I'll have look at SocketTargetFactory.  I haven't done it, but I assume that
there is no problem muxing logs, so that I can have my separate log files,
and a merged logger that writes to a local socket.  Doing that would allow
me to use a socket reader with tail, such as:

  socketread --port=localhost:xxxx | tail -n 0 -f - <file list>

I might be able to modify dog to be the socket reader, otherwise it isn't
overly challenging to code one.

Alternatively, perhaps Peter would post up his "dodgy syslog-like server."

-----------------------------

OK, I've been looking at the source for SocketOutputTarget.  There appears
to be an issue.  The constructor attempts to bind the socket.  A socket
listener may not be available, or always available.  Seems to me that the
class should be (re-)binding as necessary when logging the data.

Comments?

	--- Noel


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


Re: Hierarchy.java

Posted by Peter Donald <pe...@realityforge.org>.
On Sun, 2 Mar 2003 09:45, Noel J. Bergman wrote:
> Stephen,
>
> > The use case I'm referring to is hypothetical (basically I looking
> > forward and considering how a single block can provide aggregated
> > monitoring on resource usage
>
> Would this address an issue I have, now that I do log rotation?  

no. That is allready addressed you can have as many LogTargets for a logger as 
you want. During development I generally have the output put to the screen, a 
file and a dodgy syslog-like server I wrote.

-- 
Cheers,

Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof."                   *
*              - John Kenneth Galbraith               *
*-----------------------------------------------------*


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


Re: Hierarchy.java

Posted by Stephen McConnell <mc...@apache.org>.

Noel J. Bergman wrote:

>Stephen,
>
>  
>
>>The use case I'm referring to is hypothetical (basically I looking
>>forward and considering how a single block can provide aggregated
>>monitoring on resource usage
>>    
>>
>
>Would this address an issue I have, now that I do log rotation?  I used to
>be able to easily monitor the logs using tail.  Even with log rotation
>turned on for httpd, I am easily able to follow the logs because of
>the --previous and --symlink options to the cronolog tool.  With Avalon
>logs, there is no similar option, but if I had the option of multiple
>outputs from a log target, I could have both the rotating log files, and a
>well-known output I could monitor.
>

Noel:

This is a seperate issue to the question of log listener association.  A 
log listener listens for the establishment of a new logging channel 
(e.g. m_logger.getChildLogger("whatever") triggers a listener event). 
 In the case your describing you simply need to declare multiple logging 
targets for the particular logging channel your concerned about.  LogKit 
supports this and the configuration model from excalibur-logger provides 
support for this as well.

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




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


RE: Hierarchy.java

Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen,

> The use case I'm referring to is hypothetical (basically I looking
> forward and considering how a single block can provide aggregated
> monitoring on resource usage

Would this address an issue I have, now that I do log rotation?  I used to
be able to easily monitor the logs using tail.  Even with log rotation
turned on for httpd, I am easily able to follow the logs because of
the --previous and --symlink options to the cronolog tool.  With Avalon
logs, there is no similar option, but if I had the option of multiple
outputs from a log target, I could have both the rotating log files, and a
well-known output I could monitor.

	--- Noel


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


Re: Hierarchy.java

Posted by Stephen McConnell <mc...@apache.org>.

Noel J. Bergman wrote:

>Stephen,
>
>He is referring to me, which I find more of an amusement than anything else.
>
>As far as the interface is concerned, I don't believe that he responded when
>asked for his use case from which it was clear that no one would ever want
>to have more than one listener.  I take it from your comments that you do
>have a use case for more than one listener.  Whilest we wait for his, would
>you please share yours?
>  
>

Hi Noel:

The use case I'm referring to is hypothetical (basically I looking 
forward and considering how a single block can provide aggregated 
monitoring on resource usage - because of the hierarchical structure of 
blocks and the characteristic of potentially sharing a common logging 
system, there may exist a requirement for multiple listeners).  However 
- I don't particular want to get into a debate about this subject - 
we've done that already - and practical experimentation on this is 
probably several months away.

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




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


RE: Hierarchy.java

Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen,

He is referring to me, which I find more of an amusement than anything else.

As far as the interface is concerned, I don't believe that he responded when
asked for his use case from which it was clear that no one would ever want
to have more than one listener.  I take it from your comments that you do
have a use case for more than one listener.  Whilest we wait for his, would
you please share yours?

	--- Noel


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


Re: Hierarchy.java

Posted by Leo Simons <le...@apache.org>.
guys,

stop it already! This is not very efficient co-operation, is it? Break 
out of the disagreement loop and work on agreement, rather than driving 
things into conflict.

Peter, why don't you revert the change, bring it up for proposal, make 
your case once more, we can re-vote, and then can we /please/ just 
accept the outcome and move on.

Steve, take a break. We're not politicians. The moment we stop working 
together on a first-name basis I'm outta here!

sheesh.

grz,

- Leo

Stephen McConnell wrote:
>>>> Peter:
>>>>
>>>> There was discussion on the subject of log listener related methods
>>>> prior to the release of logkit during which it was my understanding
>>>> that the add/remove listener was the preferred approach over a set
>>>> approach.     
>>
>>
>> Not preferred by me. Mind numbingly stupid I thought but that is to be 
>> expected when the people who are "designing" the functionality don't 
>> even know what the use case is.
>>
> 
> Mr. Donald,
> 
> Given that the consensus established with this forum was to processed 
> with a add/remove even though this was not your preferred scenario 
> (ignoring the implication of the mind numbing stupidity that apparent 
> exists across this community), would you please consider this as my -1 
> on your change.  Should you which to bring this up for discussion I will 
> be more than willing to review this subject further and look forward to 
> your justification for the non-existence of the "add/remove" use case.
> 
> Unfortunately, according to the policies and procedures we have 
> established within Avalon, "mind numbingly stupid" opinions still 
> count.



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


Re: Hierarchy.java

Posted by Stephen McConnell <mc...@apache.org>.

Peter Donald wrote:

>On Sat, 1 Mar 2003 15:27, Stephen McConnell wrote:
>  
>
>>Stephen McConnell wrote:
>>    
>>
>>>Peter:
>>>
>>>There was discussion on the subject of log listener related methods
>>>prior to the release of logkit during which it was my understanding
>>>that the add/remove listener was the preferred approach over a set
>>>approach. 
>>>      
>>>
>
>Not preferred by me. Mind numbingly stupid I thought but that is to be 
>expected when the people who are "designing" the functionality don't even 
>know what the use case is.
>

Mr. Donald,

Given that the consensus established with this forum was to processed 
with a add/remove even though this was not your preferred scenario 
(ignoring the implication of the mind numbing stupidity that apparent 
exists across this community), would you please consider this as my -1 
on your change.  Should you which to bring this up for discussion I will 
be more than willing to review this subject further and look forward to 
your justification for the non-existence of the "add/remove" use case.

Unfortunately, according to the policies and procedures we have 
established within Avalon, "mind numbingly stupid" opinions still 
count.  Should you have any reservations pertaining to this issue, I can 
assure you that an add/remove case exists, and that the deprecation you 
have committed is in conflict with that use case.  If my limited 
education servers me correctly, I am under the impressions that 1 
remains a subset of n. As such, I can only assume that your use case is 
a subset of a larger and broader use case and therefore your 
requirements are not infringed.

Recevez, je vous prie, Monsieur, ma considération distinguée.

McConnell.

>
>
>  
>
>>Pete:
>>
>>Still waiting in anticipation for your reply.
>>
>>Steve.
>>
>>    
>>
>>>>donaldp     2003/02/28 14:52:53
>>>>
>>>> Modified:    src/java/org/apache/log Hierarchy.java
>>>> Log:
>>>> Deprecate insanity
>>>>
>>>> Revision  Changes    Path
>>>> 1.30      +2 -0
>>>>avalon-logkit/src/java/org/apache/log/Hierarchy.java
>>>>
>>>> Index: Hierarchy.java
>>>> ===================================================================
>>>> RCS file:
>>>>/home/cvs/avalon-logkit/src/java/org/apache/log/Hierarchy.java,v
>>>> retrieving revision 1.29
>>>> retrieving revision 1.30
>>>> diff -u -r1.29 -r1.30
>>>> --- Hierarchy.java    26 Feb 2003 08:14:39 -0000    1.29
>>>> +++ Hierarchy.java    28 Feb 2003 22:52:53 -0000    1.30
>>>> @@ -202,6 +202,7 @@
>>>>       *
>>>>       * @throws UnsupportedOperationException if no more
>>>>LoggerListeners are
>>>>       *         permitted.
>>>> +     * @deprecated Deprecated and replaced by
>>>>setLoggerListener(loggerListener)
>>>>       */
>>>>      public synchronized void addLoggerListener( final
>>>>LoggerListener loggerListener )
>>>>      {
>>>> @@ -225,6 +226,7 @@
>>>>       * step before adding a new one if you want to change it.
>>>>       *
>>>>       * @param loggerListener the LoggerListener
>>>> +     * @deprecated Deprecated and replaced by setLoggerListener(null)
>>>>       */
>>>>      public synchronized void removeLoggerListener( final
>>>>LoggerListener loggerListener )
>>>>      {
>>>>
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
>>>>For additional commands, e-mail: cvs-help@avalon.apache.org
>>>>        
>>>>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




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


Re: Hierarchy.java

Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 1 Mar 2003 15:27, Stephen McConnell wrote:
> Stephen McConnell wrote:
> > Peter:
> >
> > There was discussion on the subject of log listener related methods
> > prior to the release of logkit during which it was my understanding
> > that the add/remove listener was the preferred approach over a set
> > approach. 

Not preferred by me. Mind numbingly stupid I thought but that is to be 
expected when the people who are "designing" the functionality don't even 
know what the use case is.

>
> Pete:
>
> Still waiting in anticipation for your reply.
>
> Steve.
>
> >> donaldp     2003/02/28 14:52:53
> >>
> >>  Modified:    src/java/org/apache/log Hierarchy.java
> >>  Log:
> >>  Deprecate insanity
> >>
> >>  Revision  Changes    Path
> >>  1.30      +2 -0
> >> avalon-logkit/src/java/org/apache/log/Hierarchy.java
> >>
> >>  Index: Hierarchy.java
> >>  ===================================================================
> >>  RCS file:
> >> /home/cvs/avalon-logkit/src/java/org/apache/log/Hierarchy.java,v
> >>  retrieving revision 1.29
> >>  retrieving revision 1.30
> >>  diff -u -r1.29 -r1.30
> >>  --- Hierarchy.java    26 Feb 2003 08:14:39 -0000    1.29
> >>  +++ Hierarchy.java    28 Feb 2003 22:52:53 -0000    1.30
> >>  @@ -202,6 +202,7 @@
> >>        *
> >>        * @throws UnsupportedOperationException if no more
> >> LoggerListeners are
> >>        *         permitted.
> >>  +     * @deprecated Deprecated and replaced by
> >> setLoggerListener(loggerListener)
> >>        */
> >>       public synchronized void addLoggerListener( final
> >> LoggerListener loggerListener )
> >>       {
> >>  @@ -225,6 +226,7 @@
> >>        * step before adding a new one if you want to change it.
> >>        *
> >>        * @param loggerListener the LoggerListener
> >>  +     * @deprecated Deprecated and replaced by setLoggerListener(null)
> >>        */
> >>       public synchronized void removeLoggerListener( final
> >> LoggerListener loggerListener )
> >>       {
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
> >> For additional commands, e-mail: cvs-help@avalon.apache.org

-- 
Cheers,

Peter Donald
---------------------------------------------------------
Clarke's Third Law: "Any technology distinguishable from 
magic is insufficiently advanced".
---------------------------------------------------------


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


Re: Hierarchy.java

Posted by Stephen McConnell <mc...@apache.org>.

Stephen McConnell wrote:

>
> Peter:
>
> There was discussion on the subject of log listener related methods 
> prior to the release of logkit during which it was my understanding 
> that the add/remove listener was the preferred approach over a set 
> approach.  Could you please point me to the subsequent discussions 
> that indicate the changes in opinion and consensus on this subject 
> which have lead you to commit these changes? 


Pete:

Still waiting in anticipation for your reply.

Steve.

>> donaldp     2003/02/28 14:52:53
>>
>>  Modified:    src/java/org/apache/log Hierarchy.java
>>  Log:
>>  Deprecate insanity
>>  
>>  Revision  Changes    Path
>>  1.30      +2 -0      
>> avalon-logkit/src/java/org/apache/log/Hierarchy.java
>>  
>>  Index: Hierarchy.java
>>  ===================================================================
>>  RCS file: 
>> /home/cvs/avalon-logkit/src/java/org/apache/log/Hierarchy.java,v
>>  retrieving revision 1.29
>>  retrieving revision 1.30
>>  diff -u -r1.29 -r1.30
>>  --- Hierarchy.java    26 Feb 2003 08:14:39 -0000    1.29
>>  +++ Hierarchy.java    28 Feb 2003 22:52:53 -0000    1.30
>>  @@ -202,6 +202,7 @@
>>        *
>>        * @throws UnsupportedOperationException if no more 
>> LoggerListeners are
>>        *         permitted.
>>  +     * @deprecated Deprecated and replaced by 
>> setLoggerListener(loggerListener)
>>        */
>>       public synchronized void addLoggerListener( final 
>> LoggerListener loggerListener )
>>       {
>>  @@ -225,6 +226,7 @@
>>        * step before adding a new one if you want to change it.
>>        *
>>        * @param loggerListener the LoggerListener
>>  +     * @deprecated Deprecated and replaced by setLoggerListener(null)
>>        */
>>       public synchronized void removeLoggerListener( final 
>> LoggerListener loggerListener )
>>       {
>>  
>>  
>>  
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
>> For additional commands, e-mail: cvs-help@avalon.apache.org
>>
>>
>>
>>  
>>
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




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