Re: commons-logging infinite loop w/5.5.9

er on the VelocityTools subproject, and we recently came > >>>across an issue with the use of commons-logging in Tomcat 5.5.9. > >>> > >>>by default, we configure our example applications to use an adapter > >>>between commons-logging and Velocity'

Re: commons-logging infinite loop w/5.5.9

Nathan Bubna wrote: On 8/23/05, Remy Maucherat <[EMAIL PROTECTED]> wrote: Nathan Bubna wrote: hey folks, i'm a developer on the VelocityTools subproject, and we recently came across an issue with the use of commons-logging in Tomcat 5.5.9. by default, we configure our example a

Re: commons-logging infinite loop w/5.5.9

--- Nathan Bubna <[EMAIL PROTECTED]> wrote: > On 8/23/05, Remy Maucherat <[EMAIL PROTECTED]> wrote: > > Nathan Bubna wrote: > > > hey folks, > > > > > > i'm a developer on the VelocityTools subproject, > and we recently came > > >

Re: commons-logging infinite loop w/5.5.9

On 8/23/05, Remy Maucherat <[EMAIL PROTECTED]> wrote: > Nathan Bubna wrote: > > hey folks, > > > > i'm a developer on the VelocityTools subproject, and we recently came > > across an issue with the use of commons-logging in Tomcat 5.5.9. > > > > by

Re: commons-logging infinite loop w/5.5.9

Nathan Bubna wrote: hey folks, i'm a developer on the VelocityTools subproject, and we recently came across an issue with the use of commons-logging in Tomcat 5.5.9. by default, we configure our example applications to use an adapter between commons-logging and Velocity's LogSystem.

commons-logging infinite loop w/5.5.9

hey folks, i'm a developer on the VelocityTools subproject, and we recently came across an issue with the use of commons-logging in Tomcat 5.5.9. by default, we configure our example applications to use an adapter between commons-logging and Velocity's LogSystem. this way, those of

Re: mod_jk logging buffer

Hi, the problem is not only a delay but also an order of the messages. I think all messages should be flushed to the file as soon as they come. When I choosing to log 'info' messages I accept the fact that it will slow down the processing of requests. That is always a drawback of lo

Re: mod_jk logging buffer

Mladen Turk wrote: Jean-frederic Clere wrote: Radek Wierzbicki wrote: Hello, better : if (l->level < JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG || level==JK_LOG_ERROR) No? Flush should not be executed for INFO level. It slows the things down by the factor of 2. I agree for ERROR and EM

Re: mod_jk logging buffer

Jean-frederic Clere wrote: Radek Wierzbicki wrote: Hello, better : if (l->level < JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG || level==JK_LOG_ERROR) No? Flush should not be executed for INFO level. It slows the things down by the factor of 2. I agree for ERROR and EMERG. DEBUG and TRACE u

Re: mod_jk logging buffer

Radek Wierzbicki wrote: Hello, I see a problem with logging mechanism in mod_jk 1.2.14.1. The logger buffers and delays the output of messages with levels below 'info' (info, warning, error, emergency, request). With the new version, setting the log level to 'error' o

mod_jk logging buffer

Hello, I see a problem with logging mechanism in mod_jk 1.2.14.1. The logger buffers and delays the output of messages with levels below 'info' (info, warning, error, emergency, request). With the new version, setting the log level to 'error' on production setups will

DO NOT REPLY [Bug 34611] - Logging in servlet/jsp not working via java.util.logging.Logger.global

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 34611] - Logging in servlet/jsp not working via java.util.logging.Logger.global

|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 16:16 --- This is also not working in release 5.5.10 alpha release on 24 of July (afetr the last post in this bug) Logging with: <% java.util.logging.Logger.getLogger("foo").severe("printed"); %> Instead of t

Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow (logging)

