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 Ceki Gülcü <ce...@qos.ch> on 2005/01/08 17:47:23 UTC
Log4j integration testing with Application Servers
Hello,
In the log4j project, we need to perform integration tests between
log4j and various Application Servers. Sounds familiar? :-)
Our tests check that log4j correctly solves the "logging separation
problem" [1] when ContextJNDISelector is installed. Unfortunately,
since commons-logging relies on classloader tricks, and Cactus uses
commons-logging, we can't rely on the test results.
I was thinking of replacing c-l calls with UGLI [2] but that sounds
awfully stupid. Redoing some of Cactus without CL sounds just as bad.
It looks like we are stuck.
[1] http://www.qos.ch/logging/sc.jsp
[2] http://logging.apache.org/log4j/docs/ugli.html
--
Ceki Gülcü
The complete log4j manual: http://www.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 integration testing with Application Servers
Posted by Ceki Gülcü <ce...@qos.ch>.
Vincent,
Thanks for your quick response. It is much appreciated.
At 11:38 AM 1/9/2005, Vincent Massol wrote:
>Hi Ceki,
>
>Everything is open. However, I've never seen any issue WRT classloaders.
>Maybe because I always force CL to use a specific implementation (instead of
>letting it decide automatically)? Do the classloader issues still exist when
>you configure CL to use a specific implementation (f.e.
>org.apache.commons.logging.Log =
>org.apache.commons.logging.impl.Log4JLogger).
Yes, they do. The org.apache.commons.logging.LogFactory class *always*
caches the actual LogFactory implementation it uses. The cache is
keyed by thread context class loader. In case of failure our tests
will be impossible or at least very hard to debug (due to the side
effects created by JCL).
Moreover, you Cactus 1.6 is compiled against JCL version 1.0.3 which is not
compatible with log4j 1.3.
>See
>http://jakarta.apache.org/cactus/integration/manual/howto_config.html#loggin
>g for how we currently configure Cactus logging.
>
>I wouldn't mind using UGLI but I think we would need some good reasons for
>using it. I have a few questions:
>
>1/ Our configuration sounds a bit complex to me. Could UGLI improve it?
UGLI is about reliability. It won't make configuration any easier
nor more difficult.
>2/ How do you configure UGLI? Does it use directly the configuration from
>the underlying logging system?
The jar file you drop in determines the logging API to use. If you
drop in ugli-nop.jar, then you'll get NOP loggers. If you in drop
ugli-jdk14.jar, you'll use JDK 1.4 loggers. If you drop in log4j.jar
you'll get log4j loggers. The UGLI paradigm is extremely simple.
Other than that, UGLI does not try to configure the underlying logging
API.
>There is another solution: to use a custom logging monitor as explained here
>(http://paulhammant.com/blog//000241.html) - I've done that for Cargo and it
>looks good. I'm sure it is less powerful than using CL or UGLI but it has
>the advantage of reducing the mandatory jar dependencies by one. Also we
>have very simple logging needs and no performance required, so it would be
>enough.
>
>All that said, I personally don't have the bandwidth at this point in time
>to make the move but if we feel it's a good thing and someone wants to do
>it, then I wouldnt be against it... ;-)
I am still getting the hang of Cactus. It's way too early for me to
make a proposal.
>Thanks
>-Vincent
--
Ceki Gülcü
The complete log4j manual: http://www.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 integration testing with Application Servers
Posted by Ceki Gülcü <ce...@qos.ch>.
Vincent,
Thanks for your quick response. It is much appreciated.
At 11:38 AM 1/9/2005, Vincent Massol wrote:
>Hi Ceki,
>
>Everything is open. However, I've never seen any issue WRT classloaders.
>Maybe because I always force CL to use a specific implementation (instead of
>letting it decide automatically)? Do the classloader issues still exist when
>you configure CL to use a specific implementation (f.e.
>org.apache.commons.logging.Log =
>org.apache.commons.logging.impl.Log4JLogger).
Yes, they do. The org.apache.commons.logging.LogFactory class *always*
caches the actual LogFactory implementation it uses. The cache is
keyed by thread context class loader. In case of failure our tests
will be impossible or at least very hard to debug (due to the side
effects created by JCL).
Moreover, you Cactus 1.6 is compiled against JCL version 1.0.3 which is not
compatible with log4j 1.3.
>See
>http://jakarta.apache.org/cactus/integration/manual/howto_config.html#loggin
>g for how we currently configure Cactus logging.
>
>I wouldn't mind using UGLI but I think we would need some good reasons for
>using it. I have a few questions:
>
>1/ Our configuration sounds a bit complex to me. Could UGLI improve it?
UGLI is about reliability. It won't make configuration any easier
nor more difficult.
>2/ How do you configure UGLI? Does it use directly the configuration from
>the underlying logging system?
The jar file you drop in determines the logging API to use. If you
drop in ugli-nop.jar, then you'll get NOP loggers. If you in drop
ugli-jdk14.jar, you'll use JDK 1.4 loggers. If you drop in log4j.jar
you'll get log4j loggers. The UGLI paradigm is extremely simple.
Other than that, UGLI does not try to configure the underlying logging
API.
>There is another solution: to use a custom logging monitor as explained here
>(http://paulhammant.com/blog//000241.html) - I've done that for Cargo and it
>looks good. I'm sure it is less powerful than using CL or UGLI but it has
>the advantage of reducing the mandatory jar dependencies by one. Also we
>have very simple logging needs and no performance required, so it would be
>enough.
>
>All that said, I personally don't have the bandwidth at this point in time
>to make the move but if we feel it's a good thing and someone wants to do
>it, then I wouldnt be against it... ;-)
I am still getting the hang of Cactus. It's way too early for me to
make a proposal.
>Thanks
>-Vincent
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
RE: Log4j integration testing with Application Servers
Posted by Ceki Gülcü <ce...@qos.ch>.
As I understand it, the current *implementation* in Ant of event-based
model for logging does NOT fully take advantage of one of log4j's most
important advantages, that is, its ability to process and filter messages
by logger name. This can be attributed partially to the way Log4jListener
is implemented. In this regard, CommonsLoggingListener is a better
implementation for the event-based model for logging. The
CommonsLoggingListener .messageLogged() method at least makes an effort to
use a logger name which matches as closely as possible the component
generating the log message.
I think the monitor approach applies in case:
1) logging is not an important concern,
For example if
At 02:13 PM 1/10/2005, Vincent Massol wrote:
>That's funny because I've always thought the opposite: for Cargo for
>example, we are offering a Java API that is meant to be embedded and the
>reason I have developed the monitor is specifically to avoid dragging
>another dependency (which does not provide visible business value to the
>user). What it is doing is pushing the logging definition to the user (if he
>wants to be concerned about logging). So in my opinion the monitor is really
>best when you wish your code to be embedded.
>
>Cactus is in between: it's not really embeddable although it could be
>considered like embeddable in the sense that a Cactus tests can be run in
>any existing JUnit Test Runner. However, when you use Cactus with our Ant
>tasks or the Maven plugin, it becomes an application. I believe this
>represents the main usage.
>
>Thanks
>-Vincent
--
Ceki Gülcü
The complete log4j manual: http://www.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 integration testing with Application Servers
Posted by Ceki Gülcü <ce...@qos.ch>.
Sorry, my last message went off prematurely. Here is the complete one.
As I understand it, the current *implementation* in Ant of event-based
model for logging does NOT fully take advantage of one of log4j's most
important advantages, that is, its ability to process and filter
messages by logger name. This can be attributed partially to the way
Log4jListener is implemented. In this regard, CommonsLoggingListener
is a better implementation for the event-based model for logging. The
CommonsLoggingListener .messageLogged() method at least makes an
effort to use a logger name which matches as closely as possible the
component generating the log message.
I think the monitor approach applies in case:
1) Your application model is so tight and well-defined that you can
reduce most log messages into few event types, and those that do not
fit into those event types can be deferred to a default catch-all type
without too much prejudice, e.g. Ant being the prime example.
2) logging is not an important concern,
For example, if you don't really care about the capabilities offered
by modern logging systems. Your application generates relatively few
log messages and the end-user should be able to sift through them
without too much pain.
3) Reducing the number of dependencies is important
In the long run, I think sticking to the standard approach pays off
handsomely. You don't need to define a special events and interfaces
for propagating logging messages. Most importantly, your code can
generate any log message it wants, even those that don't fit into the
model.
In the long run, I think sticking to the standard logging approach
pays off handsomely. You don't need to define special events or
interfaces for propagating logging messages. Just as importantly, your
code can generate any log message it wants, even those that don't fit
into the model. I believe the standard approach to be less intrusive
and imposing (except for the jar dependency). On the other hand, if
you see logging mostly as a nuisance, then the monitor approach helps
to keep logging constrained in a corner, which is not necessarily bad
in itself.
At 02:13 PM 1/10/2005, Vincent Massol wrote:
>That's funny because I've always thought the opposite: for Cargo for
>example, we are offering a Java API that is meant to be embedded and the
>reason I have developed the monitor is specifically to avoid dragging
>another dependency (which does not provide visible business value to the
>user). What it is doing is pushing the logging definition to the user (if he
>wants to be concerned about logging). So in my opinion the monitor is really
>best when you wish your code to be embedded.
>
>Cactus is in between: it's not really embeddable although it could be
>considered like embeddable in the sense that a Cactus tests can be run in
>any existing JUnit Test Runner. However, when you use Cactus with our Ant
>tasks or the Maven plugin, it becomes an application. I believe this
>represents the main usage.
>
>Thanks
>-Vincent
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: cactus-user-help@jakarta.apache.org
--
Ceki Gülcü
The complete log4j manual: http://www.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 integration testing with Application Servers
Posted by Ceki Gülcü <ce...@qos.ch>.
Sorry, my last message went off prematurely. Here is the complete one.
As I understand it, the current *implementation* in Ant of event-based
model for logging does NOT fully take advantage of one of log4j's most
important advantages, that is, its ability to process and filter
messages by logger name. This can be attributed partially to the way
Log4jListener is implemented. In this regard, CommonsLoggingListener
is a better implementation for the event-based model for logging. The
CommonsLoggingListener .messageLogged() method at least makes an
effort to use a logger name which matches as closely as possible the
component generating the log message.
I think the monitor approach applies in case:
1) Your application model is so tight and well-defined that you can
reduce most log messages into few event types, and those that do not
fit into those event types can be deferred to a default catch-all type
without too much prejudice, e.g. Ant being the prime example.
2) logging is not an important concern,
For example, if you don't really care about the capabilities offered
by modern logging systems. Your application generates relatively few
log messages and the end-user should be able to sift through them
without too much pain.
3) Reducing the number of dependencies is important
In the long run, I think sticking to the standard approach pays off
handsomely. You don't need to define a special events and interfaces
for propagating logging messages. Most importantly, your code can
generate any log message it wants, even those that don't fit into the
model.
In the long run, I think sticking to the standard logging approach
pays off handsomely. You don't need to define special events or
interfaces for propagating logging messages. Just as importantly, your
code can generate any log message it wants, even those that don't fit
into the model. I believe the standard approach to be less intrusive
and imposing (except for the jar dependency). On the other hand, if
you see logging mostly as a nuisance, then the monitor approach helps
to keep logging constrained in a corner, which is not necessarily bad
in itself.
At 02:13 PM 1/10/2005, Vincent Massol wrote:
>That's funny because I've always thought the opposite: for Cargo for
>example, we are offering a Java API that is meant to be embedded and the
>reason I have developed the monitor is specifically to avoid dragging
>another dependency (which does not provide visible business value to the
>user). What it is doing is pushing the logging definition to the user (if he
>wants to be concerned about logging). So in my opinion the monitor is really
>best when you wish your code to be embedded.
>
>Cactus is in between: it's not really embeddable although it could be
>considered like embeddable in the sense that a Cactus tests can be run in
>any existing JUnit Test Runner. However, when you use Cactus with our Ant
>tasks or the Maven plugin, it becomes an application. I believe this
>represents the main usage.
>
>Thanks
>-Vincent
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: cactus-user-help@jakarta.apache.org
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
RE: Log4j integration testing with Application Servers
Posted by Ceki Gülcü <ce...@qos.ch>.
As I understand it, the current *implementation* in Ant of event-based
model for logging does NOT fully take advantage of one of log4j's most
important advantages, that is, its ability to process and filter messages
by logger name. This can be attributed partially to the way Log4jListener
is implemented. In this regard, CommonsLoggingListener is a better
implementation for the event-based model for logging. The
CommonsLoggingListener .messageLogged() method at least makes an effort to
use a logger name which matches as closely as possible the component
generating the log message.
I think the monitor approach applies in case:
1) logging is not an important concern,
For example if
At 02:13 PM 1/10/2005, Vincent Massol wrote:
>That's funny because I've always thought the opposite: for Cargo for
>example, we are offering a Java API that is meant to be embedded and the
>reason I have developed the monitor is specifically to avoid dragging
>another dependency (which does not provide visible business value to the
>user). What it is doing is pushing the logging definition to the user (if he
>wants to be concerned about logging). So in my opinion the monitor is really
>best when you wish your code to be embedded.
>
>Cactus is in between: it's not really embeddable although it could be
>considered like embeddable in the sense that a Cactus tests can be run in
>any existing JUnit Test Runner. However, when you use Cactus with our Ant
>tasks or the Maven plugin, it becomes an application. I believe this
>represents the main usage.
>
>Thanks
>-Vincent
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
RE: Log4j integration testing with Application Servers
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch]
> Sent: lundi 10 janvier 2005 12:35
> To: Cactus Users List
> Cc: log4j-dev@logging.apache.org
> Subject: RE: Log4j integration testing with Application Servers
>
> At 11:38 AM 1/9/2005, Vincent Massol wrote:
>
> >There is another solution: to use a custom logging monitor as explained
> here
> >(http://paulhammant.com/blog//000241.html) - I've done that for Cargo and
> it
> >looks good. I'm sure it is less powerful than using CL or UGLI but it has
> >the advantage of reducing the mandatory jar dependencies by one. Also we
> >have very simple logging needs and no performance required, so it would
> be
> >enough.
>
> The monitor interface approach works in case the environment is
> tightly controlled. For example, Ant uses a similar approach because
> it controls its environment, in fact, it *is* the environment. In its
> environment Ant sets the rules as it sees fit.
>
> However, as in the case of Cactus, you need to be embedded into
> various environments, then the monitor approach does not work that
> well.
That's funny because I've always thought the opposite: for Cargo for
example, we are offering a Java API that is meant to be embedded and the
reason I have developed the monitor is specifically to avoid dragging
another dependency (which does not provide visible business value to the
user). What it is doing is pushing the logging definition to the user (if he
wants to be concerned about logging). So in my opinion the monitor is really
best when you wish your code to be embedded.
Cactus is in between: it's not really embeddable although it could be
considered like embeddable in the sense that a Cactus tests can be run in
any existing JUnit Test Runner. However, when you use Cactus with our Ant
tasks or the Maven plugin, it becomes an application. I believe this
represents the main usage.
Thanks
-Vincent
RE: Log4j integration testing with Application Servers
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:38 AM 1/9/2005, Vincent Massol wrote:
>There is another solution: to use a custom logging monitor as explained here
>(http://paulhammant.com/blog//000241.html) - I've done that for Cargo and it
>looks good. I'm sure it is less powerful than using CL or UGLI but it has
>the advantage of reducing the mandatory jar dependencies by one. Also we
>have very simple logging needs and no performance required, so it would be
>enough.
The monitor interface approach works in case the environment is
tightly controlled. For example, Ant uses a similar approach because
it controls its environment, in fact, it *is* the environment. In its
environment Ant sets the rules as it sees fit.
However, as in the case of Cactus, you need to be embedded into
various environments, then the monitor approach does not work that
well.
--
Ceki Gülcü
The complete log4j manual: http://www.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: My first impressions as a Cactus user, [WAS: Log4j integration testing...]
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch]
> Sent: mardi 11 janvier 2005 16:25
> To: Cactus Users List
> Subject: Re: My first impressions as a Cactus user, [WAS: Log4j
> integration testing...]
>
>
> One more comment. It seems that during normal processing, all the logs
> generated by Cactus are of level DEBUG. It would probably be quite useful
> if some of the more significant messages were of level INFO instead of
> DEBUG.
I agree. It just has to be done...
Thanks
-Vincent
>
> Just my 2c.
>
> At 02:24 PM 1/11/2005, you wrote:
> >At 11:38 AM 1/9/2005, Vincent Massol wrote:
> >>Hi Ceki,
> >>
> >>See
> >>http://jakarta.apache.org/cactus/integration/manual/howto_config.html#lo
> ggin
> >>g for how we currently configure Cactus logging.
> >
> >I found the "Servlet Sample Walk through" [1] extremely useful. On the
> >other hand, as a beginner, the "How it works" [2] was a bit overwhelming
> >and somewhat of a turn off. In my very humble opinion, you should
> consider
> >removing the link to [2] from the main cactus page. (Given the size and
> >breadth of Cactus, I am sure that there will be plenty of other occasions
> >to confuse the user later on.)
> >
> >As for configuring Cactus to use log4j, that was easy as well although I
> >had to go look in the source code to refresh my memory about how log4j
> >treated values passes with the log4j.configuration system property. I
> >don't think all users will have the same reflex. :-)
> >
> >The Cactus docs in [3] could mention that the "log4j.configuration"
> system
> >property admits a URL as a value. The resource references by the URL can
> >be a properties file as well as an XML file. Moreover, the URL can be a
> >relative, so the all of the following would work correctly assuming the
> >log4j configuration file is in $CACTUS_HOME/target/
> >
> >log4j.configuration=file:./target/log4jClient.xml
> >log4j.configuration=file:target/log4jClient.xml
> >log4j.configuration = file:./@target.dir@/log4jClient.xml
> >
> >The last line requires substitution of @targer.dir@ with the value
> "target".
> >
> >The relative paths should let you avoid normalizing paths as currently
> >done in the "test.prepare.logging" target in
> >$CACTUS_HOME/samples/servlet/build.xml.
> >
> >I have also noticed that log4j configuration in [3] does not suggest any
> >logger names which might be useful in filtering out noise. There is
> really
> >tons of it.
> >
> >You can filter out some of it with the following log4j config file.
> >
> ><?xml version="1.0" encoding="UTF-8" ?>
> ><!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
> >
> ><log4j:configuration debug="false"
> >xmlns:log4j='http://jakarta.apache.org/log4j/'>
> >
> > <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
> > <layout class="org.apache.log4j.PatternLayout">
> > <param name="ConversionPattern" value="%-5p %c - %m%n"/>
> > </layout>
> >
> > <filter class="org.apache.log4j.filter.StringMatchFilter">
> > <param name="StringToMatch" value="enter"/>
> > <param name="AcceptOnMatch" value="false"/>
> > </filter>
> >
> > </appender>
> >
> > <logger name="org.apache.log4j.joran.action"> <level
> > value="INFO"/></logger>
> > <logger name="org.apache.commons.httpclient.HttpParser"> <level
> > value="INFO"/></logger>
> > <logger name="org.apache.commons.httpclient.HttpConnection"> <level
> > value="INFO"/></logger>
> > <logger name="org.apache.cactus.internal.WebRequestImpl"> <level
> > value="INFO"/></logger>
> > <logger name="org.apache.cactus.internal.util.JUnitVersionHelper">
> > <level value="INFO"/></logger>
> >
> > <root>
> > <level value="DEBUG"/>
> > <appender-ref ref="CONSOLE" />
> > </root>
> ></log4j:configuration>
> >
> >It removes all messages containing the string "enter". It also sets the
> >level of several loggers to "INFO" which reduces the noise they generate.
> >
> >Even with the above config file the log output still contains too much
> >noise. Which are the Cactus loggers that generate the most useful
> >information, information that can help to follow the execution steps as
> >illustrated in [2] ?
> >
> >[1]
> http://jakarta.apache.org/cactus/integration/ant/howto_ant_cactus.html
> >[2] http://jakarta.apache.org/cactus/how_it_works.html
> >[3] http://jakarta.apache.org/cactus/integration/manual/howto_config.html
> >
> >--
> >Ceki Gülcü
> >
> > The complete log4j manual: http://www.qos.ch/log4j/
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: cactus-user-help@jakarta.apache.org
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org
Re: My first impressions as a Cactus user, [WAS: Log4j
integration testing...]
Posted by Ceki Gülcü <ce...@qos.ch>.
One more comment. It seems that during normal processing, all the logs
generated by Cactus are of level DEBUG. It would probably be quite useful
if some of the more significant messages were of level INFO instead of DEBUG.
Just my 2c.
At 02:24 PM 1/11/2005, you wrote:
>At 11:38 AM 1/9/2005, Vincent Massol wrote:
>>Hi Ceki,
>>
>>See
>>http://jakarta.apache.org/cactus/integration/manual/howto_config.html#loggin
>>g for how we currently configure Cactus logging.
>
>I found the "Servlet Sample Walk through" [1] extremely useful. On the
>other hand, as a beginner, the "How it works" [2] was a bit overwhelming
>and somewhat of a turn off. In my very humble opinion, you should consider
>removing the link to [2] from the main cactus page. (Given the size and
>breadth of Cactus, I am sure that there will be plenty of other occasions
>to confuse the user later on.)
>
>As for configuring Cactus to use log4j, that was easy as well although I
>had to go look in the source code to refresh my memory about how log4j
>treated values passes with the log4j.configuration system property. I
>don't think all users will have the same reflex. :-)
>
>The Cactus docs in [3] could mention that the "log4j.configuration" system
>property admits a URL as a value. The resource references by the URL can
>be a properties file as well as an XML file. Moreover, the URL can be a
>relative, so the all of the following would work correctly assuming the
>log4j configuration file is in $CACTUS_HOME/target/
>
>log4j.configuration=file:./target/log4jClient.xml
>log4j.configuration=file:target/log4jClient.xml
>log4j.configuration = file:./@target.dir@/log4jClient.xml
>
>The last line requires substitution of @targer.dir@ with the value "target".
>
>The relative paths should let you avoid normalizing paths as currently
>done in the "test.prepare.logging" target in
>$CACTUS_HOME/samples/servlet/build.xml.
>
>I have also noticed that log4j configuration in [3] does not suggest any
>logger names which might be useful in filtering out noise. There is really
>tons of it.
>
>You can filter out some of it with the following log4j config file.
>
><?xml version="1.0" encoding="UTF-8" ?>
><!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
>
><log4j:configuration debug="false"
>xmlns:log4j='http://jakarta.apache.org/log4j/'>
>
> <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
> <layout class="org.apache.log4j.PatternLayout">
> <param name="ConversionPattern" value="%-5p %c - %m%n"/>
> </layout>
>
> <filter class="org.apache.log4j.filter.StringMatchFilter">
> <param name="StringToMatch" value="enter"/>
> <param name="AcceptOnMatch" value="false"/>
> </filter>
>
> </appender>
>
> <logger name="org.apache.log4j.joran.action"> <level
> value="INFO"/></logger>
> <logger name="org.apache.commons.httpclient.HttpParser"> <level
> value="INFO"/></logger>
> <logger name="org.apache.commons.httpclient.HttpConnection"> <level
> value="INFO"/></logger>
> <logger name="org.apache.cactus.internal.WebRequestImpl"> <level
> value="INFO"/></logger>
> <logger name="org.apache.cactus.internal.util.JUnitVersionHelper">
> <level value="INFO"/></logger>
>
> <root>
> <level value="DEBUG"/>
> <appender-ref ref="CONSOLE" />
> </root>
></log4j:configuration>
>
>It removes all messages containing the string "enter". It also sets the
>level of several loggers to "INFO" which reduces the noise they generate.
>
>Even with the above config file the log output still contains too much
>noise. Which are the Cactus loggers that generate the most useful
>information, information that can help to follow the execution steps as
>illustrated in [2] ?
>
>[1] http://jakarta.apache.org/cactus/integration/ant/howto_ant_cactus.html
>[2] http://jakarta.apache.org/cactus/how_it_works.html
>[3] http://jakarta.apache.org/cactus/integration/manual/howto_config.html
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: cactus-user-help@jakarta.apache.org
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
RE: My first impressions as a Cactus user, [WAS: Log4j integration testing...]
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Ceki,
> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch]
> Sent: mardi 11 janvier 2005 14:25
> To: Cactus Users List
> Subject: My first impressions as a Cactus user, [WAS: Log4j integration
> testing...]
First, many thanks for taking the time to provide this feedback. If everyone
was doing this we would end up with much better software for sure. I really
appreciate it.
>
> At 11:38 AM 1/9/2005, Vincent Massol wrote:
> >Hi Ceki,
> >
> >See
> >http://jakarta.apache.org/cactus/integration/manual/howto_config.html#log
> gin
> >g for how we currently configure Cactus logging.
>
> I found the "Servlet Sample Walk through" [1] extremely useful. On the
> other hand, as a beginner, the "How it works" [2] was a bit overwhelming
> and somewhat of a turn off. In my very humble opinion, you should consider
> removing the link to [2] from the main cactus page. (Given the size and
> breadth of Cactus, I am sure that there will be plenty of other occasions
> to confuse the user later on.)
:-)
Good point. I have now removed the "how it works" from the main page.
>
> As for configuring Cactus to use log4j, that was easy as well although I
> had to go look in the source code to refresh my memory about how log4j
> treated values passes with the log4j.configuration system property. I
> don't
> think all users will have the same reflex. :-)
:-)
Why did you have to do this? I would like to understand so that I can
correct the doc.
>
> The Cactus docs in [3] could mention that the "log4j.configuration" system
> property admits a URL as a value. The resource references by the URL can
> be
> a properties file as well as an XML file. Moreover, the URL can be a
> relative, so the all of the following would work correctly assuming the
> log4j configuration file is in $CACTUS_HOME/target/
>
> log4j.configuration=file:./target/log4jClient.xml
> log4j.configuration=file:target/log4jClient.xml
> log4j.configuration = file:./@target.dir@/log4jClient.xml
>
> The last line requires substitution of @targer.dir@ with the value
> "target".
>
> The relative paths should let you avoid normalizing paths as currently
> done
> in the "test.prepare.logging" target in
> $CACTUS_HOME/samples/servlet/build.xml.
Ok, I didn't know about the relative file URL feature. It should simplify
our build script.
>
> I have also noticed that log4j configuration in [3] does not suggest any
> logger names which might be useful in filtering out noise. There is really
> tons of it.
>
> You can filter out some of it with the following log4j config file.
>
> <?xml version="1.0" encoding="UTF-8" ?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
>
> <log4j:configuration debug="false"
> xmlns:log4j='http://jakarta.apache.org/log4j/'>
>
> <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
> <layout class="org.apache.log4j.PatternLayout">
> <param name="ConversionPattern" value="%-5p %c - %m%n"/>
> </layout>
>
> <filter class="org.apache.log4j.filter.StringMatchFilter">
> <param name="StringToMatch" value="enter"/>
> <param name="AcceptOnMatch" value="false"/>
> </filter>
>
> </appender>
>
> <logger name="org.apache.log4j.joran.action"> <level
> value="INFO"/></logger>
> <logger name="org.apache.commons.httpclient.HttpParser"> <level
> value="INFO"/></logger>
> <logger name="org.apache.commons.httpclient.HttpConnection"> <level
> value="INFO"/></logger>
> <logger name="org.apache.cactus.internal.WebRequestImpl"> <level
> value="INFO"/></logger>
> <logger name="org.apache.cactus.internal.util.JUnitVersionHelper">
> <level value="INFO"/></logger>
>
> <root>
> <level value="DEBUG"/>
> <appender-ref ref="CONSOLE" />
> </root>
> </log4j:configuration>
>
> It removes all messages containing the string "enter". It also sets the
> level of several loggers to "INFO" which reduces the noise they generate.
For the severity, this was already there in the sample properties file:
log4j.category.org.apache.commons.httpclient = DEBUG, cactus
log4j.additivity.org.apache.commons.httpclient = false
log4j.category.httpclient = WARN, cactus
log4j.additivity.httpclient = false
Thanks for the tip for the filter though which I had never used before.
>
> Even with the above config file the log output still contains too much
> noise. Which are the Cactus loggers that generate the most useful
> information, information that can help to follow the execution steps as
> illustrated in [2] ?
I don't know from the top of my head. Would need to research this. Usually
I've found the noise not to be a problem because I always track a problem
from the place where it happens (location of stack trace in the log) to the
cause, following the methods traversed.
>
> [1] http://jakarta.apache.org/cactus/integration/ant/howto_ant_cactus.html
> [2] http://jakarta.apache.org/cactus/how_it_works.html
> [3] http://jakarta.apache.org/cactus/integration/manual/howto_config.html
>
Thanks Ceki for this very useful feedback and let me know if I can help you
in your usage of Cactus
-Vincent
My first impressions as a Cactus user, [WAS: Log4j integration
testing...]
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:38 AM 1/9/2005, Vincent Massol wrote:
>Hi Ceki,
>
>See
>http://jakarta.apache.org/cactus/integration/manual/howto_config.html#loggin
>g for how we currently configure Cactus logging.
I found the "Servlet Sample Walk through" [1] extremely useful. On the
other hand, as a beginner, the "How it works" [2] was a bit overwhelming
and somewhat of a turn off. In my very humble opinion, you should consider
removing the link to [2] from the main cactus page. (Given the size and
breadth of Cactus, I am sure that there will be plenty of other occasions
to confuse the user later on.)
As for configuring Cactus to use log4j, that was easy as well although I
had to go look in the source code to refresh my memory about how log4j
treated values passes with the log4j.configuration system property. I don't
think all users will have the same reflex. :-)
The Cactus docs in [3] could mention that the "log4j.configuration" system
property admits a URL as a value. The resource references by the URL can be
a properties file as well as an XML file. Moreover, the URL can be a
relative, so the all of the following would work correctly assuming the
log4j configuration file is in $CACTUS_HOME/target/
log4j.configuration=file:./target/log4jClient.xml
log4j.configuration=file:target/log4jClient.xml
log4j.configuration = file:./@target.dir@/log4jClient.xml
The last line requires substitution of @targer.dir@ with the value "target".
The relative paths should let you avoid normalizing paths as currently done
in the "test.prepare.logging" target in
$CACTUS_HOME/samples/servlet/build.xml.
I have also noticed that log4j configuration in [3] does not suggest any
logger names which might be useful in filtering out noise. There is really
tons of it.
You can filter out some of it with the following log4j config file.
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration debug="false"
xmlns:log4j='http://jakarta.apache.org/log4j/'>
<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-5p %c - %m%n"/>
</layout>
<filter class="org.apache.log4j.filter.StringMatchFilter">
<param name="StringToMatch" value="enter"/>
<param name="AcceptOnMatch" value="false"/>
</filter>
</appender>
<logger name="org.apache.log4j.joran.action"> <level value="INFO"/></logger>
<logger name="org.apache.commons.httpclient.HttpParser"> <level
value="INFO"/></logger>
<logger name="org.apache.commons.httpclient.HttpConnection"> <level
value="INFO"/></logger>
<logger name="org.apache.cactus.internal.WebRequestImpl"> <level
value="INFO"/></logger>
<logger name="org.apache.cactus.internal.util.JUnitVersionHelper">
<level value="INFO"/></logger>
<root>
<level value="DEBUG"/>
<appender-ref ref="CONSOLE" />
</root>
</log4j:configuration>
It removes all messages containing the string "enter". It also sets the
level of several loggers to "INFO" which reduces the noise they generate.
Even with the above config file the log output still contains too much
noise. Which are the Cactus loggers that generate the most useful
information, information that can help to follow the execution steps as
illustrated in [2] ?
[1] http://jakarta.apache.org/cactus/integration/ant/howto_ant_cactus.html
[2] http://jakarta.apache.org/cactus/how_it_works.html
[3] http://jakarta.apache.org/cactus/integration/manual/howto_config.html
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
RE: Log4j integration testing with Application Servers
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:38 AM 1/9/2005, Vincent Massol wrote:
>There is another solution: to use a custom logging monitor as explained here
>(http://paulhammant.com/blog//000241.html) - I've done that for Cargo and it
>looks good. I'm sure it is less powerful than using CL or UGLI but it has
>the advantage of reducing the mandatory jar dependencies by one. Also we
>have very simple logging needs and no performance required, so it would be
>enough.
The monitor interface approach works in case the environment is
tightly controlled. For example, Ant uses a similar approach because
it controls its environment, in fact, it *is* the environment. In its
environment Ant sets the rules as it sees fit.
However, as in the case of Cactus, you need to be embedded into
various environments, then the monitor approach does not work that
well.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
RE: Log4j integration testing with Application Servers
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Ceki,
Everything is open. However, I've never seen any issue WRT classloaders.
Maybe because I always force CL to use a specific implementation (instead of
letting it decide automatically)? Do the classloader issues still exist when
you configure CL to use a specific implementation (f.e.
org.apache.commons.logging.Log =
org.apache.commons.logging.impl.Log4JLogger).
See
http://jakarta.apache.org/cactus/integration/manual/howto_config.html#loggin
g for how we currently configure Cactus logging.
I wouldn't mind using UGLI but I think we would need some good reasons for
using it. I have a few questions:
1/ Our configuration sounds a bit complex to me. Could UGLI improve it?
2/ How do you configure UGLI? Does it use directly the configuration from
the underlying logging system?
There is another solution: to use a custom logging monitor as explained here
(http://paulhammant.com/blog//000241.html) - I've done that for Cargo and it
looks good. I'm sure it is less powerful than using CL or UGLI but it has
the advantage of reducing the mandatory jar dependencies by one. Also we
have very simple logging needs and no performance required, so it would be
enough.
All that said, I personally don't have the bandwidth at this point in time
to make the move but if we feel it's a good thing and someone wants to do
it, then I wouldnt be against it... ;-)
Thanks
-Vincent
> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch]
> Sent: samedi 8 janvier 2005 17:47
> To: cactus-user@jakarta.apache.org
> Cc: log4j-dev@logging.apache.org
> Subject: Log4j integration testing with Application Servers
>
>
> Hello,
>
> In the log4j project, we need to perform integration tests between
> log4j and various Application Servers. Sounds familiar? :-)
>
> Our tests check that log4j correctly solves the "logging separation
> problem" [1] when ContextJNDISelector is installed. Unfortunately,
> since commons-logging relies on classloader tricks, and Cactus uses
> commons-logging, we can't rely on the test results.
>
> I was thinking of replacing c-l calls with UGLI [2] but that sounds
> awfully stupid. Redoing some of Cactus without CL sounds just as bad.
> It looks like we are stuck.
>
> [1] http://www.qos.ch/logging/sc.jsp
> [2] http://logging.apache.org/log4j/docs/ugli.html
>
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org