RE: cvs commit:jakarta-commons/logging/src/java/org/apache/common s/logging/implLogFactoryImpl.java

[Steve Downey <st...@netfolio.com>]

> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
> Sent: Thursday, February 14, 2002 1:50 PM
> To: Jakarta Commons Developers List
> Subject: RE: cvs
> commit:jakarta-commons/logging/src/java/org/apache/common
> s/logging/implLogFactoryImpl.java
> 
> 
> On Wed, 13 Feb 2002, Steve Downey wrote:
> 
> > Any logging during construction would have to go to the 
> system default
> > logger. Whatever that is. 
> 
> Not if you want the components to be useable in a secure ( 
> sandboxed ) 
> environment. 
> 
> Costin
> 
> 

But how? Digester doesn't know about the customer's custom logging
hierarchy. It can get to the system default logging system by calling
LogFactory.getLog(getClass()). It doesn't have it's own log factory yet, as
it was just constructed. Now, the system default logger may have been
configured by some outside mechanism, but Digester (for example) can't do
it. In any case, even if there was some mechanism by which Digester could
get at a non system default logger, by your arguments, it can not be relied
on to do so. Substitute for Digester RandomThirdPartyComponent, or the
web-app itself.

If LogFactory.getLog(getClass()) isn't safe, then security is hopeless. The
only way it can be safe is if the container arranges for it to be safe. Not
exposing the container's logging to the webapps is necessary, although not
sufficient. Using separate classloaders for each webapp is also probably
required.

In any case, the underlying logging package *has* to provide the same
facility. Otherwise, using the native logging api would subvert security.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: cvs commit:jakarta-commons/logging/src/java/org/apache/common s/logging/implLogFactoryImpl.java

[co...@covalent.net]

On Thu, 14 Feb 2002, Steve Downey wrote:

> If LogFactory.getLog(getClass()) isn't safe, then security is hopeless. The
> only way it can be safe is if the container arranges for it to be safe. Not
> exposing the container's logging to the webapps is necessary, although not
> sufficient. Using separate classloaders for each webapp is also probably
> required.

What I mean is: if Digester.getLog( getClass() ) calls log4j's 
Category.getInstance( "org.apache....Digester" ), and log4j is installed 
in the common class loader, then all webapps using Digester will have 
their log go to the same place. Think about a hosting service ( ASP ),
you don't want customer's logs mixed.

The LogFactory must be able to support independent hierarchies. It is 
mostly the job of the logger implementation - but the API and the 
wrappers it provides must also support this. For example LogFactoryImpl
is caching instances - so if installed in the common loader it'll
fail to separate apps, regardless of the underlying logger.

Please don't assume the logger will only be loaded in a leaf 
class loader ( i.e. by the webapp, and not in commons ). I would
point again to JAXP - at the beggining you would just put it 
in the webapp and work. But then it started to be used in the container,
and took a rewrite of the container class loader to make it 
possible to use different parsers in different apps. And now
JAXP is part of JDK1.4, in rt.jar.

I don't think commons-logging will end up in JDK1.5, but it's
likley it'll be used in tomcat and in components that have to
be in the common loader. And hopefully tomcat will 'plug' into
the logger - at least to flush the buffers when shutting down,
and more importantely in sandbox mode, to provide the doPriviledged
blocks that will be required.

If you are in a sandbox - no file logger will work. The only 
way to log in a file ( or socket, etc ) is to have  the 
commons-logger.jar in a special location with granted privs,
and use doPriviledged() to allow webapps to log. 

I can't imagine a good way to do that without having commons-logger
in a common class loader.


> In any case, the underlying logging package *has* to provide the same
> facility. Otherwise, using the native logging api would subvert security.

The API must be designed with security and container-use in mind - it's 
extremely hard to add it back later. Of course the underlying logging
package has to be secure - but if the logging API is caching the 
Log keyed on name it'll just brake whatever the logging impl. does.

Now we use the thread class loader as a namespace - and we're 
ok. A guard or similar mechanism is still needed if you want 
to share logs between apps - but that's probably not a big priority.


Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [logging] Default log

[James Strachan <ja...@yahoo.co.uk>]

----- Original Message -----
From: <co...@covalent.net>
> The current default is NoOp. I would like to change this to SimpleLog. If
> no other logger is found we don't want to lose messages - I think it
> is a huge mistake to default to 'don't log anything if a logger can't be
> found'.

