JAX-WS logging & timestamp - java

I am using JAX-WS in WebLogic and I was able to enable the message logging by using following parameters (as specified at https://metro.java.net/guide/ch02.html#logging):
com.sun.xml.ws.transport.http.HttpAdapter.dump=true
com.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true
The log entries however do not contain any timestamps so I have almost no information about when each message was received/sent.
Is there any way to add timestamps to the resulting log entries?

I guess you need to configure log messages format:
java.util.logging.SimpleFormatter.format="%4$s: %5$s [%1$tc]%n
More about configuration options could be found here:
http://docs.oracle.com/javase/7/docs/api/java/util/logging/SimpleFormatter.html

I have finally found a solution for this.
The only thing that must be done is to redirect stdout logging to WebLogic logging system by checking “Redirect stdout logging enabled” in Advanced logging section of your managed server’s configuration (e.g. Logging -> General -> Advanced).
This will add timestamps to the SOAP message logs.

Related

How to suppress logging output to stdout when using Jetty Websocket client?

When using Jetty's Websocket client implementation and creating an instance of WebSocketClient, logging is being written to stdout as such:
2018-08-22 22:30:34.720:INFO::main: Logging initialized #26651ms to org.eclipse.jetty.util.log.StdErrLog
This occurs as soon as doing this:
WebSocketClient client = new WebSocketClient();
I tried including a jetty-logging.properties file as part of the resource bundle with log levels turned OFF but that didn't work:
org.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.StrErrLog
org.eclipse.jetty.LEVEL=OFF
org.eclipse.jetty.websocket.LEVEL=OFF
How do I suppress this?
Thanks,
Tobias
Verified with Jetty 9.4.x: add /jetty-logging.properties to your classpath:
org.eclipse.jetty.util.log.announce=false
Because I'm using slf4j-simple, also /simplelogger.properties:
org.slf4j.simpleLogger.defaultLogLevel=warn
Setting a system property inside the code is flaky for obvious reasons. (https://javagc.leponceau.org/2019/02/how-to-suppress-embedded-jetty-logging.html)
I managed to figure it out by stepping into WebSocketClient() with a debugger until the message was printed to stdout.
To disable this logging announcement, set a system property.
System.setProperty("org.eclipse.jetty.util.log.announce", "false");
I wish the Jetty documentation had an overview of properties it honors.

Is it possible to get the root log level of Jboss Server, if custom loggers are used instead of logging service provided by the Server?

Following are the requirements,
multiple modules deployed on JBoss AS 7 with individual logging configuration using logback.xml.
all of them request exclusion of default logging-service provided by the Server, using jboss-deployment-structure.xml.
Following are observation,
log.debug statements get printed as INFO on Server log(server.log)
it's because root level of custom-logger(logback.xml) is set to DEBUG
Now questions,
How can I make, DEBUG statements generated by custom logging statement gets printed with appropriate log level?
Conversely, is it possible to get log level of Server without using it's logging service?
In other words, is it possible to achieve uniform log-level configuration across multiple modules that use custom-loggers?

Apache Logging - Send log output directly to queue

Am using Standard apache logging (org.apache.log4j.logging )
Currently, taking the data to be logged manually, and publishing in to Apache Active MQ.
Is it possible to configure the logging output to publish directly in to Active MQ??
This might sound stupid, but since both are from Apache, I have a doubt that whether, it has any implicit support, which I could not grab it.
log4j provides JMSAppender out of the box. It allows publishing logging events to JMS Topic.
For configuration specific to ActiveMQ please check the documentation - How do I use log4j JMS appender with ActiveMQ
Not sure if you were looking for log4j-1.x or log4j-2.0, but here are the links for log4j-2.0:
http://logging.apache.org/log4j/2.x/manual/appenders.html#JMSQueueAppender
http://logging.apache.org/log4j/2.x/manual/appenders.html#JMSTopicAppender

Jetty HTTP logging

I would like to have Jetty log all HTTP requests (along with the body) and responses. Is this natively supported by Jetty? Ideally it would log to my existing log4j log file.
I am running Jetty 6.
Jetty comes with a request logger that can log in NCSA format. That format doesn't include things like request body as you require, but that standard format will fit tools like webalizer and the like.
If you need to log more you can use the logback request log implementation or write your own logger by implementing Jetty's RequestLog interface.
Besides that I'd highly recommend to upgrade to jetty7/8 (same codebase, but 8 provides servlet 3.0 functionality). Or directly move to jetty9.
Here's the jetty9 documentation for request logs:
http://www.eclipse.org/jetty/documentation/current/configuring-logging.html#configuring-jetty-request-logs
Same for jetty7/8:
http://wiki.eclipse.org/Jetty/Tutorial/RequestLog
I leave it as an exercise for you to find the jetty6 docs or better yet, upgrade. :)
Ok, just found the jetty6 docs by accident: http://docs.codehaus.org/display/JETTY/Logging+Requests
TL;DR
You have to enable the right modules, just add into the start.ini file:
# Create access log file
--module=requestlog
# Redirect all the console log to a file
--module=console-capture
Restart Jetty and have a look into the logs directory.

Websphere with Logback logging to system out - formatting issue

I am using Logback in my application hosted on Websphere App Server. Logback is configured to log to System Out (and others are hesitant to change to a different file). The issue is that Websphere uses its own format for logging to System Out. Executing logger.debug("test") in my app yields:
[8/7/12 12:27:55:629 CDT] 0000003a SystemOut O DEBUG com.myapp... test
where everything up to the "O" is added by Websphere. The rest is from Logback
I have set up Logback to use the following pattern: %-5level %logger{36} - %msg%n so that I don't repeat timestamp and thread info which Websphere does on its own, but I am still annoyed that I can't fully customize the logging to System Out from within Logback.
I don't know a whole lot about logging best practices. Before, I have logged to separate files by web app, but for this project, I was told the System Out files are monitored by a third party and I should not change from using System Out. Is there any way to get around my issue given these requirements and tell Websphere not to mess with my System Out logging, or is the only solution to start logging to a different file? Thanks!
Your logback is configured to write messages to System.out. However, everything that is written to System.out is redirected by WebSphere and written to the SystemOut.log file with the same format as log messages produced by WebSphere, but with a severity indicator "O". It is not possible to change that.
Note that it is likely that the people who told you to use SystemOut.log actually meant that you should ensure that logging is done using WebSphere's log system so that messages are written with the correct category and severity and that log levels can be changed at runtime. Since WebSphere's log system is build on java.util.logging you should probably just replace logback by slf4j-jdk14 to satisfy their requirement.
I don't think you're going to be able to change the format. And if you could, it might break the current monitoring anyway.
I wonder if anyone would mind if you log to two loggers at the same time, SystemOut for the existing monitoring, and your own for a more readable format.
The problem is that Logback redirects the messages to console output instead of java.util.logging. Console output has no log levels and that's why WebSphere just writes "O".
We solved this by implementing a Logback appender that redirects logs to JUL (java.util.logging) instead. We convert Logback log levels to JUL levels (e.g. Logback "ERROR" is JUL "SEVERE").
We also wanted to use Websphere's trace options. If trace is enabled for a class/package pattern, you will see Logback DEBUG and TRACE messages in Websphere's trace.log. You can also check if the trace is enabled by calling Logback's isDebugEnabled() / isTraceEnabled().
See this answer with a full implementation:
https://stackoverflow.com/a/74386323/395879

Categories

Resources