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/12/01 07:08:57 UTC
Re: Log4j-1.3 autoconfiguration default?
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 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>.
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 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 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