
|
cargo overriding commons-logging?
Hi, I've seem to come across some logging problems with cargo, or maybe it is because of maven. Anyway. The core of the problem is that errors at the level of DEBUG does not print. We have a log4j.properties file for our application that details the logging levels, and have an ConsoleAppender for its output. We use the commons-logging api in our application, and include log4j as its implementation to do the actual logging.
But cargo (or maven?) is overriding the log4j output. This is evident by seeing that FATAL and ERROR loglevels are rewritten to SEVERE. SEVERE is not a loglevel in log4j, and none of our log calls ever calls on this level. Also, we can see from the print output that it seems that cargo is wrapping its logging subsystem around the containers (tomcat). Something which is evident because our log output is prefixed with "[talledcontainer] if we do not specify the <log> or <output>.
If trying to set root loglevel in log4j to DEBUG we do not receive any debug output - only errors from INFO and up is written. We are using Tomcat 5.5 as our container, with the latest cargo snapshot. I suspect that cargo is calling setLoggingLevel or something equivalent, which is overriding log4j/commons-logging in the entire application. Could someone shed some light on how the logging subsystem in cargo works?
-- Alexander Brill http://brill.no
|

|
Re: cargo overriding commons-logging?
On Thu, 2009-01-22 at 09:46 +0100, Alexander Brill wrote:
> Hi,
>
> I've seem to come across some logging problems with cargo, or maybe it
> is because of maven.
>
> Anyway. The core of the problem is that errors at the level of DEBUG
> does not print.
>
> We have a log4j.properties file for our application that details the
> logging levels, and have an ConsoleAppender for its output. We use the
> commons-logging api in our application, and include log4j as its
> implementation to do the actual logging.
>
> But cargo (or maven?) is overriding the log4j output. This is evident
> by seeing that FATAL and ERROR loglevels are rewritten to SEVERE.
> SEVERE is not a loglevel in log4j, and none of our log calls ever
> calls on this level. Also, we can see from the print output that it
> seems that cargo is wrapping its logging subsystem around the
> containers (tomcat). Something which is evident because our log output
> is prefixed with "[talledcontainer] if we do not specify the <log> or
> <output>.
>
> If trying to set root loglevel in log4j to DEBUG we do not receive any
> debug output - only errors from INFO and up is written.
>
> We are using Tomcat 5.5 as our container, with the latest cargo
> snapshot.
What type of container are you using? standalone, installed?
> I suspect that cargo is calling setLoggingLevel or something
> equivalent, which is overriding log4j/commons-logging in the entire
> application.
Cargo will set the servers logging levels if using a standalone
configuration, but that should only be for the server. Does you
application depend on the server logging levels?
> Could someone shed some light on how the logging subsystem in cargo
> works?
>
> --
> Alexander Brill
> http://brill.no---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
|

|
Re: cargo overriding commons-logging?
On Thu, Jan 22, 2009 at 3:50 PM, Matt Wringe <mwringe@...> wrote:
On Thu, 2009-01-22 at 09:46 +0100, Alexander Brill wrote:
> Hi,
>
> I've seem to come across some logging problems with cargo, or maybe it
> is because of maven.
>
> Anyway. The core of the problem is that errors at the level of DEBUG
> does not print.
>
> We have a log4j.properties file for our application that details the
> logging levels, and have an ConsoleAppender for its output. We use the
> commons-logging api in our application, and include log4j as its
> implementation to do the actual logging.
>
> But cargo (or maven?) is overriding the log4j output. This is evident
> by seeing that FATAL and ERROR loglevels are rewritten to SEVERE.
> SEVERE is not a loglevel in log4j, and none of our log calls ever
> calls on this level. Also, we can see from the print output that it
> seems that cargo is wrapping its logging subsystem around the
> containers (tomcat). Something which is evident because our log output
> is prefixed with "[talledcontainer] if we do not specify the <log> or
> <output>.
>
> If trying to set root loglevel in log4j to DEBUG we do not receive any
> debug output - only errors from INFO and up is written.
>
> We are using Tomcat 5.5 as our container, with the latest cargo
> snapshot.
What type of container are you using? standalone, installed?
> I suspect that cargo is calling setLoggingLevel or something
> equivalent, which is overriding log4j/commons-logging in the entire
> application.
Cargo will set the servers logging levels if using a standalone
configuration, but that should only be for the server. Does you
application depend on the server logging levels?
> Could someone shed some light on how the logging subsystem in cargo
> works?
>
I'm using the installed container, so I suspected that the log4j.properties file of each webapp that gets deployed to this container/server to take effect.
-- Alexander Brill http://brill.no
|

