I use HSQLDB on OSGI framework. And it is common solution to use pax-logging that support many logging frameworks (java logging, slf4j, jboss logging etc).
I don't have problems with pax-logging, however, I have problems with HSQLDB logging messages. HSQLDB logging component is very tricky - some messages go to pax-logging system, some go to console.
Could anyone explain what messages where must go and why.
There are separate logging components in HSQLDB.
The Server uses separate writers for log and error messages. The logs default to stdout and stderr but you can set each one to use a custom PrintWriter.
The optional SQL log is always a file. It can be turned on and off live for checking the SQL statements being executed.
The optional event log is a file or an external logging framework. The latter is used when the database is in-process in an application. In both configurations, it reports general persistence events at different levels of detail selected by the user.
Related
I'm used to using log4j and whenever there were setup/config problems I'd enable "-Dlog4j.debug" and all the config info would be dumped out at startup.
This was very useful on a number of occasions.
Now I'm working on a Spring boot application, which I've found uses:
Commons logging Logger statements in the client code
A bridge jar (jcl-over-slf4j-xxx.jar) which translates the commons logging calls into slf4j more info here
Finally slf4j uses "logback" as the underlying logging framework
I found it rather painful to figure all this out.
Is there an equivalent of -Dlog4j.debug which can show me how this is all hanging together at startup time?
This is the best/only option I've found so far, and it's logback specific.
Use this -D on the command line:
-Dlogback.statusListenerClass=ch.qos.logback.core.status.OnConsoleStatusListener
Taken from here
This essentially is the logback equivalent of log4j's -Dlog4j.debug.
It dumps the logback startup sequence to the console at startup time, as the logging system is initialised.
This is not a true answer as I'd like some messages to show before this to show why logback is being used, but I haven't found anything like that yet.
Aside: This may also be useful for Spring Boot:
-Ddebug
Taken from here and here
If you are using logback, I assume you are using the logback.xml file? Then if you start that file with <configuration debug="true"> then it should dump the status information. More information in the documentation under status data section.
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 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've a problem with OpenJPA logging and Websphere (8).
For a few days I try to redirect the OpenJPA logging information into a separate file (instead of the SystemOut log file). This is what I tried:
Changing the persistence.xml with logging information (e.g. ). Though I learned that websphere is ignoring this entry. Can I assume that this is correct?
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.express.doc/info/exp/ae/tejb_loggingwjpa.html tells me the same
Also the wsjpa.log property did not help.
Specifying a handler for openjpa (or openjpa.Runtime, ...) in JSR-47 configuration file does not work either (other configurations worked). What I realized here is that there is actually no openjpa logger in the java logging (java.util.logging.LogManager.getLogManager().getLoggerNames()). Does that mean that OpenJPA is not logging to a dedicated logger but just writes to SystemOut which is then processed by websphere?
I searched through all the different loggers and traces in the websphere console and tried a few, but none of them contained any openjpa logs. Can I assume that there is no other location where openjpa logs to in websphere?
To conclude: It's not working and I cannot use a handler for the openjpa logs because there are no logs generated. OpenJPA in websphere is just printing to the SystemOut which is internally used for the tracing. Does anyone have an idea what to do?
Alternatives would be:
- Use HPEL
- Script to filter the trace.log
But actually I would rather have a file handler for OpenJPA in Websphere.
Thanks for your help and I can supply you with some more information if you need that.
You can use application logging system for this purpose based on 3d party logging library for example logback.
logback is very powerful library.
I have a Swing-based application that logs all messages to text files through slf4j with logback underneath.
I'd like to add a feature to show all messages at a certain level(e.g. fatal) logged in the current session on demand, say in a JTable.
Does slf4j provide API that lets you access historical log messages, preferably filtered by level or time?
Try to use Logback, there is a ch.qos.logback.classic.db.DBAppender class that you can use as an Appender to your fatal errors. You can define your own data structure, just provide the SQL Insert statement. Also, other variants of this DBAppender are provided, so you can choose when do you want to customize the behavior.
The next thing is that you tie your appender to those loggers that you want to log.
Finally you can manage your logged data within your application (filter, purge/archive) just like your application business data.