Bill, so far all I've gotten out of FINE logging is a lot of these: Jul 14, 2005 1:44:36 PM org.apache.jk.common.MsgAjp processHeader FINE: Received 560 18 We have been monitoring the server, and even though I got no SEVERE messages, it appears to have hung as before. Am I excluding S

Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow (logging)

Wednesday, July 13, 2005 8:15 AM Subject: Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow (logging) Bill, Thanks again for this tip. After reading the document to my best ability, I added this line to the end of /usr/local/tomcat/common/classes/logging.propeties : org.apache.jk.common.MsgAjp =

Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow (logging)

That's for log4j. For Juli, you want FINE (or FINEST). - Original Message - From: "Collin McClendon" <[EMAIL PROTECTED]> To: "Tomcat Developers List" Sent: Wednesday, July 13, 2005 8:15 AM Subject: Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow (lo

Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow (logging)

Bill, Thanks again for this tip. After reading the document to my best ability, I added this line to the end of /usr/local/tomcat/common/classes/logging.propeties : org.apache.jk.common.MsgAjp = ALL I got as a result what seemed like no logging at all for this class. I am setting it to DEBUG

DO NOT REPLY [Bug 35640] - Description of logging in documentation not precise

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35640] New: - Description of logging in documentation not precise

gzilla/show_bug.cgi?id=35640 Summary: Description of logging in documentation not precise Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Ca

DO NOT REPLY [Bug 34611] - Logging in servlet/jsp not working via java.util.logging.Logger.global

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 34611] New: - Logging in servlet/jsp not working via java.util.logging.Logger.global

gzilla/show_bug.cgi?id=34611 Summary: Logging in servlet/jsp not working via java.util.logging.Logger.global Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: other Status: NEW Severity:

Re: Web apps vs. Logging vs. Tomcat

Remy Maucherat wrote: Here, I suppose modifying all the loggers to be like this: private Log log = LogFactory.getLog(JspServlet.class); would fix the issue without further problems. Hmm... Any chance of such a fix in the next few months. I can search out such and suggest patches, but I'm quite s

Re: Web apps vs. Logging vs. Tomcat

Remy Maucherat wrote: I also added fixes recently so that loggers are not accessed too early, which was a similar issue (some loggers would be have be improperly associated with the container classloader). There's lots of tweaking needed with logging overall, it's sort of to be expe

Re: Web apps vs. Logging vs. Tomcat

mmons-logging support, we added static loggers everywhere, since it was very easy this way. Example from the main JSP servlet class: private static Log log = LogFactory.getLog(JspServlet.class); So since Jasper is in the common classloader, the class definition will be loaded only once, and the lo

Re: Web apps vs. Logging vs. Tomcat

ces, while it should either log to the servlet context or have per instance loggers, as it resides in a classloader shared across webapps. Regardless of what happens, we will need to cleanup Jasper's logging behavior. What's unexpected here is as you say that these loggers are static --

Re: Web apps vs. Logging vs. Tomcat

either log to the servlet context or have per instance loggers, as it resides in a classloader shared across webapps. Regardless of what happens, we will need to cleanup Jasper's logging behavior. Another completely different strategy for acquiring loggers is to use the CL which loaded the

Re: Web apps vs. Logging vs. Tomcat