|
Re: cargo overriding commons-logging?
On Fri, 2009-01-23 at 10:02 +0100, Alexander Brill wrote:
>
>
> On Thu, Jan 22, 2009 at 3:50 PM, Matt Wringe < mwringe@...>
> wrote:
>
> On Thu, 2009-01-22 at 09:46 +0100, Alexander Brill wrote:
> > Hi,
> >
> > I've seem to come across some logging problems with cargo,
> or maybe it
> > is because of maven.
> >
> > Anyway. The core of the problem is that errors at the level
> of DEBUG
> > does not print.
> >
> > We have a log4j.properties file for our application that
> details the
> > logging levels, and have an ConsoleAppender for its output.
> We use the
> > commons-logging api in our application, and include log4j as
> its
> > implementation to do the actual logging.
> >
> > But cargo (or maven?) is overriding the log4j output. This
> is evident
> > by seeing that FATAL and ERROR loglevels are rewritten to
> SEVERE.
> > SEVERE is not a loglevel in log4j, and none of our log calls
> ever
> > calls on this level. Also, we can see from the print output
> that it
> > seems that cargo is wrapping its logging subsystem around
> the
> > containers (tomcat). Something which is evident because our
> log output
> > is prefixed with "[talledcontainer] if we do not specify the
> <log> or
> > <output>.
> >
> > If trying to set root loglevel in log4j to DEBUG we do not
> receive any
> > debug output - only errors from INFO and up is written.
> >
> > We are using Tomcat 5.5 as our container, with the latest
> cargo
> > snapshot.
>
>
> What type of container are you using? standalone, installed?
>
> > I suspect that cargo is calling setLoggingLevel or something
> > equivalent, which is overriding log4j/commons-logging in the
> entire
> > application.
>
>
> Cargo will set the servers logging levels if using a
> standalone
> configuration, but that should only be for the server. Does
> you
> application depend on the server logging levels?
>
> > Could someone shed some light on how the logging subsystem
> in cargo
> > works?
> >
>
>
>
>
>
> I'm using the installed container, so I suspected that the
> log4j.properties file of each webapp that gets deployed to this
> container/server to take effect.
so if you start and deploy the war to the tomcat server manually,
everything works fine, but if you use cargo then the logging gets
changed?
is there any difference between the original webapp and the webapp in
the deploy directory of your server?
>
> --
> Alexander Brill
> http://brill.no---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
|

|
Re: cargo overriding commons-logging?
On Fri, Jan 23, 2009 at 3:59 PM, Matt Wringe <mwringe@...> wrote:
On Fri, 2009-01-23 at 10:02 +0100, Alexander Brill wrote:
>
>
> On Thu, Jan 22, 2009 at 3:50 PM, Matt Wringe < mwringe@...>
> wrote:
>
> On Thu, 2009-01-22 at 09:46 +0100, Alexander Brill wrote:
> > Hi,
> >
> > I've seem to come across some logging problems with cargo,
> or maybe it
> > is because of maven.
> >
> > Anyway. The core of the problem is that errors at the level
> of DEBUG
> > does not print.
> >
> > We have a log4j.properties file for our application that
> details the
> > logging levels, and have an ConsoleAppender for its output.
> We use the
> > commons-logging api in our application, and include log4j as
> its
> > implementation to do the actual logging.
> >
> > But cargo (or maven?) is overriding the log4j output. This
> is evident
> > by seeing that FATAL and ERROR loglevels are rewritten to
> SEVERE.
> > SEVERE is not a loglevel in log4j, and none of our log calls
> ever
> > calls on this level. Also, we can see from the print output
> that it
> > seems that cargo is wrapping its logging subsystem around
> the
> > containers (tomcat). Something which is evident because our
> log output
> > is prefixed with "[talledcontainer] if we do not specify the
> <log> or
> > <output>.
> >
> > If trying to set root loglevel in log4j to DEBUG we do not
> receive any
> > debug output - only errors from INFO and up is written.
> >
> > We are using Tomcat 5.5 as our container, with the latest
> cargo
> > snapshot.
>
>
> What type of container are you using? standalone, installed?
>
> > I suspect that cargo is calling setLoggingLevel or something
> > equivalent, which is overriding log4j/commons-logging in the
> entire
> > application.
>
>
> Cargo will set the servers logging levels if using a
> standalone
> configuration, but that should only be for the server. Does
> you
> application depend on the server logging levels?
>
> > Could someone shed some light on how the logging subsystem
> in cargo
> > works?
> >
>
>
>
>
>
> I'm using the installed container, so I suspected that the
> log4j.properties file of each webapp that gets deployed to this
> container/server to take effect.
so if you start and deploy the war to the tomcat server manually,
everything works fine, but if you use cargo then the logging gets
changed?
is there any difference between the original webapp and the webapp in
the deploy directory of your server?
That is correct. We use cargo for starting tomcat for our development environment. But prod, testing and staging are set up manually, and we just deploy our webapps manually to these instances. And for these instances of tomcat we are getting the correct log output.
-- Alexander Brill http://brill.no
|

