RE: [Logging] [VOTE-REDUX] Commons Logging 1.0 Release

[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

[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>