Jess Holle wrote: Remy Maucherat wrote: BTW, JBoss (supposedly, I didn't check personally) uses commons-logging everywhere, and the logging implementation used is log4j. That works since *everything* uses log4j. The issue is with Tomcat is really one of *not* having log4j at the Tomcat

Re: Web apps vs. Logging vs. Tomcat

Remy Maucherat wrote: BTW, JBoss (supposedly, I didn't check personally) uses commons-logging everywhere, and the logging implementation used is log4j. That works since *everything* uses log4j. The issue is with Tomcat is really one of *not* having log4j at the Tomcat level but having i

Re: Web apps vs. Logging vs. Tomcat

rything uses it. This together with a per-web-app ClassLoader (but not contextual classloader!) based LoggerRepository will ensure each web app gets its own loggers and configuration files and Tomcat core gets its own. Yes, the logging namespaces need to be separate. I was faced with the issue ver

Re: Web apps vs. Logging vs. Tomcat

Bill Barker wrote: You just need to provide the methods (if you wanted to code against Catalina, you'd just create a LifecycleListener :). This is a hook into commons-modeler, so you technically could use a plain old JavaBean. Otherwise, DynamicMBeans probably work best (or, at least give you the

Re: Web apps vs. Logging vs. Tomcat

mcat loading, then I don't see a problem with Commons Logging. Standalone Tomcat's Commons Logging behavior vis-a-vis log4j would seem to be an issue, though. The issues are especially bad and bizarre when log4j is used in a web app but Tomcat itself does not have log4j installed, but t

RE: Web apps vs. Logging vs. Tomcat

Hi, > Yoav Shapira wrote: > > UGLI is far from mature enough to be used by Tomcat at this point. When > > log4j 1.3 is out, we'll see. > > I already voted on that: -1. > > Rémy Yup, I know. I'm holding out for the possibility that UGLI will be a good enough solution and a significant enough i

Re: Web apps vs. Logging vs. Tomcat

- Original Message - From: "Jess Holle" <[EMAIL PROTECTED]> To: "Tomcat Developers List" Sent: Thursday, March 17, 2005 3:12 PM Subject: Re: Web apps vs. Logging vs. Tomcat > Bill Barker wrote: > > >- Original Message - > >From: &qu

Re: Web apps vs. Logging vs. Tomcat

#x27;t see a problem with Commons Logging. Standalone Tomcat's Commons Logging behavior vis-a-vis log4j would seem to be an issue, though. The issues are especially bad and bizarre when log4j is used in a web app but Tomcat itself does not have log4j installed, but this is only part of t

Re: Web apps vs. Logging vs. Tomcat

Bill Barker wrote: - Original Message - From: "Jess Holle" <[EMAIL PROTECTED]> To: "Tomcat Developers List" Sent: Thursday, March 17, 2005 2:25 PM Subject: Re: Web apps vs. Logging vs. Tomcat Just one more stupid question: How/where would I register/deregis

Re: Web apps vs. Logging vs. Tomcat

- Original Message - From: "Jess Holle" <[EMAIL PROTECTED]> To: "Tomcat Developers List" Sent: Thursday, March 17, 2005 2:25 PM Subject: Re: Web apps vs. Logging vs. Tomcat > Just one more stupid question: > > How/where would I register/de

Re: Web apps vs. Logging vs. Tomcat

s Holle [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 4:30 PM To: Tomcat Developers List Subject: Re: Web apps vs. Logging vs. Tomcat Thanks. That answers that part of the question quite succinctly. Now what remains is how can I work with log4j and commons logging -- commons logging'

Re: Web apps vs. Logging vs. Tomcat

omcat is really undesirable as is. Now if you're inside JBoss and it has pre-established log4j and configured it prior to Tomcat loading, then I don't see a problem with Commons Logging. Standalone Tomcat's Commons Logging behavior vis-a-vis log4j would seem to be an issue, though. The

Re: Web apps vs. Logging vs. Tomcat

Yoav Shapira wrote: UGLI is far from mature enough to be used by Tomcat at this point. When log4j 1.3 is out, we'll see. I already voted on that: -1. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail

RE: Web apps vs. Logging vs. Tomcat

Message- > From: Jess Holle [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 17, 2005 4:30 PM > To: Tomcat Developers List > Subject: Re: Web apps vs. Logging vs. Tomcat > > Thanks. That answers that part of the question quite succinctly. > > Now what remains is how c

Re: Web apps vs. Logging vs. Tomcat

Thanks. That answers that part of the question quite succinctly. Now what remains is how can I work with log4j and commons logging -- commons logging's behavior vis-a-vis the contextual classloader seems onerous if not just plain wrong. The only way I can see to "fix" this is

RE: Web apps vs. Logging vs. Tomcat

UGLI is far from mature enough to be used by Tomcat at this point. When log4j 1.3 is out, we'll see. Yoav > -Original Message- > From: Jess Holle [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 17, 2005 4:17 PM > To: Tomcat Developers List > Subject: Re: Web

Re: Web apps vs. Logging vs. Tomcat

P.S. Why does Tomcat use Commons Logging rather than UGLI? Jess Holle wrote: I had e-mailed this to users mailing list, but I have what I believe is a more "dev" follow-on question: Is there a good way to get my own start/stop action called at a per-VM level? This is assumin

Re: Web apps vs. Logging vs. Tomcat

n trying to get really serious about log4j in web apps. I note that Tomcat (thanks to commons-logging) uses java.util.logging *except* for loggers created while my web app's classloader is the current contextual classloader -- at which point it suddenly uses log4j (since my web app does) wi

DO NOT REPLY [Bug 33932] - Problem with common logging - uses wrong logger

gzilla/show_bug.cgi?id=33932 --- Additional Comments From [EMAIL PROTECTED] 2005-03-15 19:48 --- There are changes in commons-logging 1.0.5 to address this type of memory leaks in container deployment. You might want to try with that version. -- Configure bugmail: http://issues.apac

DO NOT REPLY [Bug 33932] - Problem with common logging - uses wrong logger

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33932] - Problem with common logging - uses wrong logger

field. >From my point of view, as long as common-beanutils and common-logging exist in server/lib, they are part of Tomcat web server. For the Tomcat user's point of view, bugs in the versions of these libs delivered with Tomcat are also bugs of Tomcat. I understand the tomcat developer&

DO NOT REPLY [Bug 33932] - Problem with common logging - uses wrong logger

NVALID --- Additional Comments From [EMAIL PROTECTED] 2005-03-15 14:11 --- BeanUtilsBean is not part of the Tomcat project (maybe it's commons-beanutils ?). Also, the associations in commons-logging with the webapp classloader are cleared when stopping the web application. -- Config

DO NOT REPLY [Bug 22701] - commons-logging and SSL in tomcat with struts

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33932] New: - Problem with common logging - uses wrong logger

gzilla/show_bug.cgi?id=33932 Summary: Problem with common logging - uses wrong logger Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Ca

DO NOT REPLY [Bug 22701] - commons-logging and SSL in tomcat with struts

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 22701] - commons-logging and SSL in tomcat with struts

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: Logging The Revenge

Remy Maucherat wrote: Regardless of how it is packaged, you can use log4j simply by putting it there. The system property trick is much harder with the exe. You're not using it though, so it's clearly a SEP ;) I'll provide a default configuration in "build", so that CVS users can try it. Ok, t

Re: Logging The Revenge

Bill Barker wrote: As a log4j user I'd prefer a separate jar for Juli (so that I can remove her easily :). I'm pretty agnostic as to including it in the default tomcat-5.5.x.tar.gz or as tomcat-logging.tar.gz. In the second case, it should be enough to have tomcat-juli.jar. It's easy enough to h

Re: Logging The Revenge

- Original Message - From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" Sent: Wednesday, March 02, 2005 6:10 PM Subject: Logging The Revenge >Hi, > >As I will rewrite the documentation for java.util.logging, I'd like to >

Logging The Revenge

, the only requirement is that their classes must be visible to the classloader which contains the logging configuration where they are used), and needs a system property to be used when starting the JVM (using -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager). The defaults provid

Re: Logging

tarted, all the container logging should go to container.getLogger(), as it used to in Tomcat 4.x. That was my idea. Another option is to use something like: log = LogFactory.getLog(container.logName()+".RealmBase"); The output will usually go to the container log, but it allows you to only

Re: Logging (was: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java JAASCallbackHandler.java JAASMemoryLoginModule.java JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java)

- Original Message - From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" Sent: Saturday, February 19, 2005 2:55 AM Subject: Logging (was: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/r

Logging (was: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java JAASCallbackHandler.java JAASMemoryLoginModule.java JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java)

redentials) uses Container.getLogger(), whereas the other RealmBase.authenticate() methods use LogFactory.getLog(). Shouldn't this be consistent? This is where my confusion has stemmed from. Well, yes, it's a problem. It's simple: as soon as the container is started, all the conta

