I am trying to track down a problem with GWT. I get an error which I want to track down to the source but log4j truncates the stacktrace by indicating something like "... 26 more" hence I cannot determine the exact location for the problem. I tried finding out if there is anyway to prevent that truncation but have been unable to find any option that will accomplish that. Is this truncation a configurable feature?
I am running Tomcat 6.0.31, Spring 3.0 (for backend), GWT 2.1.0.
Thanks
It isn't log4j truncating the stack trace, it's standard Java. And it's actually only making the trace more readable because those lines that were omitted were already output by the 'enclosing' exception. See Throwable javadoc.
Related
I have this error in the console, below which gives the number 8301. What does this number mean and how can I use it to troubleshoot the error?
(node:8301) DeprecationWarning: current URL string parser is
deprecated, and will be removed in a future version. To use the new
parser, pass option { useNewUrlParser: true } to MongoClient.connect.
Pleas note, I am using this as an example error to try and understand the printed number (node:8301). I don't need help with the error itself.
Please help me to understand node errors.
The number portion of (node:8301) is the node process's process id (pid). This is attached to all warnings that Node.js itself emits, or that are emitted via its process.emitWarning() utility.
(In the particular example in the question, the warning is from a user module using process.emitWarning().)
For what it's worth, NODE_DEBUG also logs pids in the logged information, although strangely not in that format.
I'm not sure if there is actually official documentation on this. There is presently a discussion to add a "Warnings" section to the official documentation: https://github.com/nodejs/node/issues/24987
This question was also asked to https://github.com/nodejs/node/issues/25120, where I discovered and originally answered it.
try this:
MongoClient.connect("mongodb://localhost:27017/YourDB", { useNewUrlParser: true })
from here
Honestly, I’ve been working in node since 2009, and I’ve never bothered to look into the error codes unless I need my software to handle the error. Mostly, I just read the error text.
In the case of your example, the error text clearly tells me what the problem is.
I’ve found generally that the quality of error messages and codes alike varies greatly on the library you’re using.
I'm using CAS for single signon solution, My log(log4j version 1.2.15) file completely fills with the Exception(org.jasig.cas.authentication.handler.BadCredentialsAuthenticationException)
Stack trace when User enters invalid login credentials.
Is there a solution to trim the Stack trace in CAS or Java?
I can't use log4j EnhancePatternLayout to achieve this as it requires log4j version 1.2.16
Any suggestions around this problem would be appreciated.
Thanks
I haven't used CAS. However, the way that I've gotten around similar problems in the past is by suppressing log messages from the offending class. For example, if you're using a log4j.properties file, insert this line:
log4j.logger.com.jasig.cas.WhateverClassLogsTheException=OFF
Note that you will need to suppress messages from the class that throws the exception, not the exception class itself. Also, you can also use FATAL or other values to ensure that only log messages that are at or above the given level are logged. See the Log4J docs for more information.
Note that this will suppress all messages from that class, not just the particular log message that produces that exception.
The problem is CAS is passing Exception object to Log4j,so I did comment that line in my overlayed class. BindLdapAuthenticationHandler.java
We have a log4j file that has the following pattern:
#|%d{yyyy-MM-dd HH:mm:ss.SSS}|%X{Machine}|%X{CorrelationId}|%X{Sender}|%X{Receiver}|%-5p|%X{Runtime}|%X{ClientUser}|%c|%M|%L|%m%n
I created a LogFilePatternReceiver with the following pattern:
#|TIMESTAMP|PROP(MACHINE)|PROP(CORRELATIONID)|PROP(SENDER)|PROP(RECEIVER)|LEVEL|PROP(RUNTIME)|PROP(CLIENTUSER)|CLASS|METHOD|LINE|MESSAGE
But when I start that receiver I get an error:
java.lang.IllegalArgumentException: invalid expression:
at org.apache.log4j.rule.ExpressionRule$PostFixExpressionCompiler.compileExpression(ExpressionRule.java:132)
at org.apache.log4j.rule.ExpressionRule.getRule(ExpressionRule.java:64)
at org.apache.log4j.rule.ExpressionRule.getRule(ExpressionRule.java:56)
at org.apache.log4j.varia.LogFilePatternReceiver.initialize(LogFilePatternReceiver.java:557)
at org.apache.log4j.varia.LogFilePatternReceiver$1.run(LogFilePatternReceiver.java:801)
at java.lang.Thread.run(Unknown Source)
regexp is #|(\w+-\w+-\w+ \w+:\w+:\w+.\w+)|(.+?)|(.+?)|(.+?)|(.+?)|(.+?)|(.+?)|(.+?)|(.+?)|(.+?)|(.+?)|(.+)
I don't really see where the error is? Any input? Can I use the "PROP(...)" keyword like that for columns that are non-standard?
Yes, you can use the PROP keyword for your own columns..
Can you try the latest developer snapshot of Chainsaw? It can parse your log4j.xml or log4j.properties configuration containing FileAppender entries and will build a matching Chainsaw config to process that.
Snapshot available here..the new version also has a lot of new features:
http://people.apache.org/~sdeboy
What usually trips people up is timestamp formatting and special characters, but I don't see anything weird here, so see if the latest developer snapshot helps.
Scott
I just spent the better part of 3 hours trying to get my Rails application logging with Log4j. I've finally got it working, but I'm not sure if what I did is correct. I tried various methods to no avail until my very last attempt. So I'm really looking for some validation here, perhaps some pointers and tips as well -- anything would be appreciated to be honest. I've summarized all my feeble methods into three attempts below. I'm hoping for some enlightenment on where I went wrong with each attempt -- even if it means I get ripped up.
Thanks for the help in advance!
System Specs
Rails 3.0
Windows Server 2008
Log4j 1.2
Tomact 6.0.29
Java 6
Attempt 1 - Configured Tomcat to Use Log4J
I basically followed the guide on the Apache Tomcat website here. The steps are:
Create a log4j.properties file in $CATALINA_HOME/lib
Download and copy the log4j-x.y.z.jar into $CATALINA_HOME/lib
Replace $CATALINA_HOME/bin/tomcat-juli.jar with the tomcat-juli.jar from the Apache Tomcat Extras folder
Copy tomcat-juli-adapters.jar from the Apache Tomcat Extras folder into $CATALINA_HOME/lib
Delete $CATALINA_BASE/conf/logging.properties
Start Tomcat (as a service)
Expected Results According to the Guide
I should have seen a tomcat.log file in my $CATALINA_BASE/logs folder.
Actual Results
No tomcat.log
Saw three of the standard logs instead
jakarta_service_20101231.log
stderr_20101231.log
stdout_20101231.log
Question
Shouldn't I have at least seen a tomcat.log file?
Attempt 2 - Use default Tomcat logging (commons-logging)
Reverted all the changes from the previous setup
Modified $CATALINA_BASE/conf/logging.properties by doing the following:
Adding a setting for my application in the handlers line: 5rails3.org.apache.juli.FileHandler
Adding Handler specific properties
5rails3.org.apache.juli.FileHandler.level = FINE
5rails3.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
5rails3.org.apache.juli.FileHandler.prefix = rails3.
Adding Facility specific properties
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/rails3].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/rails3].handlers = 4host-manager.org.apache.juli.FileHandler
Modified my web.xml by adding the following context parameter as per the Logging section of the jruby-rack README (I also modified my warbler.rb accordingly, but I opted to change the web.xml directly to test things faster).
<context-param>
<param-name>jruby.rack.logging</param-name>
<param-value>commons_logging</param-value>
</context-param>
Restarted Tomcat
Results
A log file was created (rails3.log), however there was no log information in the file.
Attempt 2A - Use Log4j with existing set up
I decided to give Log4j another whirl with this new web.xml setting.
Copied the log4j.jar into my WEB-INF/lib folder
Created a log4j.properties file and put it into WEB-INF/classes
log4j.rootLogger=INFO, R
log4j.logger.javax.servlet=DEBUG
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=${catalina.base}/logs/rails3.log
log4j.appender.R.MaxFileSize=5036KB
log4j.appender.R.MaxBackupIndex=4
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%d{dd MMM yyyy HH:mm:ss} [%t] %-5p %c %x - %m%n
Restarted Tomcat
Results
Same as Attempt 2
NOTE: I used log4j.logger.javax.servlet=DEBUG because I read in the jruby-rack README that all logging output is automatically redirected to the javax.servlet.ServletContext#log method. So I thought this would capture it, but I was obviously wrong.
Question
Why didn't this work?
Isn't Log4J using the commons_logging API?
Attempt 3 - Tried out slf4j (WORKED)
A bit uncertain as to why Attempt 2A didn't work, I thought to myself, maybe I can't use commons_logging for the jruby.rack.logging parameter because it's probably not using commons_logging API... (but I was still not sure). I saw slf4j as an option. I have never heard of it and out of curiosity, I decided to look it up. After reading about it briefly, I thought it was as good of a shot as any and decided to try it out following the instructions here.
Continuing from the setup of Attempt 2A:
Copied slf4j-api-1.6.1.jar and slf4j-simple-1.6.1.jar into my WEB-INF/lib folder
I also copied slf4j-log4j12-1.6.1.jar into my WEB-INF/lib folder
Restarted Tomcat
And VIOLA! I now have logging information going into my rails3.log file.
So the big question is:
WTF?
Even though logging seems to be working now, I'm really not sure if what I did is right. So like I said earlier, I'm really looking for some validation more or less. I'd also appreciate any pointers/tips/advice if you have any. Thanks!
We also did various experiments and finally settled with slf4j option. Coming from Java background we knew slf4j, so we didn't go further.
<context-param>
<param-name>jruby.rack.logging</param-name>
<param-value>slf4j</param-value>
</context-param>
btw, there is no need to copy slf4j-simple-1.6.1.jar into tomcat/lib or WEB-INF/lib when using slf4j-log4jxxx.jar
It's possible that your early tests with commons-logging were showing zero bytes files because of bufferSize.
If your entries get flushed to the file when you stop Tomcat then this is indeed the case and you are falling foul of the default 8Kb buffer.
To disable, for immediate flushing try...
org.apache.juli.FileHandler.bufferSize = -1
on the specific handler...
So for localhost...
2localhost.org.apache.juli.FileHandler.bufferSize = -1
Even with the following in spark section of web.config:
<pages automaticEncoding="false">
Things between ${...} Still get passed through H(...), which HTML encodes it.
How change this or should I just fall back to !{...}?
You can change Spark's default using its configuration, though I would recommend you use ${} when you want encoded HTML and !{} when you don't.
Spark can be configured from either Web.config or using a SparkSettings instance.
In Web.config, under your <spark> configuration, add:
<pages automaticEncoding="false">
You'll want to make sure you only have the one <pages/> element. I'm unsure if Spark's processor will raise an error if you have multiple.
Using SparkSettings, add:
SparkSettings settings = new SparkSettings()
.SetAutomaticEncoding(false);
If you have these settings and still get automatic encoding, set a break-point at the point where you instantiate your SparkViewFactory (or use Console.WriteLine() or your logging framework) and have a look at:
mySparkViewFactory.Settings.AutomaticEncoding