I have a problem about logging in SystemOut.log with Websphere. Can someone help me?
I’m getting some unwanted warning written in the SystemOut.log file with Websphere Application Server (WAS). All of the warnings are being generated by OGNL (ognl.NoSuchPropertyException). These exceptions don’t affect the code flow. Hence I need to turn off the logging of these warnings.
Also I have configuration in log4j.properties file to control the filtration of the log messages to error.
It would be a great help if anyone can help what configuration I should do in WAS to avoid logging these warnings.
Regards
You can change the log level from WAS admin console. Servers->WAS->servername->troubleshooting->change log details level
Follow the path and you will see options to filter warning. For example to filer message from com.ibm.ws.*=WARN will filter all but WARN.
Hope this helps.
First, you have to determine what running component, inside your WAS instance, is generating these warning messages. Is it WebSphere itself, logging these warnings internally? or is it your code?
If the source is WebSphere, then perhaps, before setting the logging level to "error" or "severe", you may want to open a PMR with IBM. I never encountered OGNL warnings generated by WebSphere itself. These warnings, then, can be indicative of a problem in your WebSphere installation.
If the source is your application, then the way to cope with this situation depends on how OGNL, internally, is generating these messages:
If OGNL is simply writing log lines to System.out, then there's nothing you can do to suppress these lines.
If OGNL is logging through Log4J, then you should be able to set the log level of the OGNL logger(s) through your log4j.properties. If your log4j.properties changes aren't reflected, then it means that you have a classloading problem of some sort (the log4j.properties file being loaded by a different classloader than the one used to load your web application).
If OGNL is using a different logging framework (such as SLF4J or Commons Logging), then you'll have to read through the documentation of these frameworks to learn how to tune the logging level.
Related
I am writing a spring-batch application, based on an example I found. When I run it in Eclipse, it produces some annoying INFO logs from deep inside the framework. I'd like to suppress that, so only my System.out statements show - for clarity.
I figured the logging is from the inherited commons-logging1.1.1.jar, that's in my classpath, because when I take out that reference I get errors about Logger.
Question1: Which framework is used for logging in my sample application and how can I change the default INFO to WARN?
Question2: will adopting Log4j just override this default behavior?
I've create two property files under /resources: commons-logging.properties, with this: org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog, and simplelog.properties, with this: org.apache.commons.logging.simplelog.defaultlog=warn It worked. Thanks - –
I cannot control logging levels for my code in Websphere Liberty Profile server.
I have configured the server.xml on the server not to log hibernate and spring, since my logs will get flooded with activity from those two frameworks. I commonly do this using log4j and it works fine in standalone WAS.
<logging consoleLogLevel="INFO" copySystemStreams="true" traceFormat="ENHANCED" traceSpecification="org.springframework.*=off:com.ibm.ws.*=off:org.hibernate*=off"/>
In Liberty this does not work.
I get the following log when liberty updates the configuration (when I save server.xml with the changes):
[INFO ] TRAS0040I: The configured trace state included the following specifications that do not match any loggers currently registered in the server: org.hibernate*=off:org.springframework.*=off
Basically this message applies to any of my code and any third party code (Spring, Hibernate, etc).
However the traceSpecification levels work fine for the IBM classes, and I'm able to specify *=off, which effectively turns off all logging.
Has anyone experienced this?
IBM's documentation for TRAS0040I seems simple enough, but I can't seem to figure out why my loggers are not getting registered with the server.
Liberty doesn't have a rich control on logging. You should understand the difference between "logging" and "tracing". Check description of console.log, messages.log, trace.log files at the beggining of: http://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.wlp.doc/ae/rwlp_logging.html
Your configuration in "traceSpecification" - actually will do nothing, as spring and hibernate are logs from JVM and they doesn't go to trace, so trace configuration doesn't affect them.
All you can configure in liberty for jvm logs is consoleLogLevel (INFO, AUDIT, WARNING, ERROR, and OFF)
If you want to configure log levels for specific components in Liberty - you should use for example log4j with own configuration
I'm confused as to how the errors are logged without me implicitly catching them and logging out the error. All that I've done is put a log4j.xml file in my project defining appenders and now the logs catch and log everything from the frameworks.
If I say, try to query in Hibernate and the query fails, or I try to open a file that doesn't exist, or I get a null pointer exception, if the log4j.xml file defines a log file, and the error level is set correctly, then the error will be captured there?
How does my spring web app capture errors that I didn't catch and log? Is this a result of apache commons logging?
Or is this some magic that log4j knows how to deal with - catch stream to the console etc?
Any info appreciated.
From spring official documentation:
The nice thing about commons-logging is that you don't need anything else to make your application work. It has a runtime discovery algorithm that looks for other logging frameworks in well known places on the classpath and uses one that it thinks is appropriate (or you can tell it which one if you need to). If nothing else is available you get pretty nice looking logs just from the JDK (java.util.logging or JUL for short). You should find that your Spring application works and logs happily to the console out of the box in most situations, and that's important.
To make Log4j work with the default JCL dependency (commons-logging)
all you need to do is put Log4j on the classpath, and provide it with
a configuration file (log4j.properties or log4j.xml in the root of the
classpath).
Take a look for a complete explanation: http://static.springsource.org/spring/docs/3.0.x/reference/overview.html#d0e743
I am having problems integrating perf4j in an existing maven application.
I tried several approaches, but none of them seemed to work, so I was wondering if anyone has some insight into how this is done.
What I want to do is use the AOP part of perf4j on some methods and log them into a different file than the one used for app logging. Thanks
You might be suffering from the same declaration order issue as mentioned in another perf4j/logback related question. In short, it is always a good idea to enable printing of logback's internal status messages by setting the debug attribute to true within the configuration element. Also do not forget that any referenced appender must be declared beforehand.
I am currently working on a portlet that is using the commons-collections jar file and am getting a NoSuchMethodError. To resolve this issue I need to change the classloader of my WAR file from PARENT_FIRST to PARENT_LAST (in the application.xml file).
However, when I do this my portlet will not launch and when I log into the console it displays the message "The portlet is temporarily disabled". If I change the classloader back to PARENT_FIRST then it will launch again but then I get the NoSuchMethodError.
Does anybody have any suggestions on how to fix this issue ?
I am not sure how, but today I started getting error messages in the logs when I was getting "The portlet is temporarily disabled". I was getting a java.lang.LinkageError which was down to the fact that I had the servlet-api-2.5.jar and a jaxb jar which was conflicting with webshpere j2ee.jar. Once I removed these dependencies and set the classloader to PARENT_LAST, it seems to work properly. It seems that a lot of people face similar issues. The link below is also useful http://forum.springsource.org/showthread.php?33663-dispatcher-servlet-quot-not-a-servlet-class-quot-in-websphere
#MTH,
please try adding commons-collections as a shared library. See here for an example on how others have used shared library support [1]. That will give you the steps, just do it for the jars that you need to override/replace from WAS's classloader
[1] http://portals.apache.org/jetspeed-2/deployguide/deploying-jetspeed-to-websphere.html#section_4_2
thanks,
dims
You haven't provided any logs... but still, one of the most important things to look out for when setting your application to run PARENT_LAST is that your application isn't bundled with any system-level classes that may conflict with the ones provided by WebSphere Portal. For example, classes that pertain to the Portlet specification or the JavaEE specification.