You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Raymond DeCampo <rd...@twcny.rr.com> on 2005/07/29 13:41:08 UTC
[Fwd: Re: Logging Strategy/best practice]
Anybody know if the claims below have any merit? This is from a post on
comp.lang.programmer.
Thanks,
Ray
-------- Original Message --------
Subject: Re: Logging Strategy/best practice
Date: Fri, 29 Jul 2005 10:06:24 +0300
From: A_Wieminer <no...@nomail.com>
Organization: Elisa Internet customer
Newsgroups: comp.lang.java.programmer
References: <11...@g44g2000cwa.googlegroups.com>
<7o...@twister.nyroc.rr.com>
>> 3. Anything else I should consider?
> Use the XML format for the properties file, not the .properties format.
FYI, Tomcat5.5.x uses a new JULI (java.util.logging.interface) logging
for web applications. It can use JDKLog, Log4j or other implementations.
I have read from tomcat site, that if you use Log4j as a logging
implementation you _must_ use .properties format. Its something to do
with how webapp-level logging is configured and xml format
incompatibilities. It is supposed to be fixed in later Log4j versions.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [Fwd: Re: Logging Strategy/best practice]
Posted by Jacob Kjome <ho...@visi.com>.
At 12:21 PM 7/29/2005 -0500, you wrote:
>
>On Jul 29, 2005, at 11:43 AM, Curt Arnold wrote:
>
>Looking at the 1.2 code it appears that it already tries to just warn
>the user if it encounters a validation error. Is there a problem
>(other than a warning) that appears when there is non-ID value used
>for the name?
>
It would appear that you are correct. I just tested and got this in
Tomcat's stderr.log...
log4j:ERROR Parsing error on line 18 and column 101
log4j:ERROR Attribute value
"org.apache.catalina.core.ContainerBase.[Catalina].[localhost]" of type ID
must be a name.
However, I still get logging for the localhost logger, defined as....
<logger
name="org.apache.catalina.core.ContainerBase.[Catalina].[localhost]"
additivity="false">
<level value="INFO"/>
<appender-ref ref="LOCALHOST"/>
</logger>
I could have sworn that I had more problems than this before, but I guess
not. So, it looks as if this is not so serious as I had originally
thought. I think I saw the error a long while back and decided that i
shouldn't be using a config that gives me errors. Since then, this has
translated into "can't use XML for configuration in Tomcat using
Log4j-1.2.xx". I have been using builds of Log4j-1.3 for quite a while, so
I'm a bit out of practice with 1.2.xx.
Sorry for sounding the warning bells! In any case, maybe displaying a
"log4j:ERROR" is a bit much for something that doesn't actually cause any
problems? I would think WARN would be better, or even nothing at all if it
doesn't affect logging.
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [Fwd: Re: Logging Strategy/best practice]
Posted by Curt Arnold <ca...@apache.org>.
On Jul 29, 2005, at 11:43 AM, Curt Arnold wrote:
>
> On Jul 29, 2005, at 9:16 AM, Jacob Kjome wrote:
>
>> Of course, we could release a modified version of the DTD in
>> Log4j-1.2.12 with
>> the "name" attribute not declared as of type "id". Thoughts?
>>
>
> Using a type ID for name was not a good choice, but I don't think
> we can change it. If anybody was using the log4j.dtd in a
> different context, they possibly could have depended on the ID-ness
> of name since there are certain DOM methods
> (Document.getElementById for example) that would behave differently
> if the type was changed.
>
> I think the safer approach is to modify the error handler so a
> validation error is treated as a warning. So in this case, you
> might see an warning from the XML parser that the name is not valid
> according to the DTD, but things would still work. Turning off
> validation entirely (effectively what the JoranConfigurator did)
> would be another option.
>
Looking at the 1.2 code it appears that it already tries to just warn
the user if it encounters a validation error. Is there a problem
(other than a warning) that appears when there is non-ID value used
for the name?
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [Fwd: Re: Logging Strategy/best practice]
Posted by Curt Arnold <ca...@apache.org>.
On Jul 29, 2005, at 9:16 AM, Jacob Kjome wrote:
> Of course, we could release a modified version of the DTD in
> Log4j-1.2.12 with
> the "name" attribute not declared as of type "id". Thoughts?
Using a type ID for name was not a good choice, but I don't think we
can change it. If anybody was using the log4j.dtd in a different
context, they possibly could have depended on the ID-ness of name
since there are certain DOM methods (Document.getElementById for
example) that would behave differently if the type was changed.
I think the safer approach is to modify the error handler so a
validation error is treated as a warning. So in this case, you might
see an warning from the XML parser that the name is not valid
according to the DTD, but things would still work. Turning off
validation entirely (effectively what the JoranConfigurator did)
would be another option.
If we get any feedback on the WebSphere XML issue, I'd be willing to
try to knock both of them down quickly.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [Fwd: Re: Logging Strategy/best practice]
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Raymond DeCampo <rd...@twcny.rr.com>:
> Anybody know if the claims below have any merit? This is from a post on
> comp.lang.programmer.
>
I'm not completely sure about all the workings of JULI, but yes, if you use
Logj4-1.2.xx, then you need to use the .properties format for Tomcat. The
reason is that the logger names that Tomcat uses for its host and context
loggers contain characters that aren't allowed in an XML attribute of type
"id". In the DOMConfigurator, the "name" attribute is of type "id". For
instance, a host logger would look like this...
org.apache.catalina.core.ContainerBase.[Catalina].[localhost]
The square brackets aren't allowed by an attribute of type "id" in XML. And
since the DOMConfigurator uses a DTD, this is enforced. In Log4j-1.3, use of
the JoranConfigurator, which doesn't use a DTD, works around this.
Of course, we could release a modified version of the DTD in Log4j-1.2.12 with
the "name" attribute not declared as of type "id". Thoughts?
Jake
> Thanks,
> Ray
>
> -------- Original Message --------
> Subject: Re: Logging Strategy/best practice
> Date: Fri, 29 Jul 2005 10:06:24 +0300
> From: A_Wieminer <no...@nomail.com>
> Organization: Elisa Internet customer
> Newsgroups: comp.lang.java.programmer
> References: <11...@g44g2000cwa.googlegroups.com>
> <7o...@twister.nyroc.rr.com>
>
> >> 3. Anything else I should consider?
> > Use the XML format for the properties file, not the .properties format.
>
> FYI, Tomcat5.5.x uses a new JULI (java.util.logging.interface) logging
> for web applications. It can use JDKLog, Log4j or other implementations.
>
> I have read from tomcat site, that if you use Log4j as a logging
> implementation you _must_ use .properties format. Its something to do
> with how webapp-level logging is configured and xml format
> incompatibilities. It is supposed to be fixed in later Log4j versions.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [Fwd: Re: Logging Strategy/best practice]
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
It's true Tomcat 5.5.7 and later (not all 5.5.x releases) come with JULI, a
tiny library Remy put in place to do away with the logging configuration
difficulties. It's true that JULI should be configured with a properties
file. But, as the documentation
(http://jakarta.apache.org/tomcat/tomcat-5.5-doc/logging.html) states, users
still can and should configure their own log4j settings for their webapp,
and they can do so in any of the log4j-supported mechanisms, including XML
configuration. So while the tomcat logging configuration at
$CATALINA_HOME/common is in properties format, the user configuration format
in their webapp is up to them. That part of the assertion in the post you
quote is false.
However, the doc isn't perfectly clear on this. I should probably clarify
it further.
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA
yoavs@computer.org / yoavsh@sloan.mit.edu
> -----Original Message-----
> From: Raymond DeCampo [mailto:rdecampo@twcny.rr.com]
> Sent: Friday, July 29, 2005 7:41 AM
> To: log4j-dev@logging.apache.org
> Subject: [Fwd: Re: Logging Strategy/best practice]
>
> Anybody know if the claims below have any merit? This is from a post on
> comp.lang.programmer.
>
> Thanks,
> Ray
>
> -------- Original Message --------
> Subject: Re: Logging Strategy/best practice
> Date: Fri, 29 Jul 2005 10:06:24 +0300
> From: A_Wieminer <no...@nomail.com>
> Organization: Elisa Internet customer
> Newsgroups: comp.lang.java.programmer
> References: <11...@g44g2000cwa.googlegroups.com>
> <7o...@twister.nyroc.rr.com>
>
> >> 3. Anything else I should consider?
> > Use the XML format for the properties file, not the .properties format.
>
> FYI, Tomcat5.5.x uses a new JULI (java.util.logging.interface) logging
> for web applications. It can use JDKLog, Log4j or other implementations.
>
> I have read from tomcat site, that if you use Log4j as a logging
> implementation you _must_ use .properties format. Its something to do
> with how webapp-level logging is configured and xml format
> incompatibilities. It is supposed to be fixed in later Log4j versions.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org