RE: JK throws java.lang.NumberFormatException when JSP is not found. (tomcat debug logging)

Hi, No problem. Here is the debug logging from Tomcat. DEBUG TP-Processor3 org.apache.jk.common.ChannelSocket - read() [EMAIL PROTECTED] 8192 0 4 = 4 DEBUG TP-Processor3 org.apache.jk.common.MsgAjp - Received 723 18 DEBUG TP-Processor3 org.apache.jk.common.ChannelSocket - read() [EMAIL

Re: JK throws java.lang.NumberFormatException when JSP is not found. (trace logging)

- Original Message - From: "Allistair Crossley" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Thursday, December 16, 2004 8:18 AM Subject: RE: JK throws java.lang.NumberFormatException when JSP is not found. (trace logging)

JK2 logging with IIS

The documentation for setting up a logger for JK2 is below. I've tried using logger.file and logger.win32 for my IIS configuration, but no luck. Can someone please send the right configuration steps to configure JK2 logging with IIS? I'm trying to locate a "bug" in JK

RE: JK throws java.lang.NumberFormatException when JSP is not found. (trace logging)

67): exit > -Original Message- > From: Bill Barker [mailto:[EMAIL PROTECTED] > Sent: 16 December 2004 15:38 > To: Tomcat Developers List > Subject: Re: JK throws java.lang.NumberFormatException when JSP is not > found. (trace logging) > > > > - Origina

Re: JK throws java.lang.NumberFormatException when JSP is not found. (trace logging)

- Original Message - From: "Allistair Crossley" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Thursday, December 16, 2004 6:22 AM Subject: RE: JK throws java.lang.NumberFormatException when JSP is not found. (trace loggi

RE: JK throws java.lang.NumberFormatException when JSP is not found. (trace logging)

Hi Guys, Well I have trace logging on but there do not appear to be errors in the logs. You can clearly see from the timestamps on the logging below that the errors are linked to each other. As soon as I request a JSP that does not exist, e.g I request http://testserver/nosuchjsp.jsp I get

DO NOT REPLY [Bug 32532] - tomcat logging page fails to mention need of commons-logging.jar in common/lib

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32532] - tomcat logging page fails to mention need of commons-logging.jar in common/lib

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32532] - tomcat logging page fails to mention need of commons-logging.jar in common/lib

