I just read the gwt-log Getting Started guide and found it very helpful, however I have a few questions surrounding the Loggers:
The SystemLogger sends output to System.err and System.out - in the context of a client-side web app running inside a browser, where will this output eventually go? Browser logs?
Does RemoteLogger depend on JUL or log4j? I have a homegrown slf4j binding that I like to use for all my Java backends, and would like to use it, but not sure if RemoteLogger will be incompatible with it?
Is it possible to have RemoteLogger hit my own LoggingServiceServlet, which could then translate the log messages coming in on the HttpServletRequest into logging statements that are compatible with my custom slf4j binding? If so, what might this config look like?
Thanks in advance!
In this link, you have a most updated documentation about the GWT logging framework
Answers to your questions:
#1 Yes it works in client side, but only when running the app in DevMode (not in production nor superdev mode). Look for the log lines in the DevMode window, or in your terminal output if you run dev-mode from the command-line.
#2 It depends on java.util.logging, you can change it though (see #3)
#3 Yes you can change the logging framework extending the RemoteLoggingServiceImpl and overriding the logOnServer(LogRecord lr) method.
Related
Using JBoss EAP 6.4 (AS 7.x I guess).
By default, JBoss' logging service is capturing all application output to stdout (and presumably stderr) and wrapping it in its own log4j-based logs. When running locally I want to totally disable this (annoying) feature1, but the references I've found on the Interwebs all either don't work or are for older versions of JBoss. I've tried excluding every possible logging framework in the jboss-deployment-structure configuration, passing -Dorg.jboss.logging.per-deployment=false as a system property, but still JBoss captures stdout.
How can I disable it in this version of JBoss?
[1] If you must know the reason, it's because we have detailed logging configuration via logback and when running locally in an IDE want to be able to see and control that log output in the console without JBoss' logging service getting in the way.
It's hard-coded in the entry points to capture stdout and stderr. This is done so both streams are written to the defined log handlers. Because of this there is no real clean way around it. However there are ways to make it at least look a little better.
You can create a new console-handler and define a stdout logger to ensure only the simple message is written though.
Here are some CLI commands to configure a logger named stdout to just print the message it receives.
/subsystem=logging/pattern-formatter=plain-formatter:add(pattern="%s")
/subsystem=logging/console-handler=plain-console:add(autoflush=true, target=System.out, named-formatter=plain-formatter)
/subsystem=logging/logger=stdout:add(use-parent-handlers=false, handlers=[plain-console])
Note: It could be my test logback.xml configuration, but I had to use a pattern of %s%n for the plain-formatter.
The only other option I can think of would be to write your own logback ConsoleAppender that creates an output stream based on java.io.FileOutputStream.out rather than using System.out.
I am a Java newbie so please excuse any incorrect terminology.
My Java application uses SLF4j which I have configured to use the SimpleLogger implementation and redirect log messages to a file.
The application uses the Jersey framework which depends on Grizzly, which as far as I can tell, uses the standard java.util.logging framework.
When I run the application the output from my log statements appears in the lof file as expected but the output from Grizzly's log statements appears in the console in red.
Ideally, I would like to redirect the Grizzly log output to my file. Is this possible?
Using this answer I was able to redirect the Grizzly output to a different file and I can turn it off altogether with:
Logger.getLogger("").setLevel(Level.OFF);
A similar question was asked here but the only answer provided is not helpful and was not accepted.
Can anyone help?
I have a web application, which uses log4j and slf4j as facade for logging. Logging is configured not from log4j.properties file, but from Java code.
Application is running on three different machines using Websphere Application Server.
Issue is that on two instances logging works as expected. But on the third one nothing is written in my logfile. Output goes to SystemErr.log instead (there are messages of ERROR and INFO levels).
Initially I thought that something is with Websphere server configuration, but later I found this link http://www.webagesolutions.com/knowledgebase/waskb/waskb004/ which says that such situation can be when log4j.properties can not be read.
But I am not using property file for this. And configuration form Java works OK on other two instances.
Any ideas what can be the issue?
Thank you in advance!
Please make sure that no alternative slf4j binding (such as simple) exists on the CLASSPATH.
I couldn't figure out from searching Stackoverflow/Google if this has been answered or if it's even possible to do. I've only found this
https://mina.apache.org/mina-project/userguide/ch12-logging-filter/ch12-logging-filter.html which suggests that "Once configured properly, you can continue to configure the actual logging framework you chose (e.g. modifying log4j.properties)." But I didn't know how to do that for my specific java.util.logging setup, described below.
Setup:
I have a program that uses java.util.logging to output logging to FileHandler and ConsoleHandler. I'm using the Apache SSHD library in my program, from which I am including only [sshd-core-0.14.0.jar, slf4j-api-1.6.4.jar, slf4j-jdk14-1.6.4.jar] specifically.
Goal:
Logging from SSHD is currently output to the console, but not to my log file. I want to configure SSHD to route its logging to my file and/or console as I specify from within my program.
Is this even possible? Do I need to switch to another logging mechanism? I didn't think logging configuration would be this complicated and take up a not insignificant amount of time/effort.
So, I'm beating my head against the wall with logging again. I know, how complex can it be? Well, let's see...
I'm starting a new project to be run on WebSphere Application Server 6.1 (actually Portal Server 6.1, but it's WAS 6.1 under the hood - whatever). I usually use java.util.logging for my WAS projects and everything is fine. This customer is a SLF4J fan and wants to use that. Fair enough, sounds easy.
So, I deploy slf4j-api-1.5.8.jar and slf4j-jdk14-1.5.8.jar in my WEB-INF/lib directory. In my code I do a --
// These classes are coming from org.slf4j.*
private static Logger log = LoggerFactory.getLogger(MyClass.class);
...
log.debug("This is a log message");
As expected I get an entry in the SystemOut.log. However, it's the format of that message that I can't figure out. A sample would be --
[12/15/09 15:43:15:071 EST] 00000042 MyClass D com.example.MyClass This is a log message
Let me explain what's in that sample log entry. I assume everything to the left of com.example.MyClass is coming from the j.u.l formatter. Everything to the right of it is what I included in my log.debug(). So, who's adding the com.example.MyClass? Only thing I can think is that SLF4J is adding it before it passes the message through to the underlying j.u.l.
It's the com.example.MyClass part that's irritating me. I don't want that included in the SLF4J-generated log message. The class name is already included, so it's extra fluff that's not needed. Plus, the real package names are quite long and their inclusion just pushes the real meat of the log entry too far off to the right.
When I use just plain java.util.loggging, the log entry is exactly the same except that the "com.example.MyClass" piece is not included. Exactly as I want!
So, the question is - how can I get rid of this extra class name entry in the log messages generated via SLF4J under WAS?
Thanks!
You bind slf4j to java.util.logging which most likely is configured inside WebSphere as it doesn't look like the standard message format.
I do not know WebSphere, but you may get a better result by telling slf4j to bind to something else. Would the slf4j-simple backend do? It just prints out info-or-higher messages instead of invoking java.util.logging.
Basically you want to configure the layout of the logging messages produced by the underlying logging mechanism.
SLF4J does not actually perform the logging, but delegates to other logging systems (log4j, JUL, etc) based on how you set it up.
So if you are binding SLF4J with JUL, then I think the real question you are asking is either one of
Setting the Formatter of a Logger Handler
Creating a Custom Formatter for a Logger Handler