Tomcat 4.1.24 and log4j -1.2.8.jar
Hi All, I am migrating my current application to use Struts 1.1 and I am facing a problem. My current app. has logging implemented with log4J 1.2.8. I am facing a bizzare problem when using Log4J 1.2.8 with Tomcat 4.1.24 (or Tomcat 4.1.27) on Windows 2000 with JDK 1.4.1_02 When I put my log4j -1.2.8 in the jak*/common/lib directory, Tomcat refuses to start The exception throw is as follows: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging .LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@1a679 b7 for org.apache.commons.logging.impl.Log4JLogger at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactory Impl.java:532) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactory Impl.java:272) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414) at org.apache.commons.digester.Digester.(Digester.java:346) at org.apache.catalina.startup.Catalina.createStartDigester(Catalina.jav a:280) at org.apache.catalina.startup.Catalina.start(Catalina.java:441) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) Caused by: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@1a679b7 for org.apache.commons.logging.impl.Log4 JLogger at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogF actoryImpl.java:432) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactory Impl.java:525) ... 12 more Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:1590) at java.lang.Class.getConstructor0(Class.java:1762) at java.lang.Class.getConstructor(Class.java:1002) at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogF actoryImpl.java:429) ... 13 more If I put my log4J in the jakarta../shared/lib or WEB-INF/lib, Tomcat does startup. However, Struts fails to initialize giving an exception as follows: javax.servlet.ServletException: Error instantiating servlet class org.apache.struts.action.ActionServlet at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:91 2) ... - Root Cause - java.lang.ExceptionInInitializerError Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@3a5794 for org.apache.commons.logging.impl.Log4JLogger at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.ja va:532) Caused by: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@3a5794 for org.apache.commons.logging.impl.Log4JLogger at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryI mpl.java:432) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.ja va:525) ... 28 more Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:1590) at java.lang.Class.getConstructor0(Class.java:1762) at java.lang.Class.getConstructor(Class.java:1002) at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryI mpl.java:429) ... 29 more What am I missing? Thanks! Mahesh
Re: Plans for supporting a build in level of "trace"
IMHO, the simplicity of Debug/info/warn/error/fatal is one of Log4j's strengths. I personally would not want Trace However, if I required Trace-style logging, I would simply log to a dotted logger name "---.trace". E.g If I have a component "com.mycompany.mycomponent", I have a complimentary "com.mycomany.mycomponent.trace" logger, and configure Log4j to suppress this logger under normal circumstances. The other advantage to this approach is that you can get all Trace style logs into their own appender very easily (attach the appropriate appender to each .trace logger in the config), which means my trace logs are separated easily from the other debug, which I think is what a lot of people are worried about. I can't see anyone wanting to wade through Trace AND Debug log messages to find things out, but maybe I can't see the use case that other people have. Having said all this, as a Log4j developer I wonder since we've previously made a lot of effort to match JDK 1.4's syntax (e.g. Category->Logger, Priority->Level), one might argue that it's not too much effort to go that extra mile to just add the Trace level for those that way inclined. Perhaps those log4j dev-people who were involved in the Log4j-JDK1.4 matching development might be able to comment on any rationale etc. But for me, I'm very happy with the current Trace-less log4j. Paul Smith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plans for supporting a build in level of "trace"
Bill, I believe there is a plan in place to do this with some kind of "logging context" in a future release. I'm not part of the dev list, so I don't know that for a fact, but it is my understanding from various responses to some problems that I had early on with these issues. My biggest issue is that I don't agree with the forced relationship between Levels, especially when you add additional Levels to the standard package. Why is "trace" higher or lower than "debug" or "info"? I don't agree that this is a fixed relationship, it depends on the circumstances. Then you add additional Levels (DB Access, Timing, etc) and it gets even muddier. I think you are right, there is a dual notion of what a Level is. It is used for both turning on/off logging (with an implied relationship between the various Levels) and also to define the type of info being logged. For my purposes, I've created something like what you describe by wrapping the Logger class to remove the entire concept of Levels and replaced it with a LogType concept. Now, I can turn on/off logging for any particular LogType totally independent of any other LogType, because there is no inherent relationship between them. The nice part is that if I choose to have a relationship between them I can, but the Logging class doesn't make that assumption, that's up to the LogType to decide if it is "enabled". So in my config file I select what Type of info I want logged, not the Level (and its related Levels). Unfortunately, I didn't have the time to rewrite the Logger class to replace Levels (Levels and their implied relationships are embedded pretty deep in log4j), so I used a "poor-man's" context by prefixing each logger's "class name" with a "log type" name, which gives me roughly the same outcome (i.e. turning logging on/off by type instead of by group which is how levels work), albeit a bit ugly in the config file. Happily, the Java code is unaware because the wrapper does all the translation work. Probably the biggest problem I can see with this approach is that it's not exactly compatible with Java 1.4 Logging, which in my case doesn't bother me because I don't think logging belongs in the language anyhow! :) --- regards --- Larry At 04:52 PM 9/23/03, you wrote: It seems obvious enough why there is wide disagreement on how to use the existing levels and/or whether more levels are needed. People are trying to cram selectively enabled logging into log4j's strict hierarchical logging scheme. What I think mos people want is some reasonable way of saying how much logging they want (and the current scheme is fine for that) along with saying what kind of information they want logged (the current scheme is lousy for that). What folks probably want for the latter is the ability to turn on and off some selection of "items of interest". I'm sure many people independently do this outside of log4j. I don't know if it would be easy / reasonable / worthwhile to have some facility inside log4j that implemented the same idea. You might be able to cook up some "items of interest" that were interesting to many development efforts, but there would certainly be unique elements that folks would want to use to supplement that. -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Larry Young The Dalmatian Group www.dalmatian.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plans for supporting a build in level of "trace"
It seems obvious enough why there is wide disagreement on how to use the existing levels and/or whether more levels are needed. People are trying to cram selectively enabled logging into log4j's strict hierarchical logging scheme. What I think mos people want is some reasonable way of saying how much logging they want (and the current scheme is fine for that) along with saying what kind of information they want logged (the current scheme is lousy for that). What folks probably want for the latter is the ability to turn on and off some selection of "items of interest". I'm sure many people independently do this outside of log4j. I don't know if it would be easy / reasonable / worthwhile to have some facility inside log4j that implemented the same idea. You might be able to cook up some "items of interest" that were interesting to many development efforts, but there would certainly be unique elements that folks would want to use to supplement that. -- [EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119 38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
turn off loggin from java cmd line
hi - i can't figure out how to turn off log4j logging from the java cmd line. i have used -Dlog4j.level=OFF i have even created a new configuration file with rootLogger=OFF, A1 instead i get a message like this... - Log4J [user default] requested, not adjusting logging priority any help would be appreciated. i know the horrible over-logging (which is crashing my system) is coming from one of jar dependencies but i can't track down which - maybe you have a suggestion for how to track down the source of the logging init as well - greps to no avail. thanks cheers, stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sample log4j.xml file
http://jakarta.apache.org/log4j/";> > > > > > Can anyone provide a sample xml configuration file? I tried looking for > it on the log4j website - but the link from thr javadocs is broken. > > Thanks > Shuchi -- Scott Morgan President Adligo Inc. Ph: 773-758-8735 Fax: 773-632-0568 http://www.adligo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sample log4j.xml file
Can anyone provide a sample xml configuration file? I tried looking for it on the log4j website - but the link from thr javadocs is broken. Thanks Shuchi
RE: an HttpServletRequestAppender?
Have you thought about using Logger.l7dlog(), sharing the key with the ActionMessage,
and wrapping both in the appropriate log level check? This will enable the Log4j
config to control both the log and user messages. E.g.
if (LOG.isInfoEnabled())
{
String msgKey = "the.key";
Object[] valuesArray = {"val1", "val2"};
ActionMessage msg = new ActionMessage(msgKey, valuesArray);
LOG.l7dlog(Level.INFO, msgKey, valuesArray, throwab);
actionMessages.add(ActionMessages.GLOBAL_MESSAGE, msg);
}
Will that work for you? A little extra code is a negative moving forward, and
revamping your existing classes is the big negative!
I do not think you can have an appender to a transient object (i.e. in the Struts
Action), nor is there a list of Log4j messages to retrieve (need to receive the
callAppenders() event). But, perhaps one of the gurus will explain further...
> -Original Message-
> From: Brian Buckley [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 23, 2003 10:57 AM
> To: Log4J Users List
> Subject: Re: an HttpServletRequestAppender?
>
>
> Thanks. I am familiar with , ActionMessage,
> etc. and using
> those may be my solution in the end, but I have some business
> classes which
> already emit some appropriate log messages using log4j and I
> was hoping to
> be able to display those messages.
>
> Also, log4j allows one good control of turning on and off levels and
> categories of messages by configuration file and I wanted to
> take advantage
> of that. I don't believe the Strut's ActionMessages
> technique has that
> flexibility.
>
> Brian
>
>
>
>
> For "any tips" - Are you familiar with the Struts ActionMessages,
> ActionMessage, ActionErrors, and ActionError classes and the Struts
> tag?
>
> You may want to consider using them instead of pushing log
> messages to the
> user.
>
> Lemme know if you are not familiar and would like further info.
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plans for supporting a build in level of "trace"
I've just got to chime in here-- I've used Log4J for quite some time now and the one thing that has bothered me about it is its wonderful granularity during normal operations-- FATAL, ERROR, WARN, INFO; each provide for information of a particular nature, that nature is fairly obvious, and lesser important messages can be suppressed if you just don't care about it. Unfortunately, only one exists when trying to troubleshoot problems- DEBUG. There have been many times that I've longed for one more level (e.g. TRACE or similar) that would allow for finer grained logging. The lack of this has caused me, on more than one occasion, to start using INFO for debugging information just because the quantity of information output during DEBUG would have a tendency to hide the jewels I'm looking. In one case, the difference would be between checking out a 250k log file vs 100M log file. There are times that the extra verbosity is needed, but not always. If it's not obvious, I'm very much for a TRACE level. rob hedin nds systems, lc - Original Message - From: "Jensen, Jeff" <[EMAIL PROTECTED]> To: "Log4J Users List" <[EMAIL PROTECTED]> Sent: Monday, September 22, 2003 7:22 PM Subject: RE: Plans for supporting a build in level of "trace" > -Original Message- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: Monday, September 22, 2003 10:59 AM > To: Log4J Users List > Subject: RE: Plans for supporting a build in level of "trace" > > > > Howdy, > > >To separate concerns. Because trace info is a specific level, more > minutia > >than debug info. > > That's your use-case, not mine. Both are debug for me. I never want > one without the other. theValue=... is useless if I don't know what > method it's in. Yes, both are debug info for me too. I want to turn off trace info when not needed to increase the clarity and value of the logs. Your statement: "theValue=... is useless if I don't know what method it's in" is irrelevant to the trace level argument. The issue exists for any logged message at any level. (The only solutions I know are to either define it in the ConversionPattern, prefix each message logged, or use NDC [which seems a little wrong to me] - how do you solve it?). So you (and others) are happy to overload the debug level. Others, including me, are not! That is too much info on one level. "That's your use case, not mine"! :-) > >3) People want it, it does not break backwards compatibility, and it > adds > >one more level of logging clarity. > > Convince me that a majority wants it. How come it doesn't > come up more > often on the log4j user list? Perhaps others are silent on it like me, who has used Log4J for a couple of years and has always missed it. In my current project, DEBUG messages containing trace info are sometimes deleted/commented out after awhile, when things are working well in that product section, possibly re-enabled when needed. This process goes against the crux of Log4j, even its "marketing": disable the level when not desired, don't delete/comment out code. OK FOLKS! Please email the list if you want it. Yoav said "Convince me that a majority wants it"! > As Paul said, this is an eternal debate, kind of like whether > to include > version numbers of a release in the jar file name. I half agree. I agree because usage of the logging levels is subject to interpretation. What each level means to one does not necessarily mean the same to another. However, I do see some consistency applied at my various clients. I disagree because tracing is a finer grained and different message type than debug. Hence my interpretation! Hence its difference name and different concept than a general debug message. I and others see it as a missing level to Log4j. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: an HttpServletRequestAppender?
Thanks. I am familiar with , ActionMessage, etc. and using those may be my solution in the end, but I have some business classes which already emit some appropriate log messages using log4j and I was hoping to be able to display those messages. Also, log4j allows one good control of turning on and off levels and categories of messages by configuration file and I wanted to take advantage of that. I don't believe the Strut's ActionMessages technique has that flexibility. Brian For "any tips" - Are you familiar with the Struts ActionMessages, ActionMessage, ActionErrors, and ActionError classes and the Struts tag? You may want to consider using them instead of pushing log messages to the user. Lemme know if you are not familiar and would like further info. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: an HttpServletRequestAppender?
For "any tips" - Are you familiar with the Struts ActionMessages, ActionMessage, ActionErrors, and ActionError classes and the Struts tag? You may want to consider using them instead of pushing log messages to the user. Lemme know if you are not familiar and would like further info. > -Original Message- > From: Brian Buckley [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 23, 2003 10:07 AM > To: [EMAIL PROTECTED] > Subject: an HttpServletRequestAppender? > > > Is it possible to configure log4j to stuff log messages into > an attribute of > an HttpServletRequest [in addition to file, console or whatever other > logging might be configured for a webapp]? > > For example, I'd like the new logs generated while in Strut's > Action.execute > method (which is run prior to forwarding to a JSP) to be > available to a JSP > writer to display to that user right in the JSP page. > > Thanks - any tips appreciated. -Brian > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
an HttpServletRequestAppender?
Is it possible to configure log4j to stuff log messages into an attribute of an HttpServletRequest [in addition to file, console or whatever other logging might be configured for a webapp]? For example, I'd like the new logs generated while in Strut's Action.execute method (which is run prior to forwarding to a JSP) to be available to a JSP writer to display to that user right in the JSP page. Thanks - any tips appreciated. -Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
output encoding
I'm trying to move a J2EE app which uses log4j to WebSphere 5 on zOS, so I
have encoding issues. This app uses XML for the log4j config. How do I
change the output encoding in the XML, or do I need to do a
setEncoding("Cp1047") (on WriterAppender, etc.) somewhere in the code?
Thanks,
Aaron
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuring a wrapper class for rolling policies
Composite components such as org.apache.log4j.rolling.RollingFileAppender must be configured using DOMConfigurator or JoranConfigurator. Note that DOMConfigurator is deprecated in 1.3 and will be replaced with JoranConfigurator. However, JoranConfigurator is not yet ready. (Of course 1.3 is not either.) At 03:23 PM 9/23/2003 +0200, you wrote: Hi all! I.m using a wrapper class (i.e org.apache.log4j.rolling.MyTimeBasedRollingPolicy) to performance an specific rollingPolicy for my purpose. Is there any way to configure it in log4j properties file? i tried something like : log4j.rootLogger=DEBUG, A1 log4j.appender.A1=org.apache.log4j.rolling.RollingFileAppender log4j.appender.A1.RollingPolicy=org.apache.log4j.rolling.MyTimeBasedRollingPolicy log4j.appender.A1.RollingPolicy.ActiveLogFile=my_log.txt log4j.appender.A1.RollingPolicy.FileNamePattern='.'-MM-dd-HH-mm log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n but it doesn´t work. Thanks in advance -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp import org.apache.Facetime; ApacheCon US 2003, 18-21 November http://apachecon.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Configuring a wrapper class for rolling policies
Hi all! I.m using a wrapper class (i.e org.apache.log4j.rolling.MyTimeBasedRollingPolicy) to performance an specific rollingPolicy for my purpose. Is there any way to configure it in log4j properties file? i tried something like : log4j.rootLogger=DEBUG, A1 log4j.appender.A1=org.apache.log4j.rolling.RollingFileAppender log4j.appender.A1.RollingPolicy=org.apache.log4j.rolling.MyTimeBasedRollingPolicy log4j.appender.A1.RollingPolicy.ActiveLogFile=my_log.txt log4j.appender.A1.RollingPolicy.FileNamePattern='.'-MM-dd-HH-mm log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n but it doesn´t work. Thanks in advance _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wrapper class
Hi, I'm using a wrapper class for log4j (version 1.2.8). The problem I have is that the log message contains the wrapper class as the originator and not the real class. I know that I can use the log(String callerFQCN,Priority priority,Object message,Throwable t) method (and pass my wrapper class as the fqcn), but I need to use the l7dlog functions (I use a resource bundle for my log messages) and I can pass a fqcn to those methods. Is there a way to use the localized log messages with the wrapper fqcn? The only way that I find is to subclass the Category/Logger class and override the forceLog method to use the wrapper class as the fqcn and not the FQCN constant that the Category class is using. Thanks in advance, Alon