+1.

> Also, for SimpleLog - I would like to change the default level to
> info ( or warn ). Error is far too high, it's better to get more
> info by default than to get none ( in a corectly configured
> situation you'll get what's configured, but if something is
> wrong you should get as much as possible ).

+1 for warn, maybe going to System.err.

Maybe info is too low.

James



_________________________________________________________
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] Default log

[Oleg V Alexeev <oa...@apache.org>]

Hello costinm,

Friday, February 15, 2002, 7:00:00 AM, you wrote:

ccn> The current default is NoOp. I would like to change this to SimpleLog. If 
ccn> no other logger is found we don't want to lose messages - I think it
ccn> is a huge mistake to default to 'don't log anything if a logger can't be 
ccn> found'.

ccn> Also, for SimpleLog - I would like to change the default level to 
ccn> info ( or warn ). Error is far too high, it's better to get more 
ccn> info by default than to get none ( in a corectly configured 
ccn> situation you'll get what's configured, but if something is 
ccn> wrong you should get as much as possible ).

One addition - add stream property to the SimpleLog with default init
to the System.out or System.err.

-- 
Best regards,
 Oleg                            mailto:oalexeev@apache.org



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [logging] Default log

[Paulo Gaspar <pa...@krankikom.de>]

I am so quiet because I completely agree with Costin and he
is doing the talking.

Just to say that there is another voice saying the same.


Have fun,
Paulo Gaspar

> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
> Sent: Friday, February 15, 2002 11:20 PM
> To: Jakarta Commons Developers List; Morgan Delagrange
> Subject: Re: [logging] Default log
>
>
> On Fri, 15 Feb 2002, Morgan Delagrange wrote:
>
> > Probably not a good idea, because at certain log levels we
> would be sending
> > DEBUG information to standard error, which would really junk up
> logs that
> > specifically divert standard error to another file.  Your true error
> > messages would get buried in a mish-mash of debug statements.
>
> Same is true if we log to stdout, except that normal output will also
> get messed. I agree with Craig, stderr is better.
>
>
> > IMO "info" is too high.  Some applications generate a lot of
> "info" output.
> > However, I'm not too concerned about it; I doubt many users will use
> > SimpleLog for long.
>
> 'info' maps ( at least in my view ) to normal messages like "Application
> started succefully", etc. Things that you want to see.
>
> Warns, error, fatal reflect 'special' conditions, if everything works
> you'll not see any of those anyway.
>
> BTW, since commons-logging is supposed to act as a wrapper for
> multiple loggers, I hope in a future version ( 1.1 maybe ) it
> can also provide a 'default' setting for those loggers that
> is consistent ( and default to a reasonable level like info ).
>
> > An alternative to defaulting to SimpleLog would be to take the Log4J
> > approach; immediately print out a single error message if a logger
> > implementation has not been selected, then default to NoOp.
> This would be
> > my preference, I think.
>
> And subject the users to yet-another-configuration-nightmare ?
> I would stick with println(), it's faster and better and works
> without requiring me to set system properties ( which I may not
> be able to ) or learn a new system.
>
> Droping a jar file in lib/ is reasonably easy. I hope to fix
> the Log4jFactory to detect somehow if a config is present, and if
> not to provide some decent defaults - so using log4j instead
> of SimpleLog would just provide speed and more features, not
> config overhead.
>
> ( but I don't want to hold the release for that - I think
> the API is in a decent shape, and it can go on, we'll improve
> it in future versions if we need to )
>
> Costin
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [logging] Default log

[co...@covalent.net]

On Fri, 15 Feb 2002, Morgan Delagrange wrote:

> Probably not a good idea, because at certain log levels we would be sending
> DEBUG information to standard error, which would really junk up logs that
> specifically divert standard error to another file.  Your true error
> messages would get buried in a mish-mash of debug statements.

Same is true if we log to stdout, except that normal output will also
get messed. I agree with Craig, stderr is better.


> IMO "info" is too high.  Some applications generate a lot of "info" output.
> However, I'm not too concerned about it; I doubt many users will use
> SimpleLog for long.

'info' maps ( at least in my view ) to normal messages like "Application 
started succefully", etc. Things that you want to see.

Warns, error, fatal reflect 'special' conditions, if everything works 
you'll not see any of those anyway. 