|
Re: cargo overriding commons-logging?
On Fri, Jan 23, 2009 at 4:59 PM, Alexander Brill <alex@...> wrote:
On Fri, Jan 23, 2009 at 3:59 PM, Matt Wringe <mwringe@...> wrote:
On Fri, 2009-01-23 at 10:02 +0100, Alexander Brill wrote:
>
>
> On Thu, Jan 22, 2009 at 3:50 PM, Matt Wringe < mwringe@...>
> wrote:
>
> On Thu, 2009-01-22 at 09:46 +0100, Alexander Brill wrote:
> > Hi,
> >
> > I've seem to come across some logging problems with cargo,
> or maybe it
> > is because of maven.
> >
> > Anyway. The core of the problem is that errors at the level
> of DEBUG
> > does not print.
> >
> > We have a log4j.properties file for our application that
> details the
> > logging levels, and have an ConsoleAppender for its output.
> We use the
> > commons-logging api in our application, and include log4j as
> its
> > implementation to do the actual logging.
> >
> > But cargo (or maven?) is overriding the log4j output. This
> is evident
> > by seeing that FATAL and ERROR loglevels are rewritten to
> SEVERE.
> > SEVERE is not a loglevel in log4j, and none of our log calls
> ever
> > calls on this level. Also, we can see from the print output
> that it
> > seems that cargo is wrapping its logging subsystem around
> the
> > containers (tomcat). Something which is evident because our
> log output
> > is prefixed with "[talledcontainer] if we do not specify the
> <log> or
> > <output>.
> >
> > If trying to set root loglevel in log4j to DEBUG we do not
> receive any
> > debug output - only errors from INFO and up is written.
> >
> > We are using Tomcat 5.5 as our container, with the latest
> cargo
> > snapshot.
>
>
> What type of container are you using? standalone, installed?
>
> > I suspect that cargo is calling setLoggingLevel or something
> > equivalent, which is overriding log4j/commons-logging in the
> entire
> > application.
>
>
> Cargo will set the servers logging levels if using a
> standalone
> configuration, but that should only be for the server. Does
> you
> application depend on the server logging levels?
>
> > Could someone shed some light on how the logging subsystem
> in cargo
> > works?
> >
>
>
>
>
>
> I'm using the installed container, so I suspected that the
> log4j.properties file of each webapp that gets deployed to this
> container/server to take effect.
so if you start and deploy the war to the tomcat server manually,
everything works fine, but if you use cargo then the logging gets
changed?
is there any difference between the original webapp and the webapp in
the deploy directory of your server?
That is correct. We use cargo for starting tomcat for our development environment. But prod, testing and staging are set up manually, and we just deploy our webapps manually to these instances. And for these instances of tomcat we are getting the correct log output.
There are no differences in the webapps deployed.
-- Alexander Brill http://brill.no
|