gzilla/show_bug.cgi?id=32532 --- Additional Comments From [EMAIL PROTECTED] 2004-12-04 22:02 --- Actually, and this is more accurate, what you would need in the commons-logging wrapper for the logging implementation you're using (commons-logging.jar has the log4j wrapper). As for the st

DO NOT REPLY [Bug 32532] - tomcat logging page fails to mention need of commons-logging.jar in common/lib

gzilla/show_bug.cgi?id=32532 --- Additional Comments From [EMAIL PROTECTED] 2004-12-04 21:36 --- Created an attachment (id=13647) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13647&action=view) adds note to acquire commons-logging, modifies some other parts lightly to pr

DO NOT REPLY [Bug 32532] New: - tomcat logging page fails to mention need of commons-logging.jar in common/lib

gzilla/show_bug.cgi?id=32532 Summary: tomcat logging page fails to mention need of commons- logging.jar in common/lib Product: Tomcat 5 Version: 5.5.4 Platform: PC OS/Version: Windows XP Status: NEW Severity:

DO NOT REPLY [Bug 32471] - Tomcat's commons-logging conflicts with webapp that also has its own org.apache.commons.logging.Log

gzilla/show_bug.cgi?id=32471 --- Additional Comments From [EMAIL PROTECTED] 2004-12-01 17:23 --- Counterpoint: I can run our web-app in 5.5.4 (with Java 1.5) just fine -- and it contains commons-logging. Now I did change our web app such that we're using the same commons-logging versio

