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 Jacob Kjome <ho...@visi.com> on 2004/11/25 19:46:50 UTC
Re: Log4j-1.3 autoconfiguration default?
(note: I tried to send this with a zip attachment previously, but the
whole email was rejected from the list. I'm sending it to Ceki separately)
Ok, I've tried out 1.3alpha2 and I'm having some problems...
1. I couldn't figure out how to properly specify a rolling appender with a
size based triggering policy. From the examples, it seems that I have to
combine it with the sliding window rolling policy, and I thought I had it
set up correctly, but it always bombed out saying that I had to set
"activeFileName" param. I did that and it still failed. In fact, it
caused Tomcat to fail to start. I simply moved back to using a time based
rolling policy for everything and it succeeded, sort of. Tomcat was able
to start, but the log shows some nasty stuff. Read on....
2. The resulting log file shows some crazy stuff with lots of exceptions,
seemingly with a root cause of Log4j htting null pointers. Here's a
partial stack trace (notice that log4j wasn't compiled with debugging
info. Might want to modify the build to add that)...
Caused by: java.lang.NullPointerException
at org.apache.log4j.LogManager.getLogger(Unknown Source)
at org.apache.log4j.Logger.getLogger(Unknown Source)
at
org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.java:229)
at
org.apache.commons.logging.impl.Log4JLogger.<init>(Log4JLogger.java:65)
at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
... 19 more
I've provided the full log, plus my xml config for log4j as well as a
.properties config file that works fine with Log4j-1.2.9 just to prove that
logging with log4j in general works for Tomcat. So either my config file
is out of whack or log4j-1.3 is not compatible with Tomcat-5.5.x. Oh, and
commons-logging-1.0.4.jar is in common/lib along with log4j-1.3.jar.
Thoughts?
Jake
At 12:01 PM 11/25/2004 +0100, you wrote:
>At 11:23 PM 11/24/2004, Jacob Kjome wrote:
>
>
>>Thought I would try out Log4j-1.3 to configure Tomcat-5.5.4. I patched
>>together
>>a log4j.xml file from examples I found in the testcase inputs for Log4j.
>>However, it seems like DOMConfigurator is being used for
autoconfiguration. I
>>thought this had changed to JoranConfigurator. Am I just missing
something or
>>is JoranConfigurator not being used by default for autoconfiguration?
>
>Jake,
>
>You might want to try alpha2... :-)
>
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-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: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:08 AM 12/1/2004, Jacob Kjome wrote:
>At 07:57 PM 11/30/2004 +0100, you wrote:
> >At 06:51 PM 11/30/2004, Jacob Kjome wrote:
> >
> >>I don't have the code to look at right now, so let me see if I'm
> understanding
> >>you. You are suggesting that we can eat our cake and have it too. If the
> >>passed in selector doesn't have the default repository set for it, then we
> >>would fall back to the existing default repository (Hierarchy) from the
> >>default
> >>selector. If this is what you are saying, then yes, I concur.
> >
> >I made small changes to the RepositorySelector interface and to LogManager
> >as discussed in my previous message. It should all work as expected.
> >
>
>Hi Ceki,
>
>Unfortunately, I think you are still missing my point. The changes to the
>RepositorySelector interface are good. The change to the LogManager is a
>bit mysterious. I guess it is trying to protect against overriding the
>default logger repository of custom selectors which initiate a default
>repository in their constructor? Because that's the only way the default
>repository would actually exist in selectors instantiated within the
>static initialization code of LogManager. I guess that might be a
>legitimate check? Can't hurt either way. However, it doesn't address my
>original point at all, though I can use the same code change from the
>static initialization code within the LogManager.setRepositorySelector()
>for the same effect there, which is what I was trying to point out in the
>first place. To make it abundantly clear what I am talking about, look at
>the change I just committed. I'm positive this is correct and it fixes
>all the null pointers which, BTW, cause all apps in Tomcat to cease to
>work. It is clearly the right thing to do. If you really disagree, you
>can always back it out, but I can't see why you would want to.
>
>Bottom line is that external initializing code should never ever be able
>to bring down every app in the server by simply forgetting to set a
>default logger repository on the custom selector. We shouldn't override a
>default logger repository that has been set, but we should definitely make
>sure it doesn't stay null if it wasn't set. And the default repository of
>choice is the same one that was on the previous selector. That way, the
>transition is seamless. Anyway, take a look, and try this under
>Tomcat-5.5.4, not Tomcat-5.0.xx. Also, the problem would never show
>itself if you started up by passing the selector name in via the -D
>parameter on the command line. It would only occur in the case where the
>default selector was being used and then some initializer code called
>LogManager.setRepositorySelector().
>
>
>Jake
>
>
> >
> >--
> >Ceki Gülcü
> >
> > The complete log4j manual: http://qos.ch/eclm
> > Professional log4j support: http://qos.ch/log4jSupport
> >
> >
> >
> >---------------------------------------------------------------------
> >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
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Andy McBride <an...@pcmsgroup.com>.
Hi Jake,
On Sat, 04 Dec 2004 00:18:13 -0600
Jacob Kjome <ho...@visi.com> wrote:
>At 03:24 AM 12/4/2004 +0000, you wrote:
> >Hi Ceki,
> > I'm having several interesting problems
> >trying to build and run the log4j unit tests at the
>moment
> >on my system which I suspect are due to my environment
>not
> >being quite right yet after a recent clean OS
>re-install
> >:-(
> >
>
>Can you explain your issue? There is one case where unit
>tests depend on code in "examples" source tree
>(InterpreterTest) causing compile failures if you don't
>have "examples/src" configured as a location for source
>files. I don't care for this kind of invalid dependency
>and have a proposed patch for this which is sitting in my
>sandbox.
I have posted a new thread to discuss the issues: "Unit
test dependencies"
I have posted a couple messages to this point
>on log4j-dev, but haven't gotten any feedback.
> Basically, it affects Joran stuff and I'm not
>comfortable committing changes to that area of the code
>without Ceki's approval (hint, hint).
Ceki did respond to your post, see my update on that
thread.
>
> >
> >Perhaps I should also create a bugzilla item to track
>this
> >NullPointer issue and link it to this thread so it
> >can be re-visited later with fresh-eyes when the
>current
> >sprint is done?
> >
>
>Good idea. Go for it.
Will do.
>
> >Regards
> >
> >Andy
> >
>
>Jake
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail:
>log4j-dev-help@logging.apache.org
>
The information contained in this e-mail is intended only for the person or
entity to which it is addressed and may contain confidential and/or
privileged material. If You are not the intended recipient of this e-mail,
the use of this information or any disclosure, copying or distribution is
Prohibited and may be unlawful. If you received this in error, please
contact the sender and delete the material from any computer. The views
expressed in this e-mail may not necessarily be the views of The PCMS Group
plc and should not be taken as authority to carry out any instruction
contained.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Jacob Kjome <ho...@visi.com>.
At 03:24 AM 12/4/2004 +0000, you wrote:
>Hi Ceki,
> I'm having several interesting problems
>trying to build and run the log4j unit tests at the moment
>on my system which I suspect are due to my environment not
>being quite right yet after a recent clean OS re-install
>:-(
>
Can you explain your issue? There is one case where unit tests depend on
code in "examples" source tree (InterpreterTest) causing compile failures
if you don't have "examples/src" configured as a location for source
files. I don't care for this kind of invalid dependency and have a
proposed patch for this which is sitting in my sandbox. I have posted a
couple messages to this point on log4j-dev, but haven't gotten any
feedback. Basically, it affects Joran stuff and I'm not comfortable
committing changes to that area of the code without Ceki's approval (hint,
hint).
>
>Perhaps I should also create a bugzilla item to track this
>NullPointer issue and link it to this thread so it
>can be re-visited later with fresh-eyes when the current
>sprint is done?
>
Good idea. Go for it.
>Regards
>
>Andy
>
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Integration Testing [Was: Log4j-1.3 autoconfiguration
default?]
Posted by Andy McBride <an...@pcmsgroup.com>.
Hi,
On Tue, 7 Dec 2004 16:37:29 -0800 (PST)
Yoav Shapira <yo...@apache.org> wrote:
>Hi,
>Embedding Tomcat is easy. All you need is shown in one
>class,
>http://jakarta.apache.org/tomcat/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/startup/Embedded.html
>(this link is for Tomcat 5.5, but the class changed only
>minimally during the
>past couple of years as we've moved through Tomcat 4.0,
>4.1, 5.0, and 5.5).
>
>Make sure to look at its main method
>(http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/),
>as it contains a complete example, including stopping and
>starting individual
>components of Tomcat.
Hey, where's it gone? I don't see a main method on either
of these links, did the method get moved to Catalina.java
in same package?
>
>There are other ways to embed Tomcat or parts thereof,
>mostly JMX-driven, but
>we use the Embedded class above to run our own unit
>tests, and I suspect it's
>all we need for testing log4j as well.
This sounds good, thanks for the info.
>
>Yoav Shapira http://www.yoavshapira.com
>
>--- Andy McBride <an...@pcmsgroup.com> wrote:
>
>> On Tue, 07 Dec 2004 20:21:48 +0100
>> Ceki Gülcü <ce...@qos.ch> wrote:
>> >At 04:24 AM 12/4/2004, Andy McBride wrote:
>> >
>> >>Ok. The current frenzy around the 1.3 alpha release
>>is
>> >>great to see. I would love
>> >>to help increase the quality of the release in any way
>>I
>> >>can. I was hoping to find some time to start
>>increasing
>> >>the unit test coverage and javadoc along with testing
>>the
>> >>new functionality.
>> >>
>> >>Apart from the new stuff in HISTORY.txt can you
>>suggest
>> >>any other areas in need of attention or more
>> >>unit testing?
>> >
>> >
>> >If can't think of any really easy unit test. However,
>>if
>> >you are not
>> >put of by a little challenge, checking for correct
>> >release of
>> >resources (by log4j) in case of web-application
>>recycling
>> >would really
>> >be useful.
>>
>> Its only interesting if it's challenging!
>>
>> It would indeed be comforting to know that log4 handled
>> app-server life-cycle events correctly.
>>
>> >
>> >In other words, you'd to implement test cases verifying
>> >that log4j
>> >behaves properly within the target environment, say a
>> >Servlet
>> >Container such as Tomcat or Jetty. I believe this kind
>> >of
>> >testing is called integration testing.
>>
>> sounds right up my street.
>>
>> >
>> >There are two major branches to these tests, one using
>>a
>> >log4j.jar
>> >file per web-app and the other using a single log4j.jar
>> >in conjunction
>> >with JNDIContextSelector. The latter requires JNDI
>> >support from the
>> >Container.
>> >
>> >I started by looking at Jetty with JNDI support. The
>> >last time I
>> >looked this meant 'org.mortbay.jetty.plus.jar'.
>>
>> Aha, this sheds some light. I hit jetty dependency
>> problems building the unit tests which I mentioned on
>> another thread.
>> I was confused as I had a quick look at the jetty
>> home page and FAQ and saw nothing about JNDI support.
>> Didn't notice the JettyPlus project!
>>
>> >If you can manage to
>> >embed Tomcat (instead of Jetty) into the test
>>environment
>> >that would
>> >be even better. (I made no attempts at embedding
>>Tomcat.)
>>
>> An interesting idea. I've had a fair bit of experience
>> setting up and using tomcat but so far havn't had an
>> excuse
>> to investigate the embedded side of it yet. I'll start
>> digging.
>>
>> >
>> >In any case, even the simplest test cases would be much
>> >better than
>> >what we have currently.
>> >
>> >Interested?
>>
>> Definitely, and any pointers Yoav could share regarding
>> tomcat embedded would be useful.
>>
>> This could also aid aid in the ability to test the new
>> JndiSubstitutionPropertyAction.
>> These tests can be built and run optionally only where
>> the dependencies are satisfied.
>>
>> Regards
>>
>> Andy
>>
>> >
>> >>Regards
>> >>
>> >>Andy
>> >
>> >--
>> >Ceki Gülcü
>> >
>> > The complete log4j manual: http://qos.ch/log4j/
>> >
>> >
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail:
>> >log4j-dev-unsubscribe@logging.apache.org
>> >For additional commands, e-mail:
>> >log4j-dev-help@logging.apache.org
>> >
>>
>>
>> The information contained in this e-mail is intended
>>only for the person or
>> entity to which it is addressed and may contain
>>confidential and/or
>> privileged material. If You are not the intended
>>recipient of this e-mail,
>> the use of this information or any disclosure, copying
>>or distribution is
>> Prohibited and may be unlawful. If you received this in
>>error, please
>> contact the sender and delete the material from any
>>computer. The views
>> expressed in this e-mail may not necessarily be the
>>views of The PCMS Group
>> plc and should not be taken as authority to carry out
>>any instruction
>> contained.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
The information contained in this e-mail is intended only for the person or
entity to which it is addressed and may contain confidential and/or
privileged material. If You are not the intended recipient of this e-mail,
the use of this information or any disclosure, copying or distribution is
Prohibited and may be unlawful. If you received this in error, please
contact the sender and delete the material from any computer. The views
expressed in this e-mail may not necessarily be the views of The PCMS Group
plc and should not be taken as authority to carry out any instruction
contained.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Integration Testing [Was: Log4j-1.3 autoconfiguration default?]
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
Embedding Tomcat is easy. All you need is shown in one class,
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/startup/Embedded.html
(this link is for Tomcat 5.5, but the class changed only minimally during the
past couple of years as we've moved through Tomcat 4.0, 4.1, 5.0, and 5.5).
Make sure to look at its main method
(http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/),
as it contains a complete example, including stopping and starting individual
components of Tomcat.
There are other ways to embed Tomcat or parts thereof, mostly JMX-driven, but
we use the Embedded class above to run our own unit tests, and I suspect it's
all we need for testing log4j as well.
Yoav Shapira http://www.yoavshapira.com
--- Andy McBride <an...@pcmsgroup.com> wrote:
> On Tue, 07 Dec 2004 20:21:48 +0100
> Ceki G�lc� <ce...@qos.ch> wrote:
> >At 04:24 AM 12/4/2004, Andy McBride wrote:
> >
> >>Ok. The current frenzy around the 1.3 alpha release is
> >>great to see. I would love
> >>to help increase the quality of the release in any way I
> >>can. I was hoping to find some time to start increasing
> >>the unit test coverage and javadoc along with testing the
> >>new functionality.
> >>
> >>Apart from the new stuff in HISTORY.txt can you suggest
> >>any other areas in need of attention or more
> >>unit testing?
> >
> >
> >If can't think of any really easy unit test. However, if
> >you are not
> >put of by a little challenge, checking for correct
> >release of
> >resources (by log4j) in case of web-application recycling
> >would really
> >be useful.
>
> Its only interesting if it's challenging!
>
> It would indeed be comforting to know that log4 handled
> app-server life-cycle events correctly.
>
> >
> >In other words, you'd to implement test cases verifying
> >that log4j
> >behaves properly within the target environment, say a
> >Servlet
> >Container such as Tomcat or Jetty. I believe this kind
> >of
> >testing is called integration testing.
>
> sounds right up my street.
>
> >
> >There are two major branches to these tests, one using a
> >log4j.jar
> >file per web-app and the other using a single log4j.jar
> >in conjunction
> >with JNDIContextSelector. The latter requires JNDI
> >support from the
> >Container.
> >
> >I started by looking at Jetty with JNDI support. The
> >last time I
> >looked this meant 'org.mortbay.jetty.plus.jar'.
>
> Aha, this sheds some light. I hit jetty dependency
> problems building the unit tests which I mentioned on
> another thread.
> I was confused as I had a quick look at the jetty
> home page and FAQ and saw nothing about JNDI support.
> Didn't notice the JettyPlus project!
>
> >If you can manage to
> >embed Tomcat (instead of Jetty) into the test environment
> >that would
> >be even better. (I made no attempts at embedding Tomcat.)
>
> An interesting idea. I've had a fair bit of experience
> setting up and using tomcat but so far havn't had an
> excuse
> to investigate the embedded side of it yet. I'll start
> digging.
>
> >
> >In any case, even the simplest test cases would be much
> >better than
> >what we have currently.
> >
> >Interested?
>
> Definitely, and any pointers Yoav could share regarding
> tomcat embedded would be useful.
>
> This could also aid aid in the ability to test the new
> JndiSubstitutionPropertyAction.
> These tests can be built and run optionally only where
> the dependencies are satisfied.
>
> Regards
>
> Andy
>
> >
> >>Regards
> >>
> >>Andy
> >
> >--
> >Ceki G�lc�
> >
> > The complete log4j manual: http://qos.ch/log4j/
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> >log4j-dev-unsubscribe@logging.apache.org
> >For additional commands, e-mail:
> >log4j-dev-help@logging.apache.org
> >
>
>
> The information contained in this e-mail is intended only for the person or
> entity to which it is addressed and may contain confidential and/or
> privileged material. If You are not the intended recipient of this e-mail,
> the use of this information or any disclosure, copying or distribution is
> Prohibited and may be unlawful. If you received this in error, please
> contact the sender and delete the material from any computer. The views
> expressed in this e-mail may not necessarily be the views of The PCMS Group
> plc and should not be taken as authority to carry out any instruction
> contained.
>
>
> ---------------------------------------------------------------------
> 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: Integration Testing [Was: Log4j-1.3 autoconfiguration
default?]
Posted by Andy McBride <an...@pcmsgroup.com>.
On Tue, 07 Dec 2004 20:21:48 +0100
Ceki Gülcü <ce...@qos.ch> wrote:
>At 04:24 AM 12/4/2004, Andy McBride wrote:
>
>>Ok. The current frenzy around the 1.3 alpha release is
>>great to see. I would love
>>to help increase the quality of the release in any way I
>>can. I was hoping to find some time to start increasing
>>the unit test coverage and javadoc along with testing the
>>new functionality.
>>
>>Apart from the new stuff in HISTORY.txt can you suggest
>>any other areas in need of attention or more
>>unit testing?
>
>
>If can't think of any really easy unit test. However, if
>you are not
>put of by a little challenge, checking for correct
>release of
>resources (by log4j) in case of web-application recycling
>would really
>be useful.
Its only interesting if it's challenging!
It would indeed be comforting to know that log4 handled
app-server life-cycle events correctly.
>
>In other words, you'd to implement test cases verifying
>that log4j
>behaves properly within the target environment, say a
>Servlet
>Container such as Tomcat or Jetty. I believe this kind
>of
>testing is called integration testing.
sounds right up my street.
>
>There are two major branches to these tests, one using a
>log4j.jar
>file per web-app and the other using a single log4j.jar
>in conjunction
>with JNDIContextSelector. The latter requires JNDI
>support from the
>Container.
>
>I started by looking at Jetty with JNDI support. The
>last time I
>looked this meant 'org.mortbay.jetty.plus.jar'.
Aha, this sheds some light. I hit jetty dependency
problems building the unit tests which I mentioned on
another thread.
I was confused as I had a quick look at the jetty
home page and FAQ and saw nothing about JNDI support.
Didn't notice the JettyPlus project!
>If you can manage to
>embed Tomcat (instead of Jetty) into the test environment
>that would
>be even better. (I made no attempts at embedding Tomcat.)
An interesting idea. I've had a fair bit of experience
setting up and using tomcat but so far havn't had an
excuse
to investigate the embedded side of it yet. I'll start
digging.
>
>In any case, even the simplest test cases would be much
>better than
>what we have currently.
>
>Interested?
Definitely, and any pointers Yoav could share regarding
tomcat embedded would be useful.
This could also aid aid in the ability to test the new
JndiSubstitutionPropertyAction.
These tests can be built and run optionally only where
the dependencies are satisfied.
Regards
Andy
>
>>Regards
>>
>>Andy
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/log4j/
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail:
>log4j-dev-help@logging.apache.org
>
The information contained in this e-mail is intended only for the person or
entity to which it is addressed and may contain confidential and/or
privileged material. If You are not the intended recipient of this e-mail,
the use of this information or any disclosure, copying or distribution is
Prohibited and may be unlawful. If you received this in error, please
contact the sender and delete the material from any computer. The views
expressed in this e-mail may not necessarily be the views of The PCMS Group
plc and should not be taken as authority to carry out any instruction
contained.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 04:24 AM 12/4/2004, Andy McBride wrote:
>Ok. The current frenzy around the 1.3 alpha release is great to see. I
>would love
>to help increase the quality of the release in any way I can. I was
>hoping to find some time to start increasing the unit test coverage and
>javadoc along with testing the new functionality.
>
>Apart from the new stuff in HISTORY.txt can you suggest any other areas in
>need of attention or more
>unit testing?
If can't think of any really easy unit test. However, if you are not
put of by a little challenge, checking for correct release of
resources (by log4j) in case of web-application recycling would really
be useful.
In other words, you'd to implement test cases verifying that log4j
behaves properly within the target environment, say a Servlet
Container such as Tomcat or Jetty. I believe this kind of
testing is called integration testing.
There are two major branches to these tests, one using a log4j.jar
file per web-app and the other using a single log4j.jar in conjunction
with JNDIContextSelector. The latter requires JNDI support from the
Container.
I started by looking at Jetty with JNDI support. The last time I
looked this meant 'org.mortbay.jetty.plus.jar'. If you can manage to
embed Tomcat (instead of Jetty) into the test environment that would
be even better. (I made no attempts at embedding Tomcat.)
In any case, even the simplest test cases would be much better than
what we have currently.
Interested?
>Regards
>
>Andy
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Andy McBride <an...@pcmsgroup.com>.
Hi Ceki,
On Fri, 03 Dec 2004 13:49:39 +0100
Ceki Gülcü <ce...@qos.ch> wrote:
>
>Hello Andy,
>
>Thank you for taking the time to express your concerns. I
>appreciate
>it. While I agree with most of your comments, it think it
>is important
>to put them in relation with the facts.
>
>1) The NPE problem cannot be triggered from configuration
>files but
>only by java code actively trying to set up a custom
>RepositorySelector. At this time, very few people do
>that.
I agree, the problem is likely to be rare but I was
concerned that because the impact
can be so severe to the appserver, that a few occurrences
could spread FUD about
the stability of the 1.3 release.
>
>2) Item 1.2 in the FAQ, is one of the guiding principles
>behind
>log4j. You correctly point out that not catching the NPE
>contravenes
>this principle.
>
>My argument is two fold.
>
>1) This particular NPE problem concerns only few select
>developers all
>of which are expected to be of high caliber or at least
>curious enough
>to spend a few cycles on the problem. (Admittedly, they
>can make
>mistakes too.)
Agreed. Any developer working with the 1.3 alpha release
should be prepared to 'spend a few cycles'
on any 'issues'. I'm having several interesting problems
trying to build and run the log4j unit tests at the moment
on my system which I suspect are due to my environment not
being quite right yet after a recent clean OS re-install
:-(
I was just hoping that this type of issue could be
resolved by the time 1.3 reaches release candidate?
>
>2) The particular defensive solution proposed was of the
>"ignore the developer, log4j knows best" kind. Hence, my
>-1.
I understand your caution. Whilst an end-user application
can freely validate and prevent illegal
input, a library such as log4j should not generally
'second-guess' the developer.
My understanding is that this problem will only occur if
the developer fails to correctly configure the repository
selector.
The only issue is how log4j handles this recognised
problem. It can either:
1) throw a NPE, IllegalStateException or other unchecked
runtime exception potentially halting the VM.
2) throw a new specific checked exception
(SelectorConfigException) forcing the developer to
explicitly catch and deal with the
scenario as he feels fit).
3)ignore the developer and use a default which may not be
what the developer expects.
>
>Catching the NPE and providing the user with a useful
>pointer (pun
>unintended) is a solution worth exploring. However,
>currently we have
>other problems affecting many more users, hence my
>request to put the
>NPE aside for the time being. We can easily come back to
>it later.
>
Ok. The current frenzy around the 1.3 alpha release is
great to see. I would love
to help increase the quality of the release in any way I
can. I was hoping to find some time to
start increasing the unit test coverage and javadoc along
with testing the new functionality.
Apart from the new stuff in HISTORY.txt can you suggest
any other areas in need of attention or more
unit testing?
The clover unit test coverage analysis suggested by Curt
Arnold in the
"Joran, RollingFileAppender, and Rollover failure
warnings" thread would be useful here.
I have also found this tool useful in the past, simply to
highlight areas of the code possibly in need of
love and attention.
Perhaps I should also create a bugzilla item to track this
NullPointer issue and link it to this thread so it
can be re-visited later with fresh-eyes when the current
sprint is done?
Regards
Andy
>
>At 02:00 AM 12/3/2004, Andy McBride wrote:
>>Please don't allow log4j to throw any unnecessary
>>RuntimeException's be they NullPointers or
>>IllegalStateExceptions.
>>
>>According to the log4j FAQ question 1.2:
>>
>>"log4j will not throw unexpected exceptions at run-time
>>potentially causing your application to crash. If for any
>>reason, log4j throws an uncaught exception, please send
>>an email to the log4j-user@logging.apache.org mailing
>>list. Uncaught exceptions are handled as serious bugs
>>requiring immediate attention"
>>
>>Simply documenting the problem will not help.
>>
>>"... the RepositorySelector API is designed to be used by
>>developers of Application Servers or 1st class passengers
>>on the clue train..." - I would hope that there are more
>>than 5 of these currently on planet earth and that some
>>of them are capable of mistakes too! Far too many people
>>only get round to reading the docs after the problem has
>>occurred.
>>
>>If I supply log4j with an invalid config file I do not
>>expect it to crash the appserver, similarly if I
>>programatically configure log4j RS incorrectly I also do
>>not expect it to crash the appserver.
>>
>>Putting my Miss Piggy hat on, I think I would always
>>prefer log4j to ignore me and carry on with its existing
>>basic default behaviour if I tried to instruct it to do
>>something silly. A specific checked exception could be
>>(self-f)logged pointing to the exact problem with the
>>config.
>
>
>
>>These are just my humble opinions, please let the debate
>>on this run a bit longer.
>>Regards
>>
>>Andy
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail:
>log4j-dev-help@logging.apache.org
>
The information contained in this e-mail is intended only for the person or
entity to which it is addressed and may contain confidential and/or
privileged material. If You are not the intended recipient of this e-mail,
the use of this information or any disclosure, copying or distribution is
Prohibited and may be unlawful. If you received this in error, please
contact the sender and delete the material from any computer. The views
expressed in this e-mail may not necessarily be the views of The PCMS Group
plc and should not be taken as authority to carry out any instruction
contained.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
Hello Andy,
Thank you for taking the time to express your concerns. I appreciate
it. While I agree with most of your comments, it think it is important
to put them in relation with the facts.
1) The NPE problem cannot be triggered from configuration files but
only by java code actively trying to set up a custom
RepositorySelector. At this time, very few people do that.
2) Item 1.2 in the FAQ, is one of the guiding principles behind
log4j. You correctly point out that not catching the NPE contravenes
this principle.
My argument is two fold.
1) This particular NPE problem concerns only few select developers all
of which are expected to be of high caliber or at least curious enough
to spend a few cycles on the problem. (Admittedly, they can make
mistakes too.)
2) The particular defensive solution proposed was of the
"ignore the developer, log4j knows best" kind. Hence, my -1.
Catching the NPE and providing the user with a useful pointer (pun
unintended) is a solution worth exploring. However, currently we have
other problems affecting many more users, hence my request to put the
NPE aside for the time being. We can easily come back to it later.
At 02:00 AM 12/3/2004, Andy McBride wrote:
>Please don't allow log4j to throw any unnecessary RuntimeException's be
>they NullPointers or IllegalStateExceptions.
>
>According to the log4j FAQ question 1.2:
>
>"log4j will not throw unexpected exceptions at run-time potentially
>causing your application to crash. If for any reason, log4j throws an
>uncaught exception, please send an email to the
>log4j-user@logging.apache.org mailing list. Uncaught exceptions are
>handled as serious bugs requiring immediate attention"
>
>Simply documenting the problem will not help.
>
>"... the RepositorySelector API is designed to be used by developers of
>Application Servers or 1st class passengers on the clue train..." - I
>would hope that there are more than 5 of these currently on planet earth
>and that some of them are capable of mistakes too! Far too many people
>only get round to reading the docs after the problem has occurred.
>
>If I supply log4j with an invalid config file I do not expect it to crash
>the appserver, similarly if I programatically configure log4j RS
>incorrectly I also do not expect it to crash the appserver.
>
>Putting my Miss Piggy hat on, I think I would always prefer log4j to
>ignore me and carry on with its existing basic default behaviour if I
>tried to instruct it to do something silly. A specific checked exception
>could be (self-f)logged pointing to the exact problem with the config.
>These are just my humble opinions, please let the debate on this run a bit
>longer.
>Regards
>
>Andy
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Andy McBride <an...@pcmsgroup.com>.
Please don't allow log4j to throw any unnecessary
RuntimeException's be they NullPointers or
IllegalStateExceptions.
According to the log4j FAQ question 1.2:
"log4j will not throw unexpected exceptions at run-time
potentially causing your application to crash. If for any
reason, log4j throws an uncaught exception, please send an
email to the log4j-user@logging.apache.org mailing list.
Uncaught exceptions are handled as serious bugs requiring
immediate attention"
Simply documenting the problem will not help.
"... the RepositorySelector API is designed to be used by
developers of Application Servers or 1st class passengers
on the clue train..." - I would hope that there are more
than 5 of these currently on planet earth and that some of
them are capable of mistakes too! Far too many people
only get round to reading the docs after the problem has
occurred.
If I supply log4j with an invalid config file I do not
expect it to crash the appserver, similarly if I
programatically configure log4j RS incorrectly I also do
not expect it to crash the appserver.
Putting my Miss Piggy hat on, I think I would always
prefer log4j to ignore me and carry on with its existing
basic default behaviour if I tried to instruct it to do
something silly. A specific checked exception could be
(self-f)logged pointing to the exact problem with the
config.
These are just my humble opinions, please let the debate
on this run a bit longer.
Regards
Andy
On Fri, 03 Dec 2004 07:42:59 +1100
Paul Smith <ps...@aconex.com> wrote:
>Any reason why? NPE's are not useful to the end user.
>
>Ceki Gülcü wrote:
>
>>
>> May I ask you to defer this discussion to later?
>>
>> At 09:45 PM 12/1/2004, Paul Smith wrote:
>>
>>> Can we at the VERY least NOT let the user try to
>>>decipher a
>>> NullPonterException.
>>> Isn't there some way we can detect this situation (since
>>>we clearly
>>> know that it can happen from this discussion), and then
>>>throw some
>>> sort of more informative Exception (my vote would be
>>> IllegalStateException) with some detailed message giving
>>>those users
>>> who perhaps stepped onto the cluetrain illegally (maybe
>>>they didn't
>>> pay?) a bit of a helping hand.
>>> If Kermit the Frog (running out of proverbial users I
>>>think) saw a
>>> NPE, he'd immediately associate that with a bug in log4j
>>>code (even
>>> though he's wrong). Lets be a bit more open about it.
>>>
>>> cheers,
>>>
>>> Paul Smith
>>
>>
>
>--
>
>*Paul Smith
>*Software Architect
>
>
>
>*Aconex
>* 31 Drummond Street, Carlton, VIC 3053, Australia
>*Tel: +61 3 9661 0200 *Fax: +61 3 9654 9946
>Email: psmith@aconex.com www.aconex.com**
>
>This email and any attachments are intended solely for
>the addressee. The contents may be privileged,
>confidential and/or subject to copyright or other
>applicable law. No confidentiality or privilege is lost
>by an erroneous transmission. If you have received this
>e-mail in error, please let us know by reply e-mail and
>delete or destroy this mail and all copies. If you are
>not the intended recipient of this message you must not
>disseminate, copy or take any action in reliance on it.
>The sender takes no responsibility for the effect of this
>message upon the recipient's computer system.**
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail:
>log4j-dev-help@logging.apache.org
>
The information contained in this e-mail is intended only for the person or
entity to which it is addressed and may contain confidential and/or
privileged material. If You are not the intended recipient of this e-mail,
the use of this information or any disclosure, copying or distribution is
Prohibited and may be unlawful. If you received this in error, please
contact the sender and delete the material from any computer. The views
expressed in this e-mail may not necessarily be the views of The PCMS Group
plc and should not be taken as authority to carry out any instruction
contained.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Andy McBride <an...@pcmsgroup.com>.
I raised bugzilla item 32536
(http://issues.apache.org/bugzilla/show_bug.cgi?id=32536)
for this issue and attached a patch and unit test
proposing a solution for this problem.
Cheers
Andy
On Mon, 06 Dec 2004 08:24:21 +1100
Paul Smith <ps...@aconex.com> wrote:
>a) this is not bate
>b) I'm not advocating making a decision for the user, I'm
>just asking for a better message for the user so they can
>quickly sort it out.
>Ceki Gülcü wrote:
>
>> At 09:42 PM 12/2/2004, Paul Smith wrote:
>>
>>> Any reason why? NPE's are not useful to the end user.
>>
>>
>> A bait? I'll take it.
>>
>> Saying that no one has use for NPEs is like saying no
>>one has use for
>> hemorrhoids. For the time being, only Jake encountered
>>this particular
>> NPE issue. He did so because of his very particular
>>context.
>>
>> The debate is about defensive programming. Jake's fix is
>>similar to
>> the following:
>>
>> class UsesFoo {
>> Hammer myHammer = new Hammer();
>> Foo foo;
>>
>> setFoo(Foo foo) {
>> if(foo.getHammer() == 0) {
>> // What, foo does not have a hammer? Surely foo'd
>>wants ours.
>> foo.setHammer(myHammer);
>> }
>> this.foo = foo;
>> }
>>
>> Not all defensive coding is good. I don't like this
>>particular
>> defensive coding style, so I reverted it.
>>
>> Jake has reported other bugs which require attention.
>>I'd rather spend
>> my time with that, than replying to this bate. Oh, well.
>>
>>> Ceki Gülcü wrote:
>>>
>>>>
>>>> May I ask you to defer this discussion to later?
>>>
>>>
>>> --
>>> Ceki Gülcü
>>>
>>> The complete log4j manual: http://qos.ch/eclm
>>> Professional log4j support: http://qos.ch/log4jSupport
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>>log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail:
>>log4j-dev-help@logging.apache.org
>>
>>
>
>--
>
>*Paul Smith
>*Software Architect
>
>
>
>*Aconex
>* 31 Drummond Street, Carlton, VIC 3053, Australia
>*Tel: +61 3 9661 0200 *Fax: +61 3 9654 9946
>Email: psmith@aconex.com www.aconex.com**
>
>This email and any attachments are intended solely for
>the addressee. The contents may be privileged,
>confidential and/or subject to copyright or other
>applicable law. No confidentiality or privilege is lost
>by an erroneous transmission. If you have received this
>e-mail in error, please let us know by reply e-mail and
>delete or destroy this mail and all copies. If you are
>not the intended recipient of this message you must not
>disseminate, copy or take any action in reliance on it.
>The sender takes no responsibility for the effect of this
>message upon the recipient's computer system.**
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail:
>log4j-dev-help@logging.apache.org
>
The information contained in this e-mail is intended only for the person or
entity to which it is addressed and may contain confidential and/or
privileged material. If You are not the intended recipient of this e-mail,
the use of this information or any disclosure, copying or distribution is
Prohibited and may be unlawful. If you received this in error, please
contact the sender and delete the material from any computer. The views
expressed in this e-mail may not necessarily be the views of The PCMS Group
plc and should not be taken as authority to carry out any instruction
contained.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Paul Smith <ps...@aconex.com>.
a) this is not bate
b) I'm not advocating making a decision for the user, I'm just asking
for a better message for the user so they can quickly sort it out.
Ceki Gülcü wrote:
> At 09:42 PM 12/2/2004, Paul Smith wrote:
>
>> Any reason why? NPE's are not useful to the end user.
>
>
> A bait? I'll take it.
>
> Saying that no one has use for NPEs is like saying no one has use for
> hemorrhoids. For the time being, only Jake encountered this particular
> NPE issue. He did so because of his very particular context.
>
> The debate is about defensive programming. Jake's fix is similar to
> the following:
>
> class UsesFoo {
> Hammer myHammer = new Hammer();
> Foo foo;
>
> setFoo(Foo foo) {
> if(foo.getHammer() == 0) {
> // What, foo does not have a hammer? Surely foo'd wants ours.
> foo.setHammer(myHammer);
> }
> this.foo = foo;
> }
>
> Not all defensive coding is good. I don't like this particular
> defensive coding style, so I reverted it.
>
> Jake has reported other bugs which require attention. I'd rather spend
> my time with that, than replying to this bate. Oh, well.
>
>> Ceki Gülcü wrote:
>>
>>>
>>> May I ask you to defer this discussion to later?
>>
>>
>> --
>> Ceki Gülcü
>>
>> The complete log4j manual: http://qos.ch/eclm
>> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
*Paul Smith
*Software Architect
*Aconex
* 31 Drummond Street, Carlton, VIC 3053, Australia
*Tel: +61 3 9661 0200 *Fax: +61 3 9654 9946
Email: psmith@aconex.com www.aconex.com**
This email and any attachments are intended solely for the addressee.
The contents may be privileged, confidential and/or subject to copyright
or other applicable law. No confidentiality or privilege is lost by an
erroneous transmission. If you have received this e-mail in error,
please let us know by reply e-mail and delete or destroy this mail and
all copies. If you are not the intended recipient of this message you
must not disseminate, copy or take any action in reliance on it. The
sender takes no responsibility for the effect of this message upon the
recipient's computer system.**
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 09:42 PM 12/2/2004, Paul Smith wrote:
>Any reason why? NPE's are not useful to the end user.
A bait? I'll take it.
Saying that no one has use for NPEs is like saying no one has use for
hemorrhoids. For the time being, only Jake encountered this particular
NPE issue. He did so because of his very particular context.
The debate is about defensive programming. Jake's fix is similar to
the following:
class UsesFoo {
Hammer myHammer = new Hammer();
Foo foo;
setFoo(Foo foo) {
if(foo.getHammer() == 0) {
// What, foo does not have a hammer? Surely foo'd wants ours.
foo.setHammer(myHammer);
}
this.foo = foo;
}
Not all defensive coding is good. I don't like this particular
defensive coding style, so I reverted it.
Jake has reported other bugs which require attention. I'd rather spend
my time with that, than replying to this bate. Oh, well.
>Ceki Gülcü wrote:
>
>>
>>May I ask you to defer this discussion to later?
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Paul Smith <ps...@aconex.com>.
Any reason why? NPE's are not useful to the end user.
Ceki Gülcü wrote:
>
> May I ask you to defer this discussion to later?
>
> At 09:45 PM 12/1/2004, Paul Smith wrote:
>
>> Can we at the VERY least NOT let the user try to decipher a
>> NullPonterException.
>> Isn't there some way we can detect this situation (since we clearly
>> know that it can happen from this discussion), and then throw some
>> sort of more informative Exception (my vote would be
>> IllegalStateException) with some detailed message giving those users
>> who perhaps stepped onto the cluetrain illegally (maybe they didn't
>> pay?) a bit of a helping hand.
>> If Kermit the Frog (running out of proverbial users I think) saw a
>> NPE, he'd immediately associate that with a bug in log4j code (even
>> though he's wrong). Lets be a bit more open about it.
>>
>> cheers,
>>
>> Paul Smith
>
>
--
*Paul Smith
*Software Architect
*Aconex
* 31 Drummond Street, Carlton, VIC 3053, Australia
*Tel: +61 3 9661 0200 *Fax: +61 3 9654 9946
Email: psmith@aconex.com www.aconex.com**
This email and any attachments are intended solely for the addressee.
The contents may be privileged, confidential and/or subject to copyright
or other applicable law. No confidentiality or privilege is lost by an
erroneous transmission. If you have received this e-mail in error,
please let us know by reply e-mail and delete or destroy this mail and
all copies. If you are not the intended recipient of this message you
must not disseminate, copy or take any action in reliance on it. The
sender takes no responsibility for the effect of this message upon the
recipient's computer system.**
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
May I ask you to defer this discussion to later?
At 09:45 PM 12/1/2004, Paul Smith wrote:
>Can we at the VERY least NOT let the user try to decipher a
>NullPonterException.
>Isn't there some way we can detect this situation (since we clearly know
>that it can happen from this discussion), and then throw some sort of more
>informative Exception (my vote would be IllegalStateException) with some
>detailed message giving those users who perhaps stepped onto the cluetrain
>illegally (maybe they didn't pay?) a bit of a helping hand.
>If Kermit the Frog (running out of proverbial users I think) saw a NPE,
>he'd immediately associate that with a bug in log4j code (even though he's
>wrong). Lets be a bit more open about it.
>
>cheers,
>
>Paul Smith
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Paul Smith <ps...@aconex.com>.
Can we at the VERY least NOT let the user try to decipher a
NullPonterException.
Isn't there some way we can detect this situation (since we clearly know
that it can happen from this discussion), and then throw some sort of
more informative Exception (my vote would be IllegalStateException) with
some detailed message giving those users who perhaps stepped onto the
cluetrain illegally (maybe they didn't pay?) a bit of a helping hand.
If Kermit the Frog (running out of proverbial users I think) saw a NPE,
he'd immediately associate that with a bug in log4j code (even though
he's wrong). Lets be a bit more open about it.
cheers,
Paul Smith
Ceki Gülcü wrote:
> At 06:16 PM 12/1/2004, Jacob Kjome wrote:
>
>> "clue train"? What documentation?
>
>
> The documentation is lacking. Anyway, very few people know to set the
> RS, it must less than 5 people on the planet. We'll document the null
> pointer problem so that people don't forget to set the default
> repository in their custom RS. If they forget, the null pointer will
> remind them soon enough.
>
>> And why shouldn't a developer only need to
>> look at the API? Why should we expect people on the "clue train" to
>> look at
>> every inch of code in a logging API. Ceki, I can see your point to
>> an extent,
>> but sensible and predictable defaults are not, IMO, "side effects".
>> Log4j
>> should be easy to use and shouldn't be able to be used for evil
>> (taking down
>> entire application servers) whether the developer using the API is
>> clueless or
>> a prodogy (doing it with full knowledge out of spite).
>
>
> If, Sideshow Bob, the evil programmer, intentionally leaves the
> default repository blank, setting a default repository in
> LogManger.setRepositotySelector won't help because Sideshow Bob can
> always write:
>
> class EvilRespotirySelector implements RepositorySelector {
>
> LoggerRepository getDefaultRepository() {
> // Sideshow Bob finds pleasure in evil deeds:
> return null;
> }
> }
>
> Security can be only be guaranteed by setting the guard.
>
>> I strongly disagree
>> with your conclusions here and hope you change your mind. At a
>> minimum, I'm
>> satisfied that I've vigorously tried to defend my position.
>
>
> Indeed you have.
>
>> If it doesn't prevail, then I'll drink the coolaide and modify my
>> initialization code to do
>> something that Log4j should do for me in the first place, but that's
>> life and
>> open source.
>
>
> Your position is totally understandable. I hope I could convince you
> that my opposition is not totally brain dead either.
>
>> Jake
>
>
--
*Paul Smith
*Software Architect
*Aconex
* 31 Drummond Street, Carlton, VIC 3053, Australia
*Tel: +61 3 9661 0200 *Fax: +61 3 9654 9946
Email: psmith@aconex.com www.aconex.com**
This email and any attachments are intended solely for the addressee.
The contents may be privileged, confidential and/or subject to copyright
or other applicable law. No confidentiality or privilege is lost by an
erroneous transmission. If you have received this e-mail in error,
please let us know by reply e-mail and delete or destroy this mail and
all copies. If you are not the intended recipient of this message you
must not disseminate, copy or take any action in reliance on it. The
sender takes no responsibility for the effect of this message upon the
recipient's computer system.**
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 06:16 PM 12/1/2004, Jacob Kjome wrote:
>"clue train"? What documentation?
The documentation is lacking. Anyway, very few people know to set the RS,
it must less than 5 people on the planet. We'll document the null pointer
problem so that people don't forget to set the default repository in their
custom RS. If they forget, the null pointer will remind them soon enough.
>And why shouldn't a developer only need to
>look at the API? Why should we expect people on the "clue train" to look at
>every inch of code in a logging API. Ceki, I can see your point to an extent,
>but sensible and predictable defaults are not, IMO, "side effects". Log4j
>should be easy to use and shouldn't be able to be used for evil (taking down
>entire application servers) whether the developer using the API is clueless or
>a prodogy (doing it with full knowledge out of spite).
If, Sideshow Bob, the evil programmer, intentionally leaves the default
repository blank, setting a default repository in
LogManger.setRepositotySelector won't help because Sideshow Bob can always
write:
class EvilRespotirySelector implements RepositorySelector {
LoggerRepository getDefaultRepository() {
// Sideshow Bob finds pleasure in evil deeds:
return null;
}
}
Security can be only be guaranteed by setting the guard.
>I strongly disagree
>with your conclusions here and hope you change your mind. At a minimum, I'm
>satisfied that I've vigorously tried to defend my position.
Indeed you have.
>If it doesn't prevail, then I'll drink the coolaide and modify my
>initialization code to do
>something that Log4j should do for me in the first place, but that's life and
>open source.
Your position is totally understandable. I hope I could convince you that
my opposition is not totally brain dead either.
>Jake
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Ceki Gülcü <ce...@qos.ch>:
> At 07:08 AM 12/1/2004, Jacob Kjome wrote:
> >Hi Ceki,
> >
> >Unfortunately, I think you are still missing my point. The changes to the
> >RepositorySelector interface are good. The change to the LogManager is a
> >bit mysterious. I guess it is trying to protect against overriding the
> >default logger repository of custom selectors which initiate a default
> >repository in their constructor?
>
> Your conclusion is correct as long as it is limited to the scope of
> LogManager's static initializer.
>
The thing is, I never even had this in mind and I see it as far less of a
problem (by leaps and bounds) then the original issue I was addressing. I
think we'd be pretty safe if this check didn't exist. The fact that it does
exist is fine since it doesn't hurt anything, but I don't see it as
particularily important either. I'd put a bet on the fact that no one would
ever run into this issue if we didn't do the check.
> >Because that's the only way the default repository would actually exist in
> >selectors instantiated within the static initialization code of LogManager.
>
> Absolutely.
>
> > I guess that might be a legitimate check? Can't hurt either
> > way. However, it doesn't address my original point at all, though I can
> > use the same code change from the static initialization code within the
> > LogManager.setRepositorySelector() for the same effect there, which is
> > what I was trying to point out in the first place. To make it abundantly
> > clear what I am talking about, look at the change I just committed. I'm
> > positive this is correct and it fixes all the null pointers which, BTW,
> > cause all apps in Tomcat to cease to work. It is clearly the right thing
> > to do. If you really disagree, you can always back it out, but I can't
> > see why you would want to.
>
> It fixes the null pointer problem, for sure. However, introducing side
> effects like you have done eventually become part of the expected behavior
> of your API. You can't change it without breaking code downstream.
> Forgetting to set the default repository will result in a fairly immediate
> crash of the application. So anyone travelling on the clue train will
> figure our that you have to set the default repository in a custom
> selector. It's not rocket science.
>
No, it isn't, but how is a sensible default a "side effect"? In my initializer
code, and I'd bet 99% of everyone else's initializer code, I would do...
RepositorySelector selector = new ContextJNDISelector();
selector.setDefaultLoggerRepository(LogManager.getDefaultLoggerRepository());
LogManager.setRepositorySelector(selector, new Object());
How is a sensible default not simply...
LogManager.setRepositorySelector(new ContextJNDISelector(), new Object());
With the assumption that LogManager would continue with the current selector's
default logger repository? I say "assumption" and I'm guessing your are
cringing at the word, but we make lots of assumptions in Log4j just like in
other software products. As far as assumptions go, this is what for the "duh
file". I cannot imagine that a default of a NullPointerException bringing down
every app in the server is better than this sensible "side effect". Really,
I'm at a loss!
> >Bottom line is that external initializing code should never ever be able
> >to bring down every app in the server by simply forgetting to set a
> >default logger repository on the custom selector. We shouldn't override a
> >default logger repository that has been set, but we should definitely make
> >sure it doesn't stay null if it wasn't set.
>
> It's not our problem to fix. Unmaintainable code is born trying to
> compensate for other people's mistakes. Keeping the hocus-focus level low
> eventually makes a big difference with regards to code maintainability.
>
It is plainly unnacceptable to allow for a default (without documentation to the
fact, I might add) that brings down the entire appserver with one line of
seemingly inocuous logging initialization code. Talk about side effects. This
is the mother of them all. And I'm not sure why this makes code
"unmaintainable"? The developer now types fewer lines and consciously (by not
manually setting the default when it is obvious in the API that they can if
they want) accepts Log4j's sensible (and predictable) default of no change to
the current default logger repository. Am I making any sense here or am I just
living in Bizarro world, because it is sure clear to me.
> > And the default repository of choice is the same one that was on the
> > previous selector. That way, the transition is seamless. Anyway, take a
> > look, and try this under Tomcat-5.5.4, not Tomcat-5.0.xx. Also, the
> > problem would never show itself if you started up by passing the selector
> > name in via the -D parameter on the command line. It would only occur in
> > the case where the default selector was being used and then some
> > initializer code called LogManager.setRepositorySelector().
>
> That is correct but probably not relevant. I am repeating myself but the
> RepositorySelector API is designed to be used by developers of Application
> Servers or 1st class passengers on the clue train. They are expected to
> look at the source code or read the documentation.
>
"clue train"? What documentation? And why shouldn't a developer only need to
look at the API? Why should we expect people on the "clue train" to look at
every inch of code in a logging API. Ceki, I can see your point to an extent,
but sensible and predictable defaults are not, IMO, "side effects". Log4j
should be easy to use and shouldn't be able to be used for evil (taking down
entire application servers) whether the developer using the API is clueless or
a prodogy (doing it with full knowledge out of spite). I strongly disagree
with your conclusions here and hope you change your mind. At a minimum, I'm
satisfied that I've vigorously tried to defend my position. If it doesn't
prevail, then I'll drink the coolaide and modify my initialization code to do
something that Log4j should do for me in the first place, but that's life and
open source.
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:08 AM 12/1/2004, Jacob Kjome wrote:
>Hi Ceki,
>
>Unfortunately, I think you are still missing my point. The changes to the
>RepositorySelector interface are good. The change to the LogManager is a
>bit mysterious. I guess it is trying to protect against overriding the
>default logger repository of custom selectors which initiate a default
>repository in their constructor?
Your conclusion is correct as long as it is limited to the scope of
LogManager's static initializer.
>Because that's the only way the default repository would actually exist in
>selectors instantiated within the static initialization code of LogManager.
Absolutely.
> I guess that might be a legitimate check? Can't hurt either
> way. However, it doesn't address my original point at all, though I can
> use the same code change from the static initialization code within the
> LogManager.setRepositorySelector() for the same effect there, which is
> what I was trying to point out in the first place. To make it abundantly
> clear what I am talking about, look at the change I just committed. I'm
> positive this is correct and it fixes all the null pointers which, BTW,
> cause all apps in Tomcat to cease to work. It is clearly the right thing
> to do. If you really disagree, you can always back it out, but I can't
> see why you would want to.
It fixes the null pointer problem, for sure. However, introducing side
effects like you have done eventually become part of the expected behavior
of your API. You can't change it without breaking code downstream.
Forgetting to set the default repository will result in a fairly immediate
crash of the application. So anyone travelling on the clue train will
figure our that you have to set the default repository in a custom
selector. It's not rocket science.
>Bottom line is that external initializing code should never ever be able
>to bring down every app in the server by simply forgetting to set a
>default logger repository on the custom selector. We shouldn't override a
>default logger repository that has been set, but we should definitely make
>sure it doesn't stay null if it wasn't set.
It's not our problem to fix. Unmaintainable code is born trying to
compensate for other people's mistakes. Keeping the hocus-focus level low
eventually makes a big difference with regards to code maintainability.
> And the default repository of choice is the same one that was on the
> previous selector. That way, the transition is seamless. Anyway, take a
> look, and try this under Tomcat-5.5.4, not Tomcat-5.0.xx. Also, the
> problem would never show itself if you started up by passing the selector
> name in via the -D parameter on the command line. It would only occur in
> the case where the default selector was being used and then some
> initializer code called LogManager.setRepositorySelector().
That is correct but probably not relevant. I am repeating myself but the
RepositorySelector API is designed to be used by developers of Application
Servers or 1st class passengers on the clue train. They are expected to
look at the source code or read the documentation.
>Jake
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Jacob Kjome <ho...@visi.com>.
At 07:57 PM 11/30/2004 +0100, you wrote:
>At 06:51 PM 11/30/2004, Jacob Kjome wrote:
>
>>I don't have the code to look at right now, so let me see if I'm
understanding
>>you. You are suggesting that we can eat our cake and have it too. If the
>>passed in selector doesn't have the default repository set for it, then we
>>would fall back to the existing default repository (Hierarchy) from the
>>default
>>selector. If this is what you are saying, then yes, I concur.
>
>I made small changes to the RepositorySelector interface and to LogManager
>as discussed in my previous message. It should all work as expected.
>
Hi Ceki,
Unfortunately, I think you are still missing my point. The changes to the
RepositorySelector interface are good. The change to the LogManager is a
bit mysterious. I guess it is trying to protect against overriding the
default logger repository of custom selectors which initiate a default
repository in their constructor? Because that's the only way the default
repository would actually exist in selectors instantiated within the static
initialization code of LogManager. I guess that might be a legitimate
check? Can't hurt either way. However, it doesn't address my original
point at all, though I can use the same code change from the static
initialization code within the LogManager.setRepositorySelector() for the
same effect there, which is what I was trying to point out in the first
place. To make it abundantly clear what I am talking about, look at the
change I just committed. I'm positive this is correct and it fixes all the
null pointers which, BTW, cause all apps in Tomcat to cease to work. It is
clearly the right thing to do. If you really disagree, you can always back
it out, but I can't see why you would want to.
Bottom line is that external initializing code should never ever be able to
bring down every app in the server by simply forgetting to set a default
logger repository on the custom selector. We shouldn't override a default
logger repository that has been set, but we should definitely make sure it
doesn't stay null if it wasn't set. And the default repository of choice
is the same one that was on the previous selector. That way, the
transition is seamless. Anyway, take a look, and try this under
Tomcat-5.5.4, not Tomcat-5.0.xx. Also, the problem would never show itself
if you started up by passing the selector name in via the -D parameter on
the command line. It would only occur in the case where the default
selector was being used and then some initializer code called
LogManager.setRepositorySelector().
Jake
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
>---------------------------------------------------------------------
>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: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 06:51 PM 11/30/2004, Jacob Kjome wrote:
>I don't have the code to look at right now, so let me see if I'm understanding
>you. You are suggesting that we can eat our cake and have it too. If the
>passed in selector doesn't have the default repository set for it, then we
>would fall back to the existing default repository (Hierarchy) from the
>default
>selector. If this is what you are saying, then yes, I concur.
I made small changes to the RepositorySelector interface and to LogManager
as discussed in my previous message. It should all work as expected.
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Ceki Gülcü <ce...@qos.ch>:
> At 06:01 PM 11/30/2004, you wrote:
> >Quoting Ceki Gülcü <ce...@qos.ch>:
> >
> > > Jake,
> > >
> > > I see your point. Do you see anything wrong with the following?
> > >
> >
> >The only problem I see with it is that this should be done inside
> >LogManager.setRepositorySelector() rather than in custom initialization code
> >beause we need to guarantee that selector.getLoggerRepository() never
> returns
> >null. We can't do that if we count on external initialization code to "do
> the
> >right thing".
>
> Are you forgetting that in the absence of specific instructions from
> the user, the static initializer in LogManager sets a
> DefaultRepositorySelector and sets the default repository of
> DefaultRepositorySelector? I am referring to line 85 of LogManager.
>
> >Otherwise, my changes would look similar to this. Inside
> >LogManager.setRepositorySelector(), I have something like (from memory)...
> >
> >LoggerRepository currentDefaultRepository =
> >repositorySelector.getLoggerRepository();
> >newSelector.setDefaultRepository(currentDefaultRepository);
> >repositorySelector = newSelector;
>
>
> This code imposes a default repository instance to the new
> selector. Maybe the new selector wants to return its own default
> repository, possibly of a different type than o.a.l.Hiearchy? Do you
> see why leaving LogManager.setRepositorySelector() as is has at least
> some advantages?
>
> Actually, come think of it, to really lave wiggling room for the new
> selector, line 85 should be modified
>
> from:
>
> 84 // at this stage 'repositorySelector' should point to a valid selector
> 85 repositorySelector.setDefaultRepository(defaultHierarchy);
>
> to:
>
> 84 // at this stage 'repositorySelector' should point to a valid selector
> 85 if(repositorySelector.getDefaultRepository() == null) {
> 86 repositorySelector.setDefaultRepository(defaultHierarchy);
> 87 }
>
> Do you concur?
>
I don't have the code to look at right now, so let me see if I'm understanding
you. You are suggesting that we can eat our cake and have it too. If the
passed in selector doesn't have the default repository set for it, then we
would fall back to the existing default repository (Hierarchy) from the default
selector. If this is what you are saying, then yes, I concur.
Jake
> --
> Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
> ---------------------------------------------------------------------
> 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: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 06:01 PM 11/30/2004, you wrote:
>Quoting Ceki Gülcü <ce...@qos.ch>:
>
> > Jake,
> >
> > I see your point. Do you see anything wrong with the following?
> >
>
>The only problem I see with it is that this should be done inside
>LogManager.setRepositorySelector() rather than in custom initialization code
>beause we need to guarantee that selector.getLoggerRepository() never returns
>null. We can't do that if we count on external initialization code to "do the
>right thing".
Are you forgetting that in the absence of specific instructions from
the user, the static initializer in LogManager sets a
DefaultRepositorySelector and sets the default repository of
DefaultRepositorySelector? I am referring to line 85 of LogManager.
>Otherwise, my changes would look similar to this. Inside
>LogManager.setRepositorySelector(), I have something like (from memory)...
>
>LoggerRepository currentDefaultRepository =
>repositorySelector.getLoggerRepository();
>newSelector.setDefaultRepository(currentDefaultRepository);
>repositorySelector = newSelector;
This code imposes a default repository instance to the new
selector. Maybe the new selector wants to return its own default
repository, possibly of a different type than o.a.l.Hiearchy? Do you
see why leaving LogManager.setRepositorySelector() as is has at least
some advantages?
Actually, come think of it, to really lave wiggling room for the new
selector, line 85 should be modified
from:
84 // at this stage 'repositorySelector' should point to a valid selector
85 repositorySelector.setDefaultRepository(defaultHierarchy);
to:
84 // at this stage 'repositorySelector' should point to a valid selector
85 if(repositorySelector.getDefaultRepository() == null) {
86 repositorySelector.setDefaultRepository(defaultHierarchy);
87 }
Do you concur?
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Ceki Gülcü <ce...@qos.ch>:
> Jake,
>
> I see your point. Do you see anything wrong with the following?
>
The only problem I see with it is that this should be done inside
LogManager.setRepositorySelector() rather than in custom initialization code
beause we need to guarantee that selector.getLoggerRepository() never returns
null. We can't do that if we count on external initialization code to "do the
right thing". Otherwise, my changes would look similar to this. Inside
LogManager.setRepositorySelector(), I have something like (from memory)...
LoggerRepository currentDefaultRepository =
repositorySelector.getLoggerRepository();
newSelector.setDefaultRepository(currentDefaultRepository);
repositorySelector = newSelector;
All initialization code should have to worry about is simply call....
LogManger.setRepositorySelector(mySelector, new Object());
Jake
> void myInitialization() {
> // set the selector to MyRepositorySelector, preserving the
> // existing default repository:
> RepositorySelector mySelector = new MyRepositorySelector();
> // assume default selector is in currently in use
> LoggerRepository defaultRepository= LogManger.getLoggerRepository();
> mySelector.setDefaultRepository(defaultRepository);
> try {
> LogManger.setRepositorySelector(mySelector, new Object());
> } catch(IllegalArgumentException iae) {
> // the selector was already set
> }
> ...
> }
>
>
> At 05:20 PM 11/30/2004, Jacob Kjome wrote:
>
> >Well, the way things currently stand, as soon as you switch the repository
> >selector to the new one via LogManager.setRepositorySelector(), the
> >defaultLoggerRepository is null and will always be null because it is not
> >initialized to anything but null. As such, in the case of applications
> >running
> >under Tomcat, any that don't define the log4j/context-name JNDI parameter
> will
> >get the default repository, which is null, therefore necessarily causing
> null
> >pointer exceptions in LogManager.getLogger().
> >
> >My thought is to transfer the configured default repository from the
> original
> >selector to the new one being set. That way, you don't lose the original
> >configuration and loggers using the default repository will continue as they
> >did before the switch of selectors. I really think this is right and I am
> >100%
> >positive that there are problems with the current implementation.
> >
> >
> >Jake
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
> ---------------------------------------------------------------------
> 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: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
Jake,
I see your point. Do you see anything wrong with the following?
void myInitialization() {
// set the selector to MyRepositorySelector, preserving the
// existing default repository:
RepositorySelector mySelector = new MyRepositorySelector();
// assume default selector is in currently in use
LoggerRepository defaultRepository= LogManger.getLoggerRepository();
mySelector.setDefaultRepository(defaultRepository);
try {
LogManger.setRepositorySelector(mySelector, new Object());
} catch(IllegalArgumentException iae) {
// the selector was already set
}
...
}
At 05:20 PM 11/30/2004, Jacob Kjome wrote:
>Well, the way things currently stand, as soon as you switch the repository
>selector to the new one via LogManager.setRepositorySelector(), the
>defaultLoggerRepository is null and will always be null because it is not
>initialized to anything but null. As such, in the case of applications
>running
>under Tomcat, any that don't define the log4j/context-name JNDI parameter will
>get the default repository, which is null, therefore necessarily causing null
>pointer exceptions in LogManager.getLogger().
>
>My thought is to transfer the configured default repository from the original
>selector to the new one being set. That way, you don't lose the original
>configuration and loggers using the default repository will continue as they
>did before the switch of selectors. I really think this is right and I am
>100%
>positive that there are problems with the current implementation.
>
>
>Jake
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Ceki Gülcü <ce...@qos.ch>:
> At 08:16 AM 11/30/2004, Jacob Kjome wrote:
>
> >BTW, I figured out why I was getting all those null pointers. My
> >initialization code calls LogManager.setRepositorySelector() to guarantee
> >that the ContextJNDISelector is used if it hasn't already been
> >installed. The problem is, the defaultRepository field of this new
> >selector is null. The old configured repository field contained in the
> >DefaultRepositorySelector needs to be transfered to the new repository. I
> >now do this inside setRepositorySelector(). I will commit this when I can
> >tomorrow. I have too much debugging code in there right now and I'm
> >already up way too late as it is.
>
> I am not sure I fully understand what you have in mind but I believe that
> current code in LogManager and ContextJNDISelector are correct, at least
> with respect to the setRepositorySelector() method. Note that the default
> repository returned by a given repository selector may be different than
> the default repository LogManager starts off with. Thus, I do not see a
> valid reason to change the LogManager.setRepositorySelector method, if that
> was what you had in mind.
>
Well, the way things currently stand, as soon as you switch the repository
selector to the new one via LogManager.setRepositorySelector(), the
defaultLoggerRepository is null and will always be null because it is not
initialized to anything but null. As such, in the case of applications running
under Tomcat, any that don't define the log4j/context-name JNDI parameter will
get the default repository, which is null, therefore necessarily causing null
pointer exceptions in LogManager.getLogger().
My thought is to transfer the configured default repository from the original
selector to the new one being set. That way, you don't lose the original
configuration and loggers using the default repository will continue as they
did before the switch of selectors. I really think this is right and I am 100%
positive that there are problems with the current implementation.
Jake
> >Jake
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
> ---------------------------------------------------------------------
> 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: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 08:16 AM 11/30/2004, Jacob Kjome wrote:
>BTW, I figured out why I was getting all those null pointers. My
>initialization code calls LogManager.setRepositorySelector() to guarantee
>that the ContextJNDISelector is used if it hasn't already been
>installed. The problem is, the defaultRepository field of this new
>selector is null. The old configured repository field contained in the
>DefaultRepositorySelector needs to be transfered to the new repository. I
>now do this inside setRepositorySelector(). I will commit this when I can
>tomorrow. I have too much debugging code in there right now and I'm
>already up way too late as it is.
I am not sure I fully understand what you have in mind but I believe that
current code in LogManager and ContextJNDISelector are correct, at least
with respect to the setRepositorySelector() method. Note that the default
repository returned by a given repository selector may be different than
the default repository LogManager starts off with. Thus, I do not see a
valid reason to change the LogManager.setRepositorySelector method, if that
was what you had in mind.
>Jake
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Jacob Kjome <ho...@visi.com>.
At 01:04 AM 11/30/2004 +0100, you wrote:
>
>In ContextJNDISelector removed the code that performs a lookup on log4j.xml
>or log4j.properties files (for non-default repositories.) Code checked in.
>
That was the best choice I think.
BTW, I figured out why I was getting all those null pointers. My
initialization code calls LogManager.setRepositorySelector() to guarantee
that the ContextJNDISelector is used if it hasn't already been
installed. The problem is, the defaultRepository field of this new
selector is null. The old configured repository field contained in the
DefaultRepositorySelector needs to be transfered to the new repository. I
now do this inside setRepositorySelector(). I will commit this when I can
tomorrow. I have too much debugging code in there right now and I'm
already up way too late as it is.
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Ceki Gülcü <ce...@qos.ch>:
> At 09:23 PM 11/29/2004, Jacob Kjome wrote:
>
> This would work beautifully as long as the
> "single-getInitialContext-exception-implies-no-NDI" hypothesis is
> universally true. Is it?
>
I'm not 100% positive. We'll have to get some concensus. Maybe Yoav, being a
Tomcat guru, would know the answer?
Jake
>
> >Jake
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
> ---------------------------------------------------------------------
> 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: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 09:23 PM 11/29/2004, Jacob Kjome wrote:
>If JNDIUtil.getInitialContext() fails, then store that fact as a boolean
>member
>variable which will be true by default, but be set to false in the catch
>statement. We'd check the value of the boolean before attempting the
>JNDIUtil.getInitialContext() stuff so, the next time getLoggerRepository() is
>called, it would avoid doing any of the context stuff making the performance,
>essentially, the same as the default selector. Why should this have anything
>to do with classloader?
I think you've got the best of me. So what you are suggesting is this:
public class ContextJNDISelector implements RepositorySelector {
....
// by default, assume is available
booelan jndiAvailable=true;
public LoggerRepository getLoggerRepository() {
String loggingContextName = null;
Context ctx = null;
if(jndiAvailable) {
try {
ctx = JNDIUtil.getInitialContext();
} catch(NamingException ne) {
// a single failure in JNDIUtil.getInitialContext() will
// jndi lookups for good
jndiAvailable = false;
}
// if JNDIUtil.getInitialContext() succeeds, the lookup may still
// fail if the user has not setup the Constants.JNDI_CONTEXT_NAME
variable
// in JNDI, hence the two separate try/catch blocks
try {
loggingContextName = (String) JNDIUtil.lookup(ctx,
Constants.JNDI_CONTEXT_NAME);
} catch (NamingException ne) {
// we can't log here
}
}
if (loggingContextName == null) {
return defaultRepository;
} else { ... }
}
}
This would work beautifully as long as the
"single-getInitialContext-exception-implies-no-NDI" hypothesis is
universally true. Is it?
>Jake
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Ceki Gülcü <ce...@qos.ch>:
> At 08:24 PM 11/29/2004, you wrote:
> >At 08:10 PM 11/29/2004, Jacob Kjome wrote:
> >
> >>Maybe if no provider is found the first time it would skip the JNDI
> >>lookup all
> >>other times, making the performance deficit inconsequential.
> >
> >Nice idea but how do you distinguish between the first time and the next
> >time? I think you can't.
>
> If there is no JNDI, JNDIUtil.getInitialContext() call will always fail.
>
> public LoggerRepository getLoggerRepository() {
> String loggingContextName = null;
> Context ctx = null;
>
> try {
> ctx = JNDIUtil.getInitialContext();
> loggingContextName = (String) JNDIUtil.lookup(ctx,
> Constants.JNDI_CONTEXT_NAME);
> } catch (NamingException ne) {
> // without JNDI we'll always land here
> }
>
> if (loggingContextName == null) {
> return defaultRepository;
> } else { ... }
> }
>
> The only way to speed up the test would be to cache the results depending
> on the thread context classloader and we'd be back to ThreadDeathException
> hell. Anyway, I'd like to stick to the standard JNDI API without assuming
> that JNDI is just a hack around classloaders (which in reality it seems to
> be always the case.)
>
If JNDIUtil.getInitialContext() fails, then store that fact as a boolean member
variable which will be true by default, but be set to false in the catch
statement. We'd check the value of the boolean before attempting the
JNDIUtil.getInitialContext() stuff so, the next time getLoggerRepository() is
called, it would avoid doing any of the context stuff making the performance,
essentially, the same as the default selector. Why should this have anything
to do with classloader?
Jake
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
> ---------------------------------------------------------------------
> 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: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 08:24 PM 11/29/2004, you wrote:
>At 08:10 PM 11/29/2004, Jacob Kjome wrote:
>
>>Maybe if no provider is found the first time it would skip the JNDI
>>lookup all
>>other times, making the performance deficit inconsequential.
>
>Nice idea but how do you distinguish between the first time and the next
>time? I think you can't.
If there is no JNDI, JNDIUtil.getInitialContext() call will always fail.
public LoggerRepository getLoggerRepository() {
String loggingContextName = null;
Context ctx = null;
try {
ctx = JNDIUtil.getInitialContext();
loggingContextName = (String) JNDIUtil.lookup(ctx,
Constants.JNDI_CONTEXT_NAME);
} catch (NamingException ne) {
// without JNDI we'll always land here
}
if (loggingContextName == null) {
return defaultRepository;
} else { ... }
}
The only way to speed up the test would be to cache the results depending
on the thread context classloader and we'd be back to ThreadDeathException
hell. Anyway, I'd like to stick to the standard JNDI API without assuming
that JNDI is just a hack around classloaders (which in reality it seems to
be always the case.)
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 08:10 PM 11/29/2004, Jacob Kjome wrote:
>Maybe if no provider is found the first time it would skip the JNDI lookup all
>other times, making the performance deficit inconsequential.
Nice idea but how do you distinguish between the first time and the next
time? I think you can't.
>Ok, I think we are talking past each other. The fact is, I have debug="false"
>in my log4j.xml and JoranConfigurator spits out internal debugging. When I
>remove debug="false" from log4j.xml, JoranConfigurator no longer spits out
>inernal debugging. The behavior you describe above is what I expect. The
>behavior I actually get, as I've described, doesn't match the expected
>behavior. As such, there must be a bug of some sort.
Was definitely a bug. Bug fixed.
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Ceki Gülcü <ce...@qos.ch>:
> At 02:11 AM 11/29/2004, Jacob Kjome wrote:
>
> >Yep, I actually would have been surprised to have it as the default,
> >especially since a JNDI provider is only available under a J2EE container,
> >so it wouldn't make sense at all for standalone applications.
>
> Without JNDI, ContextJNDISelector would *behave* exactly as the current
> DefaultSelector, at least in terms of the returned repository. Of course,
> it would do so much slower than the DefaultSelector. Anyway, your point is
> well taken.
>
Maybe if no provider is found the first time it would skip the JNDI lookup all
other times, making the performance deficit inconsequential.
> [cut]
>
> >You miss the point on this comment. The error happens, but not because of
> >a clash with the ContextJNDISelector. It has to be something else, but
> >I'm not sure what it is. I actually made a version of the sandbox jar
> >that is 1.3 compatible so that I could still use my initializer code. I
> >think the problem happens when I attempt to set the repository selector
> >(the 1.3 one). I'm not quite sure about this, though. I have to do more
> >investigation.
>
> OK, I'll wait for the results of your investigation.
>
I don't have much time right now, but there is definitely something bad going on
if one calls LogManager.setRepositorySelector() to set the selector. I get the
stack trace where the Log4j hits a null pointer in LogManager constantly. More
later tonight (I hope).
> [cut]
>
> > >Would you like to fix this by adding and using a new method, say
> > >Loader.getResourceByTCLOnly() or should I?
> > >
> >
> >I understand what you are trying to say. However, I think the premise is
> >false. To assume that using the thread context classloader will avoid
> >loading resources from, say..., Tomcat's common/classes is just
> >incorrect. You are right that preference will be given to the resource in
> >WEB-INF/classes. However, if that is not found, normal Java2 classloading
> >behavior resumes and a log4j.xml file in common/classes would, in fact, be
> >found and utilized. I can't imagine what your proposed
> >Loader.getResourceByTCLOnly() would accomplish and I'm not sure it is a
> >solvable problem. The only solution I can see is to perform
> >initialization on non-default repositories if, and only if, the
> >configuration was provided via the "log4j/configuration-resource" JNDI
> >entry and not fall back to loading off the classloader. In this case,
> >applications would need to perform manual configuration. An alternative
> >to this is to keep the current behavior or falling back to the classloader
> >to find the config file and tell users that actually want to perform
> >manual configuration (for whatever reason) to put a minimal config file in
> >WEB-INF/classes to pacify autoconfiguration and then perform the manual
> >configuration that they so desire.
> >
> >Thoughts?
>
> Still digesting...
>
>
> > >>However, it seems that having the "debug" attribute there at all,
> > >>regardless of the value, triggers debugging. I verified this by removing
> > >>the attribute altogether and the Joran parsing logging went away. I
> think
> > >>this is a bug, although I'm not sure exactly where to fix it?
> > >
> > >No, it's supposed to be a feature. :-)
> > >
> >
> >Well, it is a confusing feature. I don't expect debug="false" to turn on
> >internal debugging. This behavior seems reminiscent of boolean attributes
> >in HTML such as "checked" which for XHTML turns into
> >checked="checked". Of course that's simply a hack to keep compatibility
> >between HTML and XHTML. I'm not sure why we'd want to purposefully
> >introduce an XML hack into a Log4j config file? Is it hard using
> >JoranConfigurator to distinguish debug="true" and debug="false" and having
> >the absence of the debug attribute mean debug="false". This would be
> >important to be as compatible as possible with existing log4j.xml files
> >meant for use with the, now deprecated, DOMConfigurator, since many
> >include the debug attribute set to false.
>
> I think you are incorrectly assuming that setting the debug flag to false
> gets interpreted as true.
>
> debug="false" is interpreted as debug set to false.
> debug="true" is interpreted as debug set to true.
> debug="" is interpreted as debug set to true.
> debug="hello_i_just_made_a_typo_when_writing_this" would also be
> interpreted as debug set to true.
>
> In short, if the debug flag is present, its value defaults to true, except
> if set to false. :-)
>
> This interpretation of the debug flag has been in log4j for a very long
> time. It's not new to Joran. Nobody has ever complained about it although
> that does not mean it's not stupid or right.
>
Ok, I think we are talking past each other. The fact is, I have debug="false"
in my log4j.xml and JoranConfigurator spits out internal debugging. When I
remove debug="false" from log4j.xml, JoranConfigurator no longer spits out
inernal debugging. The behavior you describe above is what I expect. The
behavior I actually get, as I've described, doesn't match the expected
behavior. As such, there must be a bug of some sort.
Jake
>
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
> ---------------------------------------------------------------------
> 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: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 02:11 AM 11/29/2004, Jacob Kjome wrote:
>Yep, I actually would have been surprised to have it as the default,
>especially since a JNDI provider is only available under a J2EE container,
>so it wouldn't make sense at all for standalone applications.
Without JNDI, ContextJNDISelector would *behave* exactly as the current
DefaultSelector, at least in terms of the returned repository. Of course,
it would do so much slower than the DefaultSelector. Anyway, your point is
well taken.
[cut]
>You miss the point on this comment. The error happens, but not because of
>a clash with the ContextJNDISelector. It has to be something else, but
>I'm not sure what it is. I actually made a version of the sandbox jar
>that is 1.3 compatible so that I could still use my initializer code. I
>think the problem happens when I attempt to set the repository selector
>(the 1.3 one). I'm not quite sure about this, though. I have to do more
>investigation.
OK, I'll wait for the results of your investigation.
[cut]
> >Would you like to fix this by adding and using a new method, say
> >Loader.getResourceByTCLOnly() or should I?
> >
>
>I understand what you are trying to say. However, I think the premise is
>false. To assume that using the thread context classloader will avoid
>loading resources from, say..., Tomcat's common/classes is just
>incorrect. You are right that preference will be given to the resource in
>WEB-INF/classes. However, if that is not found, normal Java2 classloading
>behavior resumes and a log4j.xml file in common/classes would, in fact, be
>found and utilized. I can't imagine what your proposed
>Loader.getResourceByTCLOnly() would accomplish and I'm not sure it is a
>solvable problem. The only solution I can see is to perform
>initialization on non-default repositories if, and only if, the
>configuration was provided via the "log4j/configuration-resource" JNDI
>entry and not fall back to loading off the classloader. In this case,
>applications would need to perform manual configuration. An alternative
>to this is to keep the current behavior or falling back to the classloader
>to find the config file and tell users that actually want to perform
>manual configuration (for whatever reason) to put a minimal config file in
>WEB-INF/classes to pacify autoconfiguration and then perform the manual
>configuration that they so desire.
>
>Thoughts?
Still digesting...
> >>However, it seems that having the "debug" attribute there at all,
> >>regardless of the value, triggers debugging. I verified this by removing
> >>the attribute altogether and the Joran parsing logging went away. I think
> >>this is a bug, although I'm not sure exactly where to fix it?
> >
> >No, it's supposed to be a feature. :-)
> >
>
>Well, it is a confusing feature. I don't expect debug="false" to turn on
>internal debugging. This behavior seems reminiscent of boolean attributes
>in HTML such as "checked" which for XHTML turns into
>checked="checked". Of course that's simply a hack to keep compatibility
>between HTML and XHTML. I'm not sure why we'd want to purposefully
>introduce an XML hack into a Log4j config file? Is it hard using
>JoranConfigurator to distinguish debug="true" and debug="false" and having
>the absence of the debug attribute mean debug="false". This would be
>important to be as compatible as possible with existing log4j.xml files
>meant for use with the, now deprecated, DOMConfigurator, since many
>include the debug attribute set to false.
I think you are incorrectly assuming that setting the debug flag to false
gets interpreted as true.
debug="false" is interpreted as debug set to false.
debug="true" is interpreted as debug set to true.
debug="" is interpreted as debug set to true.
debug="hello_i_just_made_a_typo_when_writing_this" would also be
interpreted as debug set to true.
In short, if the debug flag is present, its value defaults to true, except
if set to false. :-)
This interpretation of the debug flag has been in log4j for a very long
time. It's not new to Joran. Nobody has ever complained about it although
that does not mean it's not stupid or right.
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
In ContextJNDISelector removed the code that performs a lookup on log4j.xml
or log4j.properties files (for non-default repositories.) Code checked in.
At 02:11 AM 11/29/2004, Jacob Kjome wrote:
>I understand what you are trying to say. However, I think the premise is
>false. To assume that using the thread context classloader will avoid
>loading resources from, say..., Tomcat's common/classes is just
>incorrect. You are right that preference will be given to the resource in
>WEB-INF/classes. However, if that is not found, normal Java2 classloading
>behavior resumes and a log4j.xml file in common/classes would, in fact, be
>found and utilized. I can't imagine what your proposed
>Loader.getResourceByTCLOnly() would accomplish and I'm not sure it is a
>solvable problem. The only solution I can see is to perform
>initialization on non-default repositories if, and only if, the
>configuration was provided via the "log4j/configuration-resource" JNDI
>entry and not fall back to loading off the classloader. In this case,
>applications would need to perform manual configuration. An alternative
>to this is to keep the current behavior or falling back to the classloader
>to find the config file and tell users that actually want to perform
>manual configuration (for whatever reason) to put a minimal config file in
>WEB-INF/classes to pacify autoconfiguration and then perform the manual
>configuration that they so desire.
>
>Thoughts?
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Jacob Kjome <ho...@visi.com>.
At 08:17 PM 11/27/2004 +0100, you wrote:
>At 08:33 AM 11/27/2004, Jacob Kjome wrote:
>>I guess I'll answer my own questions. See more below...
>>
>>At 01:38 PM 11/26/2004 -0600, you wrote:
>> >At 09:02 PM 11/25/2004 +0100, you wrote:
>> > >Jake,
>> > >
>> > >I've just tried log4j-1.3alpha3 with Tomcat 5.0.27 with
>> > >JNDIRepositorySelector. It seems to work nicely.
>> > >
>> >
>> >Is the ContextJNDISelector used by default?
>>
>>No, the DefaultRepositorySelector is the default. Only if I start up
>>providing the system property -Dlog4j.repositorySelectorClass with a value
>>of JNDI or the fully qualified class name of the selector will a selector
>>other than the default be used. Based on the Javadoc, it also looks like
>>it is possible, after the fact, to set the repository selector because the
>>guard will still be null during and after autoconfig. Actually, it will
>>be null until after the first call to
>>LogManager.setRepositorySelctor(selector, guard), correct?
>
>Right on.
>
>Even if ContextJNDISelector looks fairly solid, its seemed and still
>seems too big a leap to set ContextJNDISelector as the default
>selector. We can reconsider for 1.4, 2.0 or whatever the next version
>of log4j will be called.
>
Yep, I actually would have been surprised to have it as the default,
especially since a JNDI provider is only available under a J2EE container,
so it wouldn't make sense at all for standalone applications.
>Regarding the guard issue, I think if the user specifically instructs
>log4j to set a repository selector, we can safely assume that's the
>user's final choice, spurring us to set up a guard. The only question
>is then do we make this guard visible or does it get hidden for the
>remainder of the JVM's life. To keep it simple, my instincts tell me
>that the guard should be set for good. (We have a mandate by
>Mrs. Piggy who implictly told us to do so by setting the
>-Dlog4j.repositorySelectorClass system property.)
>
Agreed
>Jake, you have a fairly good understanding of all this. Why don't you
>make the necessary changes and commit them?
>
I'll look into it and let you know if I have questions.
>> > Based on the behavior I see,
>> >I'm guessing it is. I figured out that the null pointer was caused by my
>> >having the ContextJNDISelector from logging-log4j-sandbox in the
>> >classpath. After I removed that, I didn't get those exceptions
anymore and
>> >logging seems to work nicely now with a couple quirks.
>
>Why on earth are you using the ContextJNDISelector from the sandbox when the
>real thing is available in log4j proper?
>
Because until Log4j-1.3 stabilizes (gets released), the 1.2.x selector is
my only option for a production application.
>>This is a bit weird. ContextJNDISelector in log4j-sandbox wasn't the
>>problem because it wouldn't have come into play unless I started Tomcat
>>with -Dlog4j.repositorySelectorClass=JNDI. I wonder what it was? I'll
>>have to figure this out in order to provide a Log4j-1.3 compatible config
>>utility. The one in the sandbox will only work with Log4j-1.2.x for a
>>number of reasons.
>
>Yes, the repositorySelector API was changed. More on this later.
>
You miss the point on this comment. The error happens, but not because of
a clash with the ContextJNDISelector. It has to be something else, but I'm
not sure what it is. I actually made a version of the sandbox jar that is
1.3 compatible so that I could still use my initializer code. I think the
problem happens when I attempt to set the repository selector (the 1.3
one). I'm not quite sure about this, though. I have to do more investigation.
>> >1. I have an app that has log4j-1.2.8 in it and it ends up trying to do
>> >autoconfiguration on the default logger repository. However, I don't have
>> >the config file in the webapp classpath, so it finds the one in
>> >common/classes and bombs out when it tries to use the DOMConfigurator to
>> >parse the file that only JoranConfigurator can deal with. However, since
>> >this app uses my logger initializer from log4j-sandbox and uses the
>> >sanbox's ContextJNDISelector, it successfully configures itself and logs
>> >successfully despite the config error on the default repository. I guess
>> >that's something I'll have to work out. It's probably also something
>> >people will need to remember if they use log4j logging in their webapps,
>> >but don't provide a config file in the classpath. I think it is
unexpected
>> >behavior to use a config file not meant for the app itself, but that's
>> >almost certain to happen. Or does autoconfiguration happen on non-default
>> >logger repositories? In that case, it wouldn't be an issue for Log4j-1.3
>> >since autoconfiguration would only happen once for the server as a whole,
>> >not for each JNDI-selected logger repository.
>> >
>
>
>You are raising an excellent point. If you look at
>o.a.l.selectors.ContextJNDISelector you will see that it tries to
>configure non-default repositories according to data found in
>JNDI. Note that no pure classloader-based selector can perform user
>driven configuration of non-default repositories as there would be no
>way to name the non-default repository. Hence, btw the changes to
>RepositorySelector.
>
>Having said that your comments uncovered a real bug. The
>Loader.getResource() method's search algorithm tries multiple
>classloaders to find resources. For the reasons you so justly point
>out, in case there were no config files for a given non-default
>repository, Loader.getResource() would incorrectly discover config
>files intended for the default repository
>(using for example Tomcat's common/lib classloader). I am making any sense?
>
>See
>http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/log4j/se
>lector/
>for the actual code which should make things clearer or more confusing
>depending on your coffee intake du jour.
>
>Would you like to fix this by adding and using a new method, say
>Loader.getResourceByTCLOnly() or should I?
>
I understand what you are trying to say. However, I think the premise is
false. To assume that using the thread context classloader will avoid
loading resources from, say..., Tomcat's common/classes is just
incorrect. You are right that preference will be given to the resource in
WEB-INF/classes. However, if that is not found, normal Java2 classloading
behavior resumes and a log4j.xml file in common/classes would, in fact, be
found and utilized. I can't imagine what your proposed
Loader.getResourceByTCLOnly() would accomplish and I'm not sure it is a
solvable problem. The only solution I can see is to perform initialization
on non-default repositories if, and only if, the configuration was provided
via the "log4j/configuration-resource" JNDI entry and not fall back to
loading off the classloader. In this case, applications would need to
perform manual configuration. An alternative to this is to keep the
current behavior or falling back to the classloader to find the config file
and tell users that actually want to perform manual configuration (for
whatever reason) to put a minimal config file in WEB-INF/classes to pacify
autoconfiguration and then perform the manual configuration that they so
desire.
Thoughts?
>>This is really an issue in any case where Log4j.jar (regardless of
>>version) is in WEB-INF/lib and it can't find a a config file in
>>WEB-INF/classes. It will look for it anywhere on the classpath. This was
>>a problem in the case I specified above even with Log4j-1.2.x, it's just
>>that I didn't notice errors until now because the server provided .xml
>>file is now Joran Specific and the webapp is using Log4j-1.2.x's
>>DOMConfigurator. This is a bit unfortunate since any webapp using
>>Log4j-1.2.8 while the appserver uses Log4j-1.3 will see parsing errors if
>>the webapp doesn't provide a config file in the classpath. However, in
>>reality, this is probably a minor annoyance because no config file in the
>>classpath probably means that the webapp means to do manual configuration
>>(for whatever reason) so the logger repository will, eventually, get
>>(re)configured.
>
>This is a problem we have to live with as I don't think anything
>reasonably simple can be devised to prevent it.
>
I don't understand this comment in the context of your previous
comment. Either way, see my comments above which address this.
>> >2. How do I turn off log4j internal logging? I get all this joran
parsing
>> >debug information.
>> >
>>
>>Well, I figured I'd just need to do...
>>
>><log4j:configuration debug="false">
>>
>>However, it seems that having the "debug" attribute there at all,
>>regardless of the value, triggers debugging. I verified this by removing
>>the attribute altogether and the Joran parsing logging went away. I think
>>this is a bug, although I'm not sure exactly where to fix it?
>
>No, it's supposed to be a feature. :-)
>
Well, it is a confusing feature. I don't expect debug="false" to turn on
internal debugging. This behavior seems reminiscent of boolean attributes
in HTML such as "checked" which for XHTML turns into checked="checked". Of
course that's simply a hack to keep compatibility between HTML and
XHTML. I'm not sure why we'd want to purposefully introduce an XML hack
into a Log4j config file? Is it hard using JoranConfigurator to
distinguish debug="true" and debug="false" and having the absence of the
debug attribute mean debug="false". This would be important to be as
compatible as possible with existing log4j.xml files meant for use with
the, now deprecated, DOMConfigurator, since many include the debug
attribute set to false.
>>BTW, is the "threshold" attribute still recognized in Log4j-1.3? I would
>>think it would be since with Log4j-1.2.x, you specify debug="true" and
>>then specify something like threshold="warn" to say what level of internal
>>debug logging should be output if enabled at all. I guess the
>>functionality of both these attributes should be checked.
>
>No, the threshold attribute is no longer accepted if you use joran,
>although you could teach it at run-time to honor the threshold
>attribute.
>
>The LoggerRepository threshold attribute is just a crude
>optimization. It won't be needed because newer log4j versions, those
>after 1.3, will offer better alternatives.
>
Ok
>
>>That's all for now.
>
>Really not bad for a first bug report.
>
Thanks :-)
Jake
>>Jake
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
>---------------------------------------------------------------------
>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: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 08:33 AM 11/27/2004, Jacob Kjome wrote:
>I guess I'll answer my own questions. See more below...
>
>At 01:38 PM 11/26/2004 -0600, you wrote:
> >At 09:02 PM 11/25/2004 +0100, you wrote:
> > >Jake,
> > >
> > >I've just tried log4j-1.3alpha3 with Tomcat 5.0.27 with
> > >JNDIRepositorySelector. It seems to work nicely.
> > >
> >
> >Is the ContextJNDISelector used by default?
>
>No, the DefaultRepositorySelector is the default. Only if I start up
>providing the system property -Dlog4j.repositorySelectorClass with a value
>of JNDI or the fully qualified class name of the selector will a selector
>other than the default be used. Based on the Javadoc, it also looks like
>it is possible, after the fact, to set the repository selector because the
>guard will still be null during and after autoconfig. Actually, it will
>be null until after the first call to
>LogManager.setRepositorySelctor(selector, guard), correct?
Right on.
Even if ContextJNDISelector looks fairly solid, its seemed and still
seems too big a leap to set ContextJNDISelector as the default
selector. We can reconsider for 1.4, 2.0 or whatever the next version
of log4j will be called.
Regarding the guard issue, I think if the user specifically instructs
log4j to set a repository selector, we can safely assume that's the
user's final choice, spurring us to set up a guard. The only question
is then do we make this guard visible or does it get hidden for the
remainder of the JVM's life. To keep it simple, my instincts tell me
that the guard should be set for good. (We have a mandate by
Mrs. Piggy who implictly told us to do so by setting the
-Dlog4j.repositorySelectorClass system property.)
Jake, you have a fairly good understanding of all this. Why don't you
make the necessary changes and commit them?
> > Based on the behavior I see,
> >I'm guessing it is. I figured out that the null pointer was caused by my
> >having the ContextJNDISelector from logging-log4j-sandbox in the
> >classpath. After I removed that, I didn't get those exceptions anymore and
> >logging seems to work nicely now with a couple quirks.
Why on earth are you using the ContextJNDISelector from the sandbox when the
real thing is available in log4j proper?
>This is a bit weird. ContextJNDISelector in log4j-sandbox wasn't the
>problem because it wouldn't have come into play unless I started Tomcat
>with -Dlog4j.repositorySelectorClass=JNDI. I wonder what it was? I'll
>have to figure this out in order to provide a Log4j-1.3 compatible config
>utility. The one in the sandbox will only work with Log4j-1.2.x for a
>number of reasons.
Yes, the repositorySelector API was changed. More on this later.
> >1. I have an app that has log4j-1.2.8 in it and it ends up trying to do
> >autoconfiguration on the default logger repository. However, I don't have
> >the config file in the webapp classpath, so it finds the one in
> >common/classes and bombs out when it tries to use the DOMConfigurator to
> >parse the file that only JoranConfigurator can deal with. However, since
> >this app uses my logger initializer from log4j-sandbox and uses the
> >sanbox's ContextJNDISelector, it successfully configures itself and logs
> >successfully despite the config error on the default repository. I guess
> >that's something I'll have to work out. It's probably also something
> >people will need to remember if they use log4j logging in their webapps,
> >but don't provide a config file in the classpath. I think it is unexpected
> >behavior to use a config file not meant for the app itself, but that's
> >almost certain to happen. Or does autoconfiguration happen on non-default
> >logger repositories? In that case, it wouldn't be an issue for Log4j-1.3
> >since autoconfiguration would only happen once for the server as a whole,
> >not for each JNDI-selected logger repository.
> >
You are raising an excellent point. If you look at
o.a.l.selectors.ContextJNDISelector you will see that it tries to
configure non-default repositories according to data found in
JNDI. Note that no pure classloader-based selector can perform user
driven configuration of non-default repositories as there would be no
way to name the non-default repository. Hence, btw the changes to
RepositorySelector.
Having said that your comments uncovered a real bug. The
Loader.getResource() method's search algorithm tries multiple
classloaders to find resources. For the reasons you so justly point
out, in case there were no config files for a given non-default
repository, Loader.getResource() would incorrectly discover config
files intended for the default repository
(using for example Tomcat's common/lib classloader). I am making any sense?
See
http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/log4j/selector/
for the actual code which should make things clearer or more confusing
depending on your coffee intake du jour.
Would you like to fix this by adding and using a new method, say
Loader.getResourceByTCLOnly() or should I?
>This is really an issue in any case where Log4j.jar (regardless of
>version) is in WEB-INF/lib and it can't find a a config file in
>WEB-INF/classes. It will look for it anywhere on the classpath. This was
>a problem in the case I specified above even with Log4j-1.2.x, it's just
>that I didn't notice errors until now because the server provided .xml
>file is now Joran Specific and the webapp is using Log4j-1.2.x's
>DOMConfigurator. This is a bit unfortunate since any webapp using
>Log4j-1.2.8 while the appserver uses Log4j-1.3 will see parsing errors if
>the webapp doesn't provide a config file in the classpath. However, in
>reality, this is probably a minor annoyance because no config file in the
>classpath probably means that the webapp means to do manual configuration
>(for whatever reason) so the logger repository will, eventually, get
>(re)configured.
This is a problem we have to live with as I don't think anything
reasonably simple can be devised to prevent it.
> >2. How do I turn off log4j internal logging? I get all this joran parsing
> >debug information.
> >
>
>Well, I figured I'd just need to do...
>
><log4j:configuration debug="false">
>
>However, it seems that having the "debug" attribute there at all,
>regardless of the value, triggers debugging. I verified this by removing
>the attribute altogether and the Joran parsing logging went away. I think
>this is a bug, although I'm not sure exactly where to fix it?
No, it's supposed to be a feature. :-)
>BTW, is the "threshold" attribute still recognized in Log4j-1.3? I would
>think it would be since with Log4j-1.2.x, you specify debug="true" and
>then specify something like threshold="warn" to say what level of internal
>debug logging should be output if enabled at all. I guess the
>functionality of both these attributes should be checked.
No, the threshold attribute is no longer accepted if you use joran,
although you could teach it at run-time to honor the threshold
attribute.
The LoggerRepository threshold attribute is just a crude
optimization. It won't be needed because newer log4j versions, those
after 1.3, will offer better alternatives.
>That's all for now.
Really not bad for a first bug report.
>Jake
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Jacob Kjome <ho...@visi.com>.
I guess I'll answer my own questions. See more below...
At 01:38 PM 11/26/2004 -0600, you wrote:
>At 09:02 PM 11/25/2004 +0100, you wrote:
> >Jake,
> >
> >I've just tried log4j-1.3alpha3 with Tomcat 5.0.27 with
> >JNDIRepositorySelector. It seems to work nicely.
> >
>
>Is the ContextJNDISelector used by default?
No, the DefaultRepositorySelector is the default. Only if I start up
providing the system property -Dlog4j.repositorySelectorClass with a value
of JNDI or the fully qualified class name of the selector will a selector
other than the default be used. Based on the Javadoc, it also looks like
it is possible, after the fact, to set the repository selector because the
guard will still be null during and after autoconfig. Actually, it will be
null until after the first call to
LogManager.setRepositorySelctor(selector, guard), correct?
> Based on the behavior I see,
>I'm guessing it is. I figured out that the null pointer was caused by my
>having the ContextJNDISelector from logging-log4j-sandbox in the
>classpath. After I removed that, I didn't get those exceptions anymore and
>logging seems to work nicely now with a couple quirks.
>
This is a bit weird. ContextJNDISelector in log4j-sandbox wasn't the
problem because it wouldn't have come into play unless I started Tomcat
with -Dlog4j.repositorySelectorClass=JNDI. I wonder what it was? I'll
have to figure this out in order to provide a Log4j-1.3 compatible config
utility. The one in the sandbox will only work with Log4j-1.2.x for a
number of reasons.
>1. I have an app that has log4j-1.2.8 in it and it ends up trying to do
>autoconfiguration on the default logger repository. However, I don't have
>the config file in the webapp classpath, so it finds the one in
>common/classes and bombs out when it tries to use the DOMConfigurator to
>parse the file that only JoranConfigurator can deal with. However, since
>this app uses my logger initializer from log4j-sandbox and uses the
>sanbox's ContextJNDISelector, it successfully configures itself and logs
>successfully despite the config error on the default repository. I guess
>that's something I'll have to work out. It's probably also something
>people will need to remember if they use log4j logging in their webapps,
>but don't provide a config file in the classpath. I think it is unexpected
>behavior to use a config file not meant for the app itself, but that's
>almost certain to happen. Or does autoconfiguration happen on non-default
>logger repositories? In that case, it wouldn't be an issue for Log4j-1.3
>since autoconfiguration would only happen once for the server as a whole,
>not for each JNDI-selected logger repository.
>
This is really an issue in any case where Log4j.jar (regardless of version)
is in WEB-INF/lib and it can't find a a config file in WEB-INF/classes. It
will look for it anywhere on the classpath. This was a problem in the case
I specified above even with Log4j-1.2.x, it's just that I didn't notice
errors until now because the server provided .xml file is now Joran
Specific and the webapp is using Log4j-1.2.x's DOMConfigurator. This is a
bit unfortunate since any webapp using Log4j-1.2.8 while the appserver uses
Log4j-1.3 will see parsing errors if the webapp doesn't provide a config
file in the classpath. However, in reality, this is probably a minor
annoyance because no config file in the classpath probably means that the
webapp means to do manual configuration (for whatever reason) so the logger
repository will, eventually, get (re)configured.
>2. How do I turn off log4j internal logging? I get all this joran parsing
>debug information.
>
Well, I figured I'd just need to do...
<log4j:configuration debug="false">
However, it seems that having the "debug" attribute there at all,
regardless of the value, triggers debugging. I verified this by removing
the attribute altogether and the Joran parsing logging went away. I think
this is a bug, although I'm not sure exactly where to fix it? BTW, is the
"threshold" attribute still recognized in Log4j-1.3? I would think it
would be since with Log4j-1.2.x, you specify debug="true" and then specify
something like threshold="warn" to say what level of internal debug logging
should be output if enabled at all. I guess the functionality of both
these attributes should be checked.
That's all for now.
Jake
>So, so far so good. things seem to work pretty well. I'll probably come
>back with more info later after more testing.
>
>
>Jake
>
> >At 07:46 PM 11/25/2004, you wrote:
> >>(note: I tried to send this with a zip attachment previously, but the
> >>whole email was rejected from the list. I'm sending it to Ceki
separately)
> >>
> >>
> >>Ok, I've tried out 1.3alpha2 and I'm having some problems...
> >>
> >>1. I couldn't figure out how to properly specify a rolling appender with
> >>a size based triggering policy. From the examples, it seems that I have
> >>to combine it with the sliding window rolling policy, and I thought I had
> >>it set up correctly, but it always bombed out saying that I had to set
> >>"activeFileName" param. I did that and it still failed. In fact, it
> >>caused Tomcat to fail to start. I simply moved back to using a time based
> >>rolling policy for everything and it succeeded, sort of. Tomcat was able
> >>to start, but the log shows some nasty stuff. Read on....
> >>
> >>2. The resulting log file shows some crazy stuff with lots of exceptions,
> >>seemingly with a root cause of Log4j htting null pointers. Here's a
> >>partial stack trace (notice that log4j wasn't compiled with debugging
> >>info. Might want to modify the build to add that)...
> >>
> >>Caused by: java.lang.NullPointerException
> >> at org.apache.log4j.LogManager.getLogger(Unknown Source)
> >> at org.apache.log4j.Logger.getLogger(Unknown Source)
> >> at
> >>
org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.java:229)
> >> at
> >> org.apache.commons.logging.impl.Log4JLogger.<init>(Log4JLogger.java:65)
> >> at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown
> >> Source)
> >> at
> >>
> >sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons
truc
> >torAccessorImpl.java:27)
> >> at
java.lang.reflect.Constructor.newInstance(Constructor.java:274)
> >> at
> >>
> >org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImp
l.ja
> >va:529)
> >> ... 19 more
> >>
> >>
> >>I've provided the full log, plus my xml config for log4j as well as a
> >>.properties config file that works fine with Log4j-1.2.9 just to prove
> >>that logging with log4j in general works for Tomcat. So either my config
> >>file is out of whack or log4j-1.3 is not compatible with
> >>Tomcat-5.5.x. Oh, and commons-logging-1.0.4.jar is in common/lib along
> >>with log4j-1.3.jar.
> >>
> >>Thoughts?
> >>
> >>
> >>Jake
> >
> >--
> >Ceki Gülcü
> >
> > The complete log4j manual: http://qos.ch/eclm
> > Professional log4j support: http://qos.ch/log4jSupport
> >
> >
> >
> >---------------------------------------------------------------------
> >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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Jacob Kjome <ho...@visi.com>.
At 09:02 PM 11/25/2004 +0100, you wrote:
>Jake,
>
>I've just tried log4j-1.3alpha3 with Tomcat 5.0.27 with
>JNDIRepositorySelector. It seems to work nicely.
>
Is the ContextJNDISelector used by default? Based on the behavior I see,
I'm guessing it is. I figured out that the null pointer was caused by my
having the ContextJNDISelector from logging-log4j-sandbox in the
classpath. After I removed that, I didn't get those exceptions anymore and
logging seems to work nicely now with a couple quirks.
1. I have an app that has log4j-1.2.8 in it and it ends up trying to do
autoconfiguration on the default logger repository. However, I don't have
the config file in the webapp classpath, so it finds the one in
common/classes and bombs out when it tries to use the DOMConfigurator to
parse the file that only JoranConfigurator can deal with. However, since
this app uses my logger initializer from log4j-sandbox and uses the
sanbox's ContextJNDISelector, it successfully configures itself and logs
successfully despite the config error on the default repository. I guess
that's something I'll have to work out. It's probably also something
people will need to remember if they use log4j logging in their webapps,
but don't provide a config file in the classpath. I think it is unexpected
behavior to use a config file not meant for the app itself, but that's
almost certain to happen. Or does autoconfiguration happen on non-default
logger repositories? In that case, it wouldn't be an issue for Log4j-1.3
since autoconfiguration would only happen once for the server as a whole,
not for each JNDI-selected logger repository.
2. How do I turn off log4j internal logging? I get all this joran parsing
debug information.
So, so far so good. things seem to work pretty well. I'll probably come
back with more info later after more testing.
Jake
>At 07:46 PM 11/25/2004, you wrote:
>>(note: I tried to send this with a zip attachment previously, but the
>>whole email was rejected from the list. I'm sending it to Ceki separately)
>>
>>
>>Ok, I've tried out 1.3alpha2 and I'm having some problems...
>>
>>1. I couldn't figure out how to properly specify a rolling appender with
>>a size based triggering policy. From the examples, it seems that I have
>>to combine it with the sliding window rolling policy, and I thought I had
>>it set up correctly, but it always bombed out saying that I had to set
>>"activeFileName" param. I did that and it still failed. In fact, it
>>caused Tomcat to fail to start. I simply moved back to using a time based
>>rolling policy for everything and it succeeded, sort of. Tomcat was able
>>to start, but the log shows some nasty stuff. Read on....
>>
>>2. The resulting log file shows some crazy stuff with lots of exceptions,
>>seemingly with a root cause of Log4j htting null pointers. Here's a
>>partial stack trace (notice that log4j wasn't compiled with debugging
>>info. Might want to modify the build to add that)...
>>
>>Caused by: java.lang.NullPointerException
>> at org.apache.log4j.LogManager.getLogger(Unknown Source)
>> at org.apache.log4j.Logger.getLogger(Unknown Source)
>> at
>> org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.java:229)
>> at
>> org.apache.commons.logging.impl.Log4JLogger.<init>(Log4JLogger.java:65)
>> at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown
>> Source)
>> at
>>
>sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc
>torAccessorImpl.java:27)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
>> at
>>
>org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.ja
>va:529)
>> ... 19 more
>>
>>
>>I've provided the full log, plus my xml config for log4j as well as a
>>.properties config file that works fine with Log4j-1.2.9 just to prove
>>that logging with log4j in general works for Tomcat. So either my config
>>file is out of whack or log4j-1.3 is not compatible with
>>Tomcat-5.5.x. Oh, and commons-logging-1.0.4.jar is in common/lib along
>>with log4j-1.3.jar.
>>
>>Thoughts?
>>
>>
>>Jake
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://qos.ch/eclm
> Professional log4j support: http://qos.ch/log4jSupport
>
>
>
>---------------------------------------------------------------------
>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: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
Jake,
I've just tried log4j-1.3alpha3 with Tomcat 5.0.27 with
JNDIRepositorySelector. It seems to work nicely.
At 07:46 PM 11/25/2004, you wrote:
>(note: I tried to send this with a zip attachment previously, but the
>whole email was rejected from the list. I'm sending it to Ceki separately)
>
>
>Ok, I've tried out 1.3alpha2 and I'm having some problems...
>
>1. I couldn't figure out how to properly specify a rolling appender with
>a size based triggering policy. From the examples, it seems that I have
>to combine it with the sliding window rolling policy, and I thought I had
>it set up correctly, but it always bombed out saying that I had to set
>"activeFileName" param. I did that and it still failed. In fact, it
>caused Tomcat to fail to start. I simply moved back to using a time based
>rolling policy for everything and it succeeded, sort of. Tomcat was able
>to start, but the log shows some nasty stuff. Read on....
>
>2. The resulting log file shows some crazy stuff with lots of exceptions,
>seemingly with a root cause of Log4j htting null pointers. Here's a
>partial stack trace (notice that log4j wasn't compiled with debugging
>info. Might want to modify the build to add that)...
>
>Caused by: java.lang.NullPointerException
> at org.apache.log4j.LogManager.getLogger(Unknown Source)
> at org.apache.log4j.Logger.getLogger(Unknown Source)
> at
> org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.java:229)
> at
> org.apache.commons.logging.impl.Log4JLogger.<init>(Log4JLogger.java:65)
> at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
> ... 19 more
>
>
>I've provided the full log, plus my xml config for log4j as well as a
>.properties config file that works fine with Log4j-1.2.9 just to prove
>that logging with log4j in general works for Tomcat. So either my config
>file is out of whack or log4j-1.3 is not compatible with
>Tomcat-5.5.x. Oh, and commons-logging-1.0.4.jar is in common/lib along
>with log4j-1.3.jar.
>
>Thoughts?
>
>
>Jake
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j-1.3 autoconfiguration default?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:46 PM 11/25/2004, Jacob Kjome wrote:
>(note: I tried to send this with a zip attachment previously, but the
>whole email was rejected from the list. I'm sending it to Ceki separately)
>
>
>Ok, I've tried out 1.3alpha2 and I'm having some problems...
>
>1. I couldn't figure out how to properly specify a rolling appender with
>a size based triggering policy. From the examples, it seems that I have
>to combine it with the sliding window rolling policy, and I thought I had
>it set up correctly, but it always bombed out saying that I had to set
>"activeFileName" param. I did that and it still failed. In fact, it
>caused Tomcat to fail to start. I simply moved back to using a time based
>rolling policy for everything and it succeeded, sort of. Tomcat was able
>to start, but the log shows some nasty stuff. Read on....
Some recent changes caused SizeBasedTriggerringPolicy to brake. It's an
easy fix but which slipped by. Sorry about that.
>2. The resulting log file shows some crazy stuff with lots of exceptions,
>seemingly with a root cause of Log4j htting null pointers. Here's a
>partial stack trace (notice that log4j wasn't compiled with debugging
>info. Might want to modify the build to add that)...
Definitely debug should be on. You can either wait for me to release alpha3
or build the sucker yourself.
>Caused by: java.lang.NullPointerException
> at org.apache.log4j.LogManager.getLogger(Unknown Source)
> at org.apache.log4j.Logger.getLogger(Unknown Source)
> at
> org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.java:229)
> at
> org.apache.commons.logging.impl.Log4JLogger.<init>(Log4JLogger.java:65)
> at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
> ... 19 more
The unknown source makes the trace useless doesn't it?
>I've provided the full log, plus my xml config for log4j as well as a
>.properties config file that works fine with Log4j-1.2.9 just to prove
>that logging with log4j in general works for Tomcat. So either my config
>file is out of whack or log4j-1.3 is not compatible with
>Tomcat-5.5.x. Oh, and commons-logging-1.0.4.jar is in common/lib along
>with log4j-1.3.jar.
>
>Thoughts?
I'll fix the SizeBasedWhatever and set debug=on, and then release alpha3 so
you can try it.
>Jake
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org