|
Re: cargo overriding commons-logging?
On Fri, Jan 23, 2009 at 4:59 PM, Alexander Brill <alex@...> wrote:
On Fri, Jan 23, 2009 at 4:59 PM, Alexander Brill <alex@...> wrote:
On Fri, Jan 23, 2009 at 3:59 PM, Matt Wringe <mwringe@...> wrote:
On Fri, 2009-01-23 at 10:02 +0100, Alexander Brill wrote:
>
>
> On Thu, Jan 22, 2009 at 3:50 PM, Matt Wringe < mwringe@...>
> wrote:
>
> On Thu, 2009-01-22 at 09:46 +0100, Alexander Brill wrote:
> > Hi,
> >
> > I've seem to come across some logging problems with cargo,
> or maybe it
> > is because of maven.
> >
> > Anyway. The core of the problem is that errors at the level
> of DEBUG
> > does not print.
> >
> > We have a log4j.properties file for our application that
> details the
> > logging levels, and have an ConsoleAppender for its output.
> We use the
> > commons-logging api in our application, and include log4j as
> its
> > implementation to do the actual logging.
> >
> > But cargo (or maven?) is overriding the log4j output. This
> is evident
> > by seeing that FATAL and ERROR loglevels are rewritten to
> SEVERE.
> > SEVERE is not a loglevel in log4j, and none of our log calls
> ever
> > calls on this level. Also, we can see from the print output
> that it
> > seems that cargo is wrapping its logging subsystem around
> the
> > containers (tomcat). Something which is evident because our
> log output
> > is prefixed with "[talledcontainer] if we do not specify the
> <log> or
> > <output>.
> >
> > If trying to set root loglevel in log4j to DEBUG we do not
> receive any
> > debug output - only errors from INFO and up is written.
> >
> > We are using Tomcat 5.5 as our container, with the latest
> cargo
> > snapshot.
>
>
> What type of container are you using? standalone, installed?
>
> > I suspect that cargo is calling setLoggingLevel or something
> > equivalent, which is overriding log4j/commons-logging in the
> entire
> > application.
>
>
> Cargo will set the servers logging levels if using a
> standalone
> configuration, but that should only be for the server. Does
> you
> application depend on the server logging levels?
>
> > Could someone shed some light on how the logging subsystem
> in cargo
> > works?
> >
>
>
>
>
>
> I'm using the installed container, so I suspected that the
> log4j.properties file of each webapp that gets deployed to this
> container/server to take effect.
so if you start and deploy the war to the tomcat server manually,
everything works fine, but if you use cargo then the logging gets
changed?
is there any difference between the original webapp and the webapp in
the deploy directory of your server?
That is correct. We use cargo for starting tomcat for our development environment. But prod, testing and staging are set up manually, and we just deploy our webapps manually to these instances. And for these instances of tomcat we are getting the correct log output.
There are no differences in the webapps deployed.
I also tried to add a FileAppender, to see if log4j would log my output to a file. But to no avail. It seems the cargo logging wrapper for the container overrides a lot of stuff here. Can I disable it somehow?
-- Alexander Brill http://brill.no
|

|
Re: cargo overriding commons-logging?
On Tue, Jan 27, 2009 at 10:12 AM, Alexander Brill <alex@...> wrote:
On Fri, Jan 23, 2009 at 4:59 PM, Alexander Brill <alex@...> wrote:
On Fri, Jan 23, 2009 at 4:59 PM, Alexander Brill <alex@...> wrote:
On Fri, Jan 23, 2009 at 3:59 PM, Matt Wringe <mwringe@...> wrote:
On Fri, 2009-01-23 at 10:02 +0100, Alexander Brill wrote:
>
>
> On Thu, Jan 22, 2009 at 3:50 PM, Matt Wringe < mwringe@...>
> wrote:
>
> On Thu, 2009-01-22 at 09:46 +0100, Alexander Brill wrote:
> > Hi,
> >
> > I've seem to come across some logging problems with cargo,
> or maybe it
> > is because of maven.
> >
> > Anyway. The core of the problem is that errors at the level
> of DEBUG
> > does not print.
> >
> > We have a log4j.properties file for our application that
> details the
> > logging levels, and have an ConsoleAppender for its output.
> We use the
> > commons-logging api in our application, and include log4j as
> its
> > implementation to do the actual logging.
> >
> > But cargo (or maven?) is overriding the log4j output. This
> is evident
> > by seeing that FATAL and ERROR loglevels are rewritten to
> SEVERE.
> > SEVERE is not a loglevel in log4j, and none of our log calls
> ever
> > calls on this level. Also, we can see from the print output
> that it
> > seems that cargo is wrapping its logging subsystem around
> the
> > containers (tomcat). Something which is evident because our
> log output
> > is prefixed with "[talledcontainer] if we do not specify the
> <log> or
> > <output>.
> >
> > If trying to set root loglevel in log4j to DEBUG we do not
> receive any
> > debug output - only errors from INFO and up is written.
> >
> > We are using Tomcat 5.5 as our container, with the latest
> cargo
> > snapshot.
>
>
> What type of container are you using? standalone, installed?
>
> > I suspect that cargo is calling setLoggingLevel or something
> > equivalent, which is overriding log4j/commons-logging in the
> entire
> > application.
>
>
> Cargo will set the servers logging levels if using a
> standalone
> configuration, but that should only be for the server. Does
> you
> application depend on the server logging levels?
>
> > Could someone shed some light on how the logging subsystem
> in cargo
> > works?
> >
>
>
>
>
>
> I'm using the installed container, so I suspected that the
> log4j.properties file of each webapp that gets deployed to this
> container/server to take effect.
so if you start and deploy the war to the tomcat server manually,
everything works fine, but if you use cargo then the logging gets
changed?
is there any difference between the original webapp and the webapp in
the deploy directory of your server?
That is correct. We use cargo for starting tomcat for our development environment. But prod, testing and staging are set up manually, and we just deploy our webapps manually to these instances. And for these instances of tomcat we are getting the correct log output.
There are no differences in the webapps deployed.
I also tried to add a FileAppender, to see if log4j would log my output to a file. But to no avail. It seems the cargo logging wrapper for the container overrides a lot of stuff here. Can I disable it somehow?
Did some more fiddling around with my own codebase. And it seems that anything that goes through via java.util.logging logs to output:
import java.util.logging.Level import java.util.logging.Logger
private static final Logger logger = Logger.getLogger("funkyLogger");
... logger.log(Level.SEVERE, "some message");
... -- Alexander Brill http://brill.no
|