DO NOT REPLY [Bug 32471] - Tomcat's commons-logging conflicts with webapp that also has its own org.apache.commons.logging.Log

gzilla/show_bug.cgi?id=32471 --- Additional Comments From [EMAIL PROTECTED] 2004-12-01 17:04 --- 1) try removing your web application's lib/commons-logging-1.0.3.jar, restart and test 2 if (1) fails copy tomcat/bin/commons-logging-api.jar into your web application's lib,

DO NOT REPLY [Bug 32471] - Tomcat's commons-logging conflicts with webapp that also has its own org.apache.commons.logging.Log

NVALID --- Additional Comments From [EMAIL PROTECTED] 2004-12-01 17:00 --- The commons-logging JAR which is bundled in on the system classpath, and will be delegated to first, so what you describe cannot occur. Please provide a test war if you'd like to reopen this report. I don'

DO NOT REPLY [Bug 32471] - Tomcat's commons-logging conflicts with webapp that also has its own org.apache.commons.logging.Log

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32471] - Tomcat's commons-logging conflicts with webapp that also has its own org.apache.commons.logging.Log

o in a web app lib folder. this issue is also slightly but not exactly related to another issue where if a webapp has any other version of commons-logging than that in tomcat's BIN folder a NoClassDefFoundError is thrown. that is, if you use commons-logging- api.jar from tomcat's BIN in

DO NOT REPLY [Bug 32471] - Tomcat's commons-logging conflicts with webapp that also has its own org.apache.commons.logging.Log

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32471] - Tomcat's commons-logging conflicts with webapp that also has its own org.apache.commons.logging.Log

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32471] New: - Tomcat's commons-logging conflicts with webapp that also has its own org.apache.commons.logging.Log

gzilla/show_bug.cgi?id=32471 Summary: Tomcat's commons-logging conflicts with webapp that also has its own org.apache.commons.logging.Log Product: Tomcat 5 Version: 5.5.4 Platform: PC OS/Version: Linux

DO NOT REPLY [Bug 32312] - mod_jk enhancement logging PID/TID in JkLogFile

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32249] - Log4j section enhancement for Tomcat Logging page

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32312] New: - mod_jk enhancement logging PID/TID in JkLogFile

gzilla/show_bug.cgi?id=32312 Summary: mod_jk enhancement logging PID/TID in JkLogFile Product: Tomcat 5 Version: 5.0.30 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Nat

DO NOT REPLY [Bug 32249] - Log4j section enhancement for Tomcat Logging page

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32249] - Log4j section enhancement for Tomcat Logging page

solete|| --- Additional Comments From [EMAIL PROTECTED] 2004-11-18 17:35 --- Created an attachment (id=13491) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13491&action=view) fuller documentation patch for tomcat 5.5 logging page including introduction and jdk logging, revised log4j to

DO NOT REPLY [Bug 32249] - Log4j section enhancement for Tomcat Logging page

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32249] - Log4j section enhancement for Tomcat Logging page

gzilla/show_bug.cgi?id=32249 --- Additional Comments From [EMAIL PROTECTED] 2004-11-15 17:16 --- Created an attachment (id=13467) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13467&action=view) documentation patch for logging page -- Configure bugmail: http://issu

DO NOT REPLY [Bug 32249] New: - Log4j section enhancement for Tomcat Logging page

gzilla/show_bug.cgi?id=32249 Summary: Log4j section enhancement for Tomcat Logging page Product: Tomcat 5 Version: 5.5.4 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Com