BTW, since commons-logging is supposed to act as a wrapper for 
multiple loggers, I hope in a future version ( 1.1 maybe ) it
can also provide a 'default' setting for those loggers that
is consistent ( and default to a reasonable level like info ). 

> An alternative to defaulting to SimpleLog would be to take the Log4J
> approach; immediately print out a single error message if a logger
> implementation has not been selected, then default to NoOp.  This would be
> my preference, I think.

And subject the users to yet-another-configuration-nightmare ? 
I would stick with println(), it's faster and better and works 
without requiring me to set system properties ( which I may not 
be able to ) or learn a new system.

Droping a jar file in lib/ is reasonably easy. I hope to fix 
the Log4jFactory to detect somehow if a config is present, and if
not to provide some decent defaults - so using log4j instead 
of SimpleLog would just provide speed and more features, not 
config overhead.

( but I don't want to hold the release for that - I think
the API is in a decent shape, and it can go on, we'll improve
it in future versions if we need to )

Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [logging] Default log

[Morgan Delagrange <md...@yahoo.com>]

----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, February 14, 2002 10:49 PM
Subject: Re: [logging] Default log


>
>
> On Thu, 14 Feb 2002 costinm@covalent.net wrote:
>
> > Date: Thu, 14 Feb 2002 20:00:00 -0800 (PST)
> > From: costinm@covalent.net
> > Reply-To: Jakarta Commons Developers List
<co...@jakarta.apache.org>
> > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > Subject: [logging] Default log
> >
> > The current default is NoOp. I would like to change this to SimpleLog.
If
> > no other logger is found we don't want to lose messages - I think it
> > is a huge mistake to default to 'don't log anything if a logger can't be
> > found'.
> >
>
> My only problem with this is applications that use System.out for their
> own output (such as a "filter" in the traditional Unix sense of programs
> that read standard input and write to standard output).
>
> Maybe SimpleLog should go to standard error instead?

Probably not a good idea, because at certain log levels we would be sending
DEBUG information to standard error, which would really junk up logs that
specifically divert standard error to another file.  Your true error
messages would get buried in a mish-mash of debug statements.

> > Also, for SimpleLog - I would like to change the default level to
> > info ( or warn ). Error is far too high, it's better to get more
> > info by default than to get none ( in a corectly configured
> > situation you'll get what's configured, but if something is
> > wrong you should get as much as possible ).
> >
>
> My preference would be "warn" if we default to System.out, or "info" if we
> default to someplace else.

IMO "info" is too high.  Some applications generate a lot of "info" output.
However, I'm not too concerned about it; I doubt many users will use
SimpleLog for long.

> >
> > Costin
> >
>
> Craig
>

An alternative to defaulting to SimpleLog would be to take the Log4J
approach; immediately print out a single error message if a logger
implementation has not been selected, then default to NoOp.  This would be
my preference, I think.

- Morgan




_________________________________________________________
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] Default log

["Craig R. McClanahan" <cr...@apache.org>]

On Thu, 14 Feb 2002 costinm@covalent.net wrote:

> Date: Thu, 14 Feb 2002 20:00:00 -0800 (PST)
> From: costinm@covalent.net
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: [logging] Default log
>
> The current default is NoOp. I would like to change this to SimpleLog. If
> no other logger is found we don't want to lose messages - I think it
> is a huge mistake to default to 'don't log anything if a logger can't be
> found'.
>

My only problem with this is applications that use System.out for their
own output (such as a "filter" in the traditional Unix sense of programs
that read standard input and write to standard output).

Maybe SimpleLog should go to standard error instead?

> Also, for SimpleLog - I would like to change the default level to
> info ( or warn ). Error is far too high, it's better to get more
> info by default than to get none ( in a corectly configured
> situation you'll get what's configured, but if something is
> wrong you should get as much as possible ).
>

My preference would be "warn" if we default to System.out, or "info" if we
default to someplace else.

>
> Costin
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

[logging] Default log

[co...@covalent.net]

The current default is NoOp. I would like to change this to SimpleLog. If 
no other logger is found we don't want to lose messages - I think it
is a huge mistake to default to 'don't log anything if a logger can't be 
found'.

Also, for SimpleLog - I would like to change the default level to 
info ( or warn ). Error is far too high, it's better to get more 
info by default than to get none ( in a corectly configured 
situation you'll get what's configured, but if something is 
wrong you should get as much as possible ).



Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>