|
Re: cargo overriding commons-logging?
On Tue, Jan 27, 2009 at 12:45 PM, Alexander Brill <alex@...> wrote:
On Tue, Jan 27, 2009 at 10:12 AM, Alexander Brill <alex@...> wrote:
On Fri, Jan 23, 2009 at 4:59 PM, Alexander Brill <alex@...> wrote:
On Fri, Jan 23, 2009 at 4:59 PM, Alexander Brill <alex@...> wrote:
On Fri, Jan 23, 2009 at 3:59 PM, Matt Wringe <mwringe@...> wrote:
On Fri, 2009-01-23 at 10:02 +0100, Alexander Brill wrote:
>
>
> On Thu, Jan 22, 2009 at 3:50 PM, Matt Wringe < mwringe@...>
> wrote:
>
> On Thu, 2009-01-22 at 09:46 +0100, Alexander Brill wrote:
> > Hi,
> >
> > I've seem to come across some logging problems with cargo,
> or maybe it
> > is because of maven.
> >
> > Anyway. The core of the problem is that errors at the level
> of DEBUG
> > does not print.
> >
> > We have a log4j.properties file for our application that
> details the
> > logging levels, and have an ConsoleAppender for its output.
> We use the
> > commons-logging api in our application, and include log4j as
> its
> > implementation to do the actual logging.
> >
> > But cargo (or maven?) is overriding the log4j output. This
> is evident
> > by seeing that FATAL and ERROR loglevels are rewritten to
> SEVERE.
> > SEVERE is not a loglevel in log4j, and none of our log calls
> ever
> > calls on this level. Also, we can see from the print output
> that it
> > seems that cargo is wrapping its logging subsystem around
> the
> > containers (tomcat). Something which is evident because our
> log output
> > is prefixed with "[talledcontainer] if we do not specify the
> <log> or
> > <output>.
> >
> > If trying to set root loglevel in log4j to DEBUG we do not
> receive any
> > debug output - only errors from INFO and up is written.
> >
> > We are using Tomcat 5.5 as our container, with the latest
> cargo
> > snapshot.
>
>
> What type of container are you using? standalone, installed?
>
> > I suspect that cargo is calling setLoggingLevel or something
> > equivalent, which is overriding log4j/commons-logging in the
> entire
> > application.
>
>
> Cargo will set the servers logging levels if using a
> standalone
> configuration, but that should only be for the server. Does
> you
> application depend on the server logging levels?
>
> > Could someone shed some light on how the logging subsystem
> in cargo
> > works?
> >
>
>
>
>
>
> I'm using the installed container, so I suspected that the
> log4j.properties file of each webapp that gets deployed to this
> container/server to take effect.
so if you start and deploy the war to the tomcat server manually,
everything works fine, but if you use cargo then the logging gets
changed?
is there any difference between the original webapp and the webapp in
the deploy directory of your server?
That is correct. We use cargo for starting tomcat for our development environment. But prod, testing and staging are set up manually, and we just deploy our webapps manually to these instances. And for these instances of tomcat we are getting the correct log output.
There are no differences in the webapps deployed.
I also tried to add a FileAppender, to see if log4j would log my output to a file. But to no avail. It seems the cargo logging wrapper for the container overrides a lot of stuff here. Can I disable it somehow?
Did some more fiddling around with my own codebase. And it seems that anything that goes through via java.util.logging logs to output:
import java.util.logging.Level import java.util.logging.Logger
private static final Logger logger = Logger.getLogger("funkyLogger");
... logger.log(Level.SEVERE, "some message");
... -- Alexander Brill http://brill.no
|