{TOML#001-402-286}Enhancement: mod_jk-Logging

Dear Customer, Thank you for your interest in the services offered by TimesofMoney.com.We have received your email. Our Customer Relations Officer will get in touch with you shortly. In case you would like to speak to our representatives, you can reach us at these numbers : 2207 2072 (B

{TOML#001-402-139}Enhancement: mod_jk-Logging

Dear Customer, Thank you for your interest in the services offered by TimesofMoney.com.We have received your email. Our Customer Relations Officer will get in touch with you shortly. In case you would like to speak to our representatives, you can reach us at these numbers : 2207 2072 (B

Re: Enhancement: mod_jk-Logging

Rainer. You are definitely on my track :). I'm planning to add one additional log level, and clear all the log messages. 1. ERROR - fatal operations 2. WARN - problems but not fatal 3. INFO - production logging 4. DEBUG - protocol tracing 5. TRACE - function call logging 1) Include the log level

Enhancement: mod_jk-Logging

of a message in the log line. That should be easy and is very helpful to find relevant messages. It is pretty standard and much more safe than relying on the fact, that most error messages actually contain the word error in the message text. 2) Include the PID of the logging process in the log

DO NOT REPLY [Bug 20639] - many logging info in catalina.out

gzilla/show_bug.cgi?id=20639 many logging info in catalina.out --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 19:59 --- Just add the following lines in worker2.properties. I had to add it as the first section of the file for it to take effect. [logger] level

DO NOT REPLY [Bug 31398] - StandardWrapperValve logging

gzilla/show_bug.cgi?id=31398 StandardWrapperValve logging [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Reso

DO NOT REPLY [Bug 31398] New: - StandardWrapperValve logging

gzilla/show_bug.cgi?id=31398 StandardWrapperValve logging Summary: StandardWrapperValve logging Product: Tomcat 4 Version: 4.1.27 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Com

Re: Enhancement: mod_jk-Logging

is a pretty standard feature. 2) Include the PID of the logging process in the log file. That helps a lot, because one can also log the PID in Apaches access log. So it is easier to relate access log lines and mod_jk log lines to each other. Also it helps to unmangle, if log lines from several

Enhancement: mod_jk-Logging

feature. 2) Include the PID of the logging process in the log file. That helps a lot, because one can also log the PID in Apaches access log. So it is easier to relate access log lines and mod_jk log lines to each other. Also it helps to unmangle, if log lines from several parallel requests are

RE: Enhancement: mod_jk-Logging

Please remove [EMAIL PROTECTED] from your discussion list. Thank you. -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 12:25 PM To: Tomcat Developers List Subject: Enhancement: mod_jk-Logging I have a proposal for a slight enhancement

Enhancement: mod_jk-Logging

I have a proposal for a slight enhancement concerning the log format of mod_jk. 1) Include the log level of a message in the log line. That should be easy and is very helpful to find relevant messages. It is pretty standard. 2) Include the PID of the logging process in the log file. That helps

DO NOT REPLY [Bug 28961] - provide new Log4J/java2-logging-api proxy loggers class

gzilla/show_bug.cgi?id=28961 provide new Log4J/java2-logging-api proxy loggers class [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RE

DO NOT REPLY [Bug 28961] - provide new Log4J/java2-logging-api proxy loggers class

gzilla/show_bug.cgi?id=28961 provide new Log4J/java2-logging-api proxy loggers class [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|RE

DO NOT REPLY [Bug 28961] - provide new Log4J/java2-logging-api proxy loggers class

gzilla/show_bug.cgi?id=28961 provide new Log4J/java2-logging-api proxy loggers class --- Additional Comments From [EMAIL PROTECTED] 2004-05-26 19:27 --- >From what I observed, it only changes filename every day, but doesn't deleted older ones. If so, what is the rolling policy? -s

  1   2   3   4   >