You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/02/06 06:37:42 UTC
[VOTE] LogKit LoggerListener API
We got sidetracked on this issue. LogKit 1.2rc5 works with no bugs
reported.
The only outstanding issue before a release is the LoggerListener API.
Do we define the LoggerListener registration as:
//------------------------------------------------------------------
void setLoggerListener( final LoggerListener loggerListener )
{
m_loggerListener = loggerListener;
}
//------------------------------------------------------------------
* Easy, and already done.
* Can be overridden at any time, losing the old listener
* Possible change in API requiring deprecation if we decide to enable
multicasting.
Or do we define it as:
//------------------------------------------------------------------
void addLoggerListener( final LoggerListener listener )
throws java.util.TooManyListenersException()
{
if ( null == m_loggerListener )
{
m_loggerListener = listener;
}
else
{
throw new java.util.TooManyListenersException();
}
}
//------------------------------------------------------------------
* Easy to do, does not change functionality
* Clearer contract, although it forces client code to do exception
handling for the listener.
* No future API changes other than the removal of the declared exception
I don't care which one we decide on as long as we decide soon. I want
to get the release out the door. Now is not the time to discuss the
technical merits of either approach, just put down your preference.
I am +0 on setLoggerListener and -0 on addLoggerListener
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] LogKit LoggerListener API
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>> void setLoggerListener( final LoggerListener loggerListener )
>
> -0
-0
>> Or do we define it as:
>>
>> void addLoggerListener( final LoggerListener listener )
>> throws java.util.TooManyListenersException()
>
> +1
+1
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] LogKit LoggerListener API
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> void setLoggerListener( final LoggerListener loggerListener )
-0
>
> Or do we define it as:
>
> void addLoggerListener( final LoggerListener listener )
> throws java.util.TooManyListenersException()
+1
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
AbstractJdbcConnection.close may lose connections
Posted by Greg Steuck <gr...@nest.cx>.
Hello,
If I am not mistaken, connections may not be returned to pool nor
disposed of if clearWarnings() in close() throws a SQLException. Could
somebody comment on the validity of the following patch or explain why
it is not necessary?
Index: AbstractJdbcConnection.java
===================================================================
RCS file: /home/cvspublic/avalon-excalibur/datasource/src/java/org/apache/avalon/excalibur/datasource/AbstractJdbcConnection.java,v
retrieving revision 1.21
diff -u -c -r1.21 AbstractJdbcConnection.java
*** AbstractJdbcConnection.java 8 Nov 2002 03:24:27 -0000 1.21
--- AbstractJdbcConnection.java 6 Feb 2003 22:19:10 -0000
***************
*** 157,164 ****
public void close()
throws SQLException
{
! clearWarnings();
! m_pool.put( this );
}
public void dispose()
--- 157,174 ----
public void close()
throws SQLException
{
! try
! {
! clearWarnings();
! m_pool.put( this );
! }
! catch ( SQLException se )
! {
! // gets rid of connections that throw SQLException during
! // clean up
! getLogger.error( "Connection could not be recycled", se );
! this.dispose();
! }
}
public void dispose()
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] LogKit LoggerListener API
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> We got sidetracked on this issue.
can we just get back on track? We're not really getting anywhere I guess...
Peter Donald wrote:
> Fairly silly if you ask me but I got not choice in the manner.
sure you do. State your opinion and preferences, explain how you formed
those, and they'll be respected and taken into account.
Leo Sutic wrote:
> I think we have entered the "well it depends on your personal
> preferences" zone here.
agreed.
Yoda said:
> "No. Try not. Do. Or do not. There is no try."
he makes a good point, too. :D
g'night,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [VOTE] LogKit LoggerListener API
Posted by "Noel J. Bergman" <no...@devtech.com>.
> that would imply that there is a remove method...
Yup. :-) Should be one.
> > > does anyone actually know what use case would use multicast?
> > Why have a listener at all?
> Good question - anyone care to answer?
If we can get an answer to mine, we can probably answer yours.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] LogKit LoggerListener API
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 7 Feb 2003 08:00, Noel J. Bergman wrote:
> The unicast convention is that you remove the current one, then you can add
> a replacement. At least you know that you've done something "bad."
that would imply that there is a remove method...
>
> > does anyone actually know what use case would use multicast?
>
> Why have a listener at all?
Good question - anyone care to answer?
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Religion is what the common people see as true, the |
| wise people see as false, and the rulers see as |
| useful" --Seneca |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [VOTE] LogKit LoggerListener API
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Seems like this is already decided. However you have removed the ability
to
> change the listener. At least add that back.
The unicast convention is that you remove the current one, then you can add
a replacement. At least you know that you've done something "bad."
> does anyone actually know what use case would use multicast?
Why have a listener at all?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] LogKit LoggerListener API
Posted by Peter Donald <pe...@realityforge.org>.
Seems like this is already decided. However you have removed the ability to
change the listener. At least add that back.
Fairly silly if you ask me but I got not choice in the manner. The listener is
an abstract class not an interface and is not likely to be ever multicast.
Just as a curious question - does anyone actually know what use case would use
multicast? Or is this just flexability syndrome?
On Thu, 6 Feb 2003 16:37, Berin Loritsch wrote:
> We got sidetracked on this issue. LogKit 1.2rc5 works with no bugs
> reported.
>
> The only outstanding issue before a release is the LoggerListener API.
>
>
> Do we define the LoggerListener registration as:
>
> //------------------------------------------------------------------
> void setLoggerListener( final LoggerListener loggerListener )
> {
> m_loggerListener = loggerListener;
> }
> //------------------------------------------------------------------
> * Easy, and already done.
> * Can be overridden at any time, losing the old listener
> * Possible change in API requiring deprecation if we decide to enable
> multicasting.
>
>
> Or do we define it as:
>
> //------------------------------------------------------------------
> void addLoggerListener( final LoggerListener listener )
> throws java.util.TooManyListenersException()
> {
> if ( null == m_loggerListener )
> {
> m_loggerListener = listener;
> }
> else
> {
> throw new java.util.TooManyListenersException();
> }
> }
> //------------------------------------------------------------------
> * Easy to do, does not change functionality
> * Clearer contract, although it forces client code to do exception
> handling for the listener.
> * No future API changes other than the removal of the declared exception
>
>
> I don't care which one we decide on as long as we decide soon. I want
> to get the release out the door. Now is not the time to discuss the
> technical merits of either approach, just put down your preference.
>
> I am +0 on setLoggerListener and -0 on addLoggerListener
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
--
Cheers,
Peter Donald
------------------------------------------------------
Mark Twain: "In the real world, the right thing never
happens in the right place at the right time. It is
the task of journalists and historians to rectify
this error."
------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] LogKit LoggerListener API
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 7 Feb 2003 08:21, Noel J. Bergman wrote:
> If this is something that isn't needed,
It is needed or else I would not have implemented it.
--
Cheers,
Peter Donald
------------------------------------------------
"No. Try not. Do. Or do not. There is no try."
-- Yoda
------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [VOTE] LogKit LoggerListener API
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I think we have entered the "well it depends on your personal
> preferences" zone here. I see your point, and still I think my
> way is better - simply because I give more weight to my own
> arguments for no particular reason other than my own
> sense of aestethics.
LOL
Personally, I was permanently corrupted by the experience of writing
real-time operating systems for ROMable systems that were expected to run
for, oh, ever between reboots. In component oriented packaging, you need
enforcable contracts.
> > Why have a listener at all?
> To hold up the release for as long as possible while we debate
> things that are really unimportant compared to getting a release
> out the door.
If this is something that isn't needed, then rather than resolve issues
related to a new public interface, if there is still debate over what it
should be, deal with it later.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [VOTE] LogKit LoggerListener API
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> > Since we should keep the necessity of try/catch to a
> minimum, I figure
> > people can live with a RuntimeException potentially being
> thrown until
> > we can get true multicast functionality in.
>
> So the person calls the method, and because they are saving
> themselves from the perils of exception handling, their
> method fails. Not only that, but it silently fails all the
> way up the stack until someone catches Throwable, or they
> blow out the thread.
I think we have entered the "well it depends on your personal
preferences" zone here. I see your point, and still I think my
way is better - simply because I give more weight to my own
arguments for no particular reason other than my own
sense of aestethics.
I have no problem debating the merits of our different approaches,
BUT:
> Why have a listener at all?
To hold up the release for as long as possible while we debate
things that are really unimportant compared to getting a release
out the door. I don't think you're the only one who has had a lot
of one-minute logfiles.
So, how about we re-visit this later, if needed?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [VOTE] LogKit LoggerListener API
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Since we should keep the necessity of try/catch to a minimum, I
> figure people can live with a RuntimeException potentially being
> thrown until we can get true multicast functionality in.
So the person calls the method, and because they are saving themselves from
the perils of exception handling, their method fails. Not only that, but it
silently fails all the way up the stack until someone catches Throwable, or
they blow out the thread.
Which reminds me ... Avalon's thread runners catches Throwable and silently
discards errors. Seems to me that it would be better if Avalon had a log
for things not caught by application components, and used it.
See:
http://cvs.apache.org/viewcvs/avalon-excalibur/thread/src/java/org/apache/ex
calibur/thread/impl/WorkerThread.java?rev=1.3&content-type=text/vnd.viewcvs-
markup
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [VOTE] LogKit LoggerListener API
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Leo Sutic wrote:
>
> >
> >
> >>From: Berin Loritsch [mailto:bloritsch@apache.org]
> >>
> >>void addLoggerListener( final LoggerListener listener )
> >> throws java.util.TooManyListenersException()
> >>{
> >> if ( null == m_loggerListener )
> >> {
> >> m_loggerListener = listener;
> >> }
> >> else
> >> {
> >> throw new java.util.TooManyListenersException();
> >> }
> >>}
> >>
> >>
> >
> > +1
> >
> >
> >
> >>* Easy to do, does not change functionality
> >>* Clearer contract, although it forces client code to do exception
> >> handling for the listener.
> >>* No future API changes other than the removal of the declared
> >>
> >>
> >exception
> >
> >Will result in compilation errors. Given a:
> >
> >try {
> > x.addLoggerListener (this);
> >} catch (TooManyListenersException tmle) {
> > // Do nothing
> >}
> >
> >if addLoggerListener (this) doesn't throw a
> TooManyListenersException,
> >javac will complain that "TooManyListenersException not thrown in
> >corresponding try clause".
> >
>
> But the proposed implementation DOES declare and can
> potentially throw a
> TooManyListenersException. I don't get the issue here. I must be
> missing something (seems to be a habbit lately) - please explain.
I think you missed this part of the alternative I voted +1 for:
* No future API changes other than the removal of the declared
exception
So while it *does* declare and can potentially throw an exception,
future versions *won't*. And the removal of the declaration will
result in compilation errors.
So the options are these:
1. Keep the exception declared, even though it is never thrown.
2. Remove the exception.
Since we should keep the necessity of try/catch to a minimum, I
figure people can live with a RuntimeException potentially being
thrown until we can get true multicast functionality in.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] LogKit LoggerListener API
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>void addLoggerListener( final LoggerListener listener )
>> throws java.util.TooManyListenersException()
>>{
>> if ( null == m_loggerListener )
>> {
>> m_loggerListener = listener;
>> }
>> else
>> {
>> throw new java.util.TooManyListenersException();
>> }
>>}
>>
>>
>
> +1
>
>
>
>>* Easy to do, does not change functionality
>>* Clearer contract, although it forces client code to do exception
>> handling for the listener.
>>* No future API changes other than the removal of the declared
>>
>>
>exception
>
>Will result in compilation errors. Given a:
>
>try {
> x.addLoggerListener (this);
>} catch (TooManyListenersException tmle) {
> // Do nothing
>}
>
>if addLoggerListener (this) doesn't throw a TooManyListenersException,
>javac will complain that "TooManyListenersException not thrown in
>corresponding try clause".
>
But the proposed implementation DOES declare and can potentially throw a
TooManyListenersException. I don't get the issue here. I must be
missing something (seems to be a habbit lately) - please explain.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [VOTE] LogKit LoggerListener API
Posted by "Noel J. Bergman" <no...@devtech.com>.
>
synchronized void addLoggerListener( final LoggerListener listener )
throws java.lang.UnsupportedOperationException
> UnsupportedOperationException is a RuntimeException and requires no
try/catch
Oh great ... so you want to throw an exception without the compiler telling
me about it. :-)
-- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [VOTE] LogKit LoggerListener API
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> void addLoggerListener( final LoggerListener listener )
> throws java.util.TooManyListenersException()
> {
> if ( null == m_loggerListener )
> {
> m_loggerListener = listener;
> }
> else
> {
> throw new java.util.TooManyListenersException();
> }
> }
+1
> * Easy to do, does not change functionality
> * Clearer contract, although it forces client code to do exception
> handling for the listener.
> * No future API changes other than the removal of the declared
exception
Will result in compilation errors. Given a:
try {
x.addLoggerListener (this);
} catch (TooManyListenersException tmle) {
// Do nothing
}
if addLoggerListener (this) doesn't throw a TooManyListenersException,
javac will complain that "TooManyListenersException not thrown in
corresponding try clause".
I suggest a:
synchronized void addLoggerListener( final LoggerListener listener )
throws java.lang.UnsupportedOperationException
{
if ( null == m_loggerListener )
{
m_loggerListener = listener;
}
else
{
throw new java.lang.UnsupportedOperationException("This version
of LogKit (1.2) doesn't support multicast listeners.");
}
}
as UnsupportedOperationException is a RuntimeException and requires no
try/catch,
plus we get the protection of an exception when some code is fighting
over who
gets to be the listener for an attractive logger.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] LogKit LoggerListener API
Posted by Peter Royal <pr...@apache.org>.
On Thursday, February 6, 2003, at 12:37 AM, Berin Loritsch wrote:
> void setLoggerListener( final LoggerListener loggerListener )
-0
> void addLoggerListener( final LoggerListener listener )
> throws java.util.TooManyListenersException()
+1
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org