|
Re: cargo overriding commons-logging?
On Mon, Feb 2, 2009 at 2:23 PM, Alexander Brill <alex@...> wrote:
On Tue, Jan 27, 2009 at 12:45 PM, Alexander Brill <alex@...> wrote:
On Tue, Jan 27, 2009 at 10:12 AM, Alexander Brill <alex@...> wrote:
On Fri, Jan 23, 2009 at 4:59 PM, Alexander Brill <alex@...> wrote:
On Fri, Jan 23, 2009 at 4:59 PM, Alexander Brill <alex@...> wrote:
On Fri, Jan 23, 2009 at 3:59 PM, Matt Wringe <mwringe@...> wrote:
On Fri, 2009-01-23 at 10:02 +0100, Alexander Brill wrote:
>
>
> On Thu, Jan 22, 2009 at 3:50 PM, Matt Wringe < mwringe@...>
> wrote:
>
> On Thu, 2009-01-22 at 09:46 +0100, Alexander Brill wrote:
> > Hi,
> >
> > I've seem to come across some logging problems with cargo,
> or maybe it
> > is because of maven.
> >
> > Anyway. The core of the problem is that errors at the level
> of DEBUG
> > does not print.
> >
> > We have a log4j.properties file for our application that
> details the
> > logging levels, and have an ConsoleAppender for its output.
> We use the
> > commons-logging api in our application, and include log4j as
> its
> > implementation to do the actual logging.
> >
> > But cargo (or maven?) is overriding the log4j output. This
> is evident
> > by seeing that FATAL and ERROR loglevels are rewritten to
> SEVERE.
> > SEVERE is not a loglevel in log4j, and none of our log calls
> ever
> > calls on this level. Also, we can see from the print output
> that it
> > seems that cargo is wrapping its logging subsystem around
> the
> > containers (tomcat). Something which is evident because our
> log output
> > is prefixed with "[talledcontainer] if we do not specify the
> <log> or
> > <output>.
> >
> > If trying to set root loglevel in log4j to DEBUG we do not
> receive any
> > debug output - only errors from INFO and up is written.
> >
> > We are using Tomcat 5.5 as our container, with the latest
> cargo
> > snapshot.
>
>
> What type of container are you using? standalone, installed?
>
> > I suspect that cargo is calling setLoggingLevel or something
> > equivalent, which is overriding log4j/commons-logging in the
> entire
> > application.
>
>
> Cargo will set the servers logging levels if using a
> standalone
> configuration, but that should only be for the server. Does
> you
> application depend on the server logging levels?
>
> > Could someone shed some light on how the logging subsystem
> in cargo
> > works?
> >
>
>
>
>
>
> I'm using the installed container, so I suspected that the
> log4j.properties file of each webapp that gets deployed to this
> container/server to take effect.
so if you start and deploy the war to the tomcat server manually,
everything works fine, but if you use cargo then the logging gets
changed?
is there any difference between the original webapp and the webapp in
the deploy directory of your server?
That is correct. We use cargo for starting tomcat for our development environment. But prod, testing and staging are set up manually, and we just deploy our webapps manually to these instances. And for these instances of tomcat we are getting the correct log output.
There are no differences in the webapps deployed.
I also tried to add a FileAppender, to see if log4j would log my output to a file. But to no avail. It seems the cargo logging wrapper for the container overrides a lot of stuff here. Can I disable it somehow?
Did some more fiddling around with my own codebase. And it seems that anything that goes through via java.util.logging logs to output:
import java.util.logging.Level import java.util.logging.Logger
private static final Logger logger = Logger.getLogger("funkyLogger");
... logger.log(Level.SEVERE, "some message");
...
Hi again.
I eventually found out that this wasn't a bug in cargo, but some classloader issues with tomcat. So you can close the bug I opened (I don't seem to have permissions) :)
-- Alexander Brill http://brill.no
|