You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2002/01/30 17:40:27 UTC
[Logging] [VOTE-REDUX] Commons Logging 1.0 Release
Out of the "discussions" yesterday, the proposal to release
commons-logging 1.0 received a sufficient number of +1 votes to pass.
Howeer, three issues were raised that should be settled beforehand, in
order to provide future users of this package with a stable API. I'd like
to review them individually so we can move forwards.
(1) Attribution
As was pointed out, the developers of the Avalon framework, and the
logging abstractions and implementations they have developed, had an
influence on the development of the Commons Logging API. In particular,
my implementation of the JDK 1.4 wrapper was based primarily on Avalon
code. Because of time pressures at the time, and the fact that it was
packaged with a different package name, I spaced on the fact that this was
actually Avalon code, and compounded the problem by omitting the author
names of the original authors (Berin and Peter). I apologize to both of
them for that error, and have corrected it in the commons-logging source
code. Please let me know if there are any remaining issues in this area.
(2) Add a trace() level
There was a suggestion to add trace(message) and trace(message,exception)
methods to the commons-logging API, with the idea that trace is a level
"below" debug. I'm personally OK with doing that *before* a 1.0 release,
but will likely oppose it afterwards (adding new public methods to Java
interfaces is hard on backwards compatibility). Therefore, I think this
is a "now or never" decision. What do you guys think?
(3) Change the "message" argument type from Object to String
In all of the current commons-logging API, the "message" argument to all
of the logging calls is an Object. This allows passing an Object on to
the underlying logging implementation (currently Log4J supports this, but
it's also possible to write your own application-specific wrappers using
things like the Chain of Responsibility pattern, but there is a potential
security concern that the logging system might call methods on your object
and modify its state.
I believe that the security concern can be dealt with -- the calling
program can do its own conversion to string beforehand if it is concerned
-- so would prefer to maintain the flexibility. Geir has proposed an
alternative of supporting both method signatures. Comments?
Let's try to move towards resolution on these issues in the next day or
so.
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <co...@jakarta.apache.org>
Sent: Wednesday, January 30, 2002 10:40 AM
Subject: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
> Out of the "discussions" yesterday, the proposal to release
> commons-logging 1.0 received a sufficient number of +1 votes to pass.
> Howeer, three issues were raised that should be settled beforehand, in
> order to provide future users of this package with a stable API. I'd like
> to review them individually so we can move forwards.
>
>
> (1) Attribution
>
> As was pointed out, the developers of the Avalon framework, and the
> logging abstractions and implementations they have developed, had an
> influence on the development of the Commons Logging API. In particular,
> my implementation of the JDK 1.4 wrapper was based primarily on Avalon
> code. Because of time pressures at the time, and the fact that it was
> packaged with a different package name, I spaced on the fact that this was
> actually Avalon code, and compounded the problem by omitting the author
> names of the original authors (Berin and Peter). I apologize to both of
> them for that error, and have corrected it in the commons-logging source
> code. Please let me know if there are any remaining issues in this area.
+1.
>
> (2) Add a trace() level
>
> There was a suggestion to add trace(message) and trace(message,exception)
> methods to the commons-logging API, with the idea that trace is a level
> "below" debug. I'm personally OK with doing that *before* a 1.0 release,
> but will likely oppose it afterwards (adding new public methods to Java
> interfaces is hard on backwards compatibility). Therefore, I think this
> is a "now or never" decision. What do you guys think?
0. Neither for nor agin it.
>
> (3) Change the "message" argument type from Object to String
>
> In all of the current commons-logging API, the "message" argument to all
> of the logging calls is an Object. This allows passing an Object on to
> the underlying logging implementation (currently Log4J supports this, but
> it's also possible to write your own application-specific wrappers using
> things like the Chain of Responsibility pattern, but there is a potential
> security concern that the logging system might call methods on your object
> and modify its state.
>
> I believe that the security concern can be dealt with -- the calling
> program can do its own conversion to string beforehand if it is concerned
> -- so would prefer to maintain the flexibility. Geir has proposed an
> alternative of supporting both method signatures. Comments?
I'm +1 on maintaining the current approach. Objects are more flexible.
Even if you are not using Log4J, you can and may want to introduce your own
implementation of the Logging interface to interact with particular objects
before passing them onto another logger. So basing the interface on Objects
is not necessarily specific to Log4J.
Also, the Sun JDK 1.3.1 implementation of String.toString() is amazingly
performant!
/**
* This object (which is already a string!) is itself returned.
*
* @return the string itself.
*/
public String toString() {
return this;
}
Genius!
-Morgan
>
> Let's try to move towards resolution on these issues in the next day or
> so.
>
> Craig McClanahan
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
Posted by Paulo Gaspar <pa...@krankikom.de>.
> > (2) Add a trace() level
> >
> > There was a suggestion to add trace(message) and
> trace(message,exception)
> > methods to the commons-logging API, with the idea that trace is a level
> > "below" debug. I'm personally OK with doing that *before* a
> 1.0 release,
> > but will likely oppose it afterwards (adding new public methods to Java
> > interfaces is hard on backwards compatibility). Therefore, I think this
> > is a "now or never" decision. What do you guys think?
> >
>
> +1. I think this should be done, if it would be vetoed at a later date.
> I am happy to add this myself.
Funny... somewhere between the 50K lines and the 90K lines of code in my
current project, I started having doubts about the "just 5 debug levels"
idea that Peter and Ceki (used to?) defend.
Actually, if I had to choose just 5, I would choose:
1 TRACE
2 DEBUG
3 WARN
4 INFO
5 ERROR
and skip FATAL... which (argh!) gets me a bit closer to agree with JSR047.
Ok, to redeem myself a bit from such sin, I still think they (JSR47) have
too many "finesse" levels and that FATAL (missing in JSR47), while maybe
having a lower use count has a critical usefulness. Not to talk about the
very cluttered API!
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Scott Sanders [mailto:sanders@apache.org]
> Sent: Wednesday, January 30, 2002 8:17 PM
> To: Jakarta Commons Developers List
> Subject: Re: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
>
>
> On Wed, Jan 30, 2002 at 08:40:27AM -0800, Craig R. McClanahan wrote:
> > Out of the "discussions" yesterday, the proposal to release
> > commons-logging 1.0 received a sufficient number of +1 votes to pass.
> > Howeer, three issues were raised that should be settled beforehand, in
> > order to provide future users of this package with a stable
> API. I'd like
> > to review them individually so we can move forwards.
> >
> >
> > (1) Attribution
> >
> > As was pointed out, the developers of the Avalon framework, and the
> > logging abstractions and implementations they have developed, had an
> > influence on the development of the Commons Logging API. In particular,
> > my implementation of the JDK 1.4 wrapper was based primarily on Avalon
> > code. Because of time pressures at the time, and the fact that it was
> > packaged with a different package name, I spaced on the fact
> that this was
> > actually Avalon code, and compounded the problem by omitting the author
> > names of the original authors (Berin and Peter). I apologize to both of
> > them for that error, and have corrected it in the commons-logging source
> > code. Please let me know if there are any remaining issues in
> this area.
> >
> >
> > (2) Add a trace() level
> >
> > There was a suggestion to add trace(message) and
> trace(message,exception)
> > methods to the commons-logging API, with the idea that trace is a level
> > "below" debug. I'm personally OK with doing that *before* a
> 1.0 release,
> > but will likely oppose it afterwards (adding new public methods to Java
> > interfaces is hard on backwards compatibility). Therefore, I think this
> > is a "now or never" decision. What do you guys think?
> >
>
> +1. I think this should be done, if it would be vetoed at a later date.
> I am happy to add this myself.
>
> >
> > (3) Change the "message" argument type from Object to String
> >
> > In all of the current commons-logging API, the "message" argument to all
> > of the logging calls is an Object. This allows passing an Object on to
> > the underlying logging implementation (currently Log4J supports
> this, but
> > it's also possible to write your own application-specific wrappers using
> > things like the Chain of Responsibility pattern, but there is a
> potential
> > security concern that the logging system might call methods on
> your object
> > and modify its state.
> >
> > I believe that the security concern can be dealt with -- the calling
> > program can do its own conversion to string beforehand if it is
> concerned
> > -- so would prefer to maintain the flexibility. Geir has proposed an
> > alternative of supporting both method signatures. Comments?
> >
>
> +0, I am fine with it staying Object, and I am fine with there being two
> different methods for each.
>
> I am -1, however on only having a String impl.
>
> >
> > Let's try to move towards resolution on these issues in the next day or
> > so.
> >
> > Craig McClanahan
> >
>
> --
> Scott Sanders - sanders@apache.org
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
Posted by Scott Sanders <sa...@apache.org>.
On Wed, Jan 30, 2002 at 08:40:27AM -0800, Craig R. McClanahan wrote:
> Out of the "discussions" yesterday, the proposal to release
> commons-logging 1.0 received a sufficient number of +1 votes to pass.
> Howeer, three issues were raised that should be settled beforehand, in
> order to provide future users of this package with a stable API. I'd like
> to review them individually so we can move forwards.
>
>
> (1) Attribution
>
> As was pointed out, the developers of the Avalon framework, and the
> logging abstractions and implementations they have developed, had an
> influence on the development of the Commons Logging API. In particular,
> my implementation of the JDK 1.4 wrapper was based primarily on Avalon
> code. Because of time pressures at the time, and the fact that it was
> packaged with a different package name, I spaced on the fact that this was
> actually Avalon code, and compounded the problem by omitting the author
> names of the original authors (Berin and Peter). I apologize to both of
> them for that error, and have corrected it in the commons-logging source
> code. Please let me know if there are any remaining issues in this area.
>
>
> (2) Add a trace() level
>
> There was a suggestion to add trace(message) and trace(message,exception)
> methods to the commons-logging API, with the idea that trace is a level
> "below" debug. I'm personally OK with doing that *before* a 1.0 release,
> but will likely oppose it afterwards (adding new public methods to Java
> interfaces is hard on backwards compatibility). Therefore, I think this
> is a "now or never" decision. What do you guys think?
>
+1. I think this should be done, if it would be vetoed at a later date.
I am happy to add this myself.
>
> (3) Change the "message" argument type from Object to String
>
> In all of the current commons-logging API, the "message" argument to all
> of the logging calls is an Object. This allows passing an Object on to
> the underlying logging implementation (currently Log4J supports this, but
> it's also possible to write your own application-specific wrappers using
> things like the Chain of Responsibility pattern, but there is a potential
> security concern that the logging system might call methods on your object
> and modify its state.
>
> I believe that the security concern can be dealt with -- the calling
> program can do its own conversion to string beforehand if it is concerned
> -- so would prefer to maintain the flexibility. Geir has proposed an
> alternative of supporting both method signatures. Comments?
>
+0, I am fine with it staying Object, and I am fine with there being two
different methods for each.
I am -1, however on only having a String impl.
>
> Let's try to move towards resolution on these issues in the next day or
> so.
>
> Craig McClanahan
>
--
Scott Sanders - sanders@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
Posted by Paulo Gaspar <pa...@krankikom.de>.
Craig,
Since I made those remarks, I would like to add that there is no doubt
in my mind that you only omitted credit because you did not notice it.
Your past talks for you - I always saw you giving credit when it was
due and even when you did not have to.
Besides, to perform the amount of work you do I can only imagine that
you must skip reading bits here and there.
=;o)
Thanks for the correction.
All the best,
Paulo Gaspar
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Wednesday, January 30, 2002 5:40 PM
> To: commons-dev@jakarta.apache.org
> Subject: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
>
<SNIP />
>
> (1) Attribution
>
> As was pointed out, the developers of the Avalon framework, and the
> logging abstractions and implementations they have developed, had an
> influence on the development of the Commons Logging API. In particular,
> my implementation of the JDK 1.4 wrapper was based primarily on Avalon
> code. Because of time pressures at the time, and the fact that it was
> packaged with a different package name, I spaced on the fact that this was
> actually Avalon code, and compounded the problem by omitting the author
> names of the original authors (Berin and Peter). I apologize to both of
> them for that error, and have corrected it in the commons-logging source
> code. Please let me know if there are any remaining issues in this area.
>
<SNIP />
>
> Let's try to move towards resolution on these issues in the next day or
> so.
>
> Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
Posted by co...@covalent.net.
On Fri, 1 Feb 2002, Paulo Gaspar wrote:
> Now, since you are also a security freak (like Peter Donald) I
> have a (Devil's Advocate) question:
> - What is the way to avoid that a "hostile logger" accesses the
> objects that are passed to it?
I'll send a longer email with comments on the logger - makeNewLogInstance
is _very_ bad, and I'm sure Peter will point this out very soon :-)
( Ceki fixed this problem in log4j with a 'guard', there are other ways ).
In any case, if the application is not trusting the logger, it shouldn't
send information to it or call it. If it's not trusting the logger - it
can send Strings or other imutable objects.
However the logger will probably have more permissions than the
application ( file access to log dir, etc ), so it's the logger that has
to be protected from bad apps, not the reverse. And the current impl.
doesn't seem to do that.
I'm also not sure I like the discovery and creation mechanism - I would
rather have a mechanism similar with jaxp, which is more flexible than
the current fixed set of Class.forName().
And I don't like the mixing of impl. and interfaces at all.
Again, that's just a quick look, I have a bit to much work to do.
> Anyway, me thinks that it is not so natural that a "hostile
> logger" creeps into a system. Not as natural as an "hostile app"
> in a web/app service provider scenario.
That's my view as well.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
Posted by Paulo Gaspar <pa...@krankikom.de>.
Sh*t Costin!
I was completely convinced that the String argument was the way
to go and you had to come up with a technical argument that
really makes some sense!
=:o/
Now I am divided again! You and your object (bean?) counter habit!
=;o)
Well, I guess that your arguments make a lot of sense for software
where performance is critical.
Now, since you are also a security freak (like Peter Donald) I
have a (Devil's Advocate) question:
- What is the way to avoid that a "hostile logger" accesses the
objects that are passed to it?
Anyway, me thinks that it is not so natural that a "hostile
logger" creeps into a system. Not as natural as an "hostile app"
in a web/app service provider scenario.
Have fun,
Paulo
> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
> Sent: Thursday, January 31, 2002 10:53 PM
> To: Jakarta Commons Developers List
> Subject: Re: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
>
>
> On Wed, 30 Jan 2002, Craig R. McClanahan wrote:
>
> > (3) Change the "message" argument type from Object to String
>
> A big -1.
>
> Object in the interface will allow loggers to provide 'render'-like
> capability. This would allow passing things like StringBuffer or
> Object[] - that can be recycled.
>
> Think about an access log file - this would require about 5-6
> concatenations, etc.
>
> If some logger impl. doesn't provide 'renderer' - it'll still be useable
> by apps that do not need it. The reverse is not true - if the API
> uses Strings, apps will not be able to take advantage of advanced
> loggers.
>
> Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release
Posted by co...@covalent.net.
On Wed, 30 Jan 2002, Craig R. McClanahan wrote:
> (3) Change the "message" argument type from Object to String
A big -1.
Object in the interface will allow loggers to provide 'render'-like
capability. This would allow passing things like StringBuffer or
Object[] - that can be recycled.
Think about an access log file - this would require about 5-6
concatenations, etc.
If some logger impl. doesn't provide 'renderer' - it'll still be useable
by apps that do not need it. The reverse is not true - if the API
uses Strings, apps will not be able to take advantage of advanced
loggers.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>