How do I configure internal event monitoring in hsqldb? When I run my Java application, I get the following warnings:
log4j:WARN No appenders could be found for logger (HSQLDB2C7984E18B.org.hsqldb.persist.Logger).
log4j:WARN Please initialize the log4j system properly.
The documentation tells me log4j is not the only option, but it doesn't tell me how to configure my application. Can anyone point me to this documentation? Remember, I don't want to use log4j for hsqldb.
It bears mentioning that a 3rd-party jar I'm referencing requires log4j. Does hsqldb automatically detect that log4j is present and then attempt to use it? Or am I missing something fundamental about how logging works?
Check out this link. It says
The logging facility hands off to Log4j if Log4j is found in the classpath, and otherwise will hand off to java.util.logging.
The consequence of what the message indicates is that no logging for HSQLDB will take place because no appenders were found.
If you wish to suppress the message, add a line like the one below to the log4j.properties file:
log4j.logger.HSQLDB2C7984E18B.org.hsqldb.persist.Logger=FATAL
This will log only FATAL events, which wouldn't happen in normal operation.
You also state that you don't want to use log4j for HSQLDB. Software components that can use log4j leave the logging configuration (including level and where to log, etc.) to the log4j properties settings, which you can edit and configure.
In this case, the logger name is based on the "unique" database name which is initially autogenerated, but which you can change in HSQLDB.
Because as YWE noted hsqldb uses log4j by default if it is found in the classpath, I needed to figure out how to override the log4j.properties found in the 3rd-party library. This I managed to do as follows:
Copy the existing log4j.properties to my project, and add the following line at the beginning:
log4j.rootLogger=WARN, CONSOLE
Add the following VM Arguments:
-Dlog4j.log4j.defaultInitOverride=true
-Dlog4j.configuration=C:/full/path/to/my/log4j.properties
Make sure this line of code runs before anyone (e.g. hsqldb) attempts to use log4j:
org.apache.log4j.PropertyConfigurator.configure("log4j.properties");
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.
I have 4 appllications (ear) on my WAS. I need them to write in SystemOut.log some sign. I.e each application must write to log file its own sign. For example:
[16.01.17 3:50:05:592 GMT+05:00] ADMIN 000005e0 SubsystemMess I com.docflow.core.integration.jms.SubsystemMessageListener onMessage_aroundBody0 Subsystem integration message ID:f5392a5ec3b3f41502095b00110a134f0000000000000001 of type DP_EKS_BANK_GUARANTEE_RECEIVED process finished
Here ADMIN is sign of the application.
How i can do that?
It's not possible to adjust the default logging format in this way. Your options would be to use java.util.logging.Logger with a particular name (to replace the "SubsystemMess" part) or to use a separate logging package and configure it to log to a separate file.
Look at log4j and configuring each app's log4j to go to a different file.
Log4j's file appender can be configured to also include timestamp and more.
The only catch is you can't configure it from WAS's admin console then.
Note that java.util.Logger writes to the trace.log. If you use a different logger name, it will list as such in the same trace.log file. Upside is you can now configure it from the admin console.
One potential solution could be to switch to HPEL logging. Then you could query log entries for your given application using logviewer, like:
logViewer.sh -includeExtensions appName=PlantsByWebSphere
I know that it is not exactly what you are looking for, but maybe it will be sufficient for your needs.
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'd like to configure log4j in a huge distributed system. There are a lot of JVMs and processes and (as I am only a student) I am new to such a situation. I use JMS Appender, so I need two files: log4j.properties, jndi.properties.
I've tried some ways:
Put these files into src folder
or into src/java
add jvm argument -Dlog4j.configuration=C:\...\log4j.properties
I don't want to set it in code using PropertyConfigurator.configure("path"), because I'd like to not change source code at all.
Are there any other ways to configure log4j? Or maybe I am missing something? I still get a messages
No appenders could be found for logger (some.package.SomeClass).
Please initialize the log4j system properly.
basically you have the following ways to configure Log4J:
Via your code
properties file (as you're trying to use)
Xml File
What you're asking to me related to specific configuration of JMS appender and its not about 'general way of how to configure log4j'
Here is an example of how to configure it with ActiveMQ
For other JMS implementations in your property file the keys will be probably the same but the values will be different
Example - using JMS appender with ActiveMQ
I'm using Hibernate's c3p0 connection pooling and standard Java 1.4 java.util.logging. Upon startup, my app sets up it's logging properties (including formatter and log levels) in static block. Every time I start my app, I see the following:
2011-04-16 17-43-51 [com.mchange.v2.log.MLog] INFO: {MLog.<clinit>) MLog clients using java 1.4+ standard logging.
2011-04-16 17-43-51 [com.mchange.v2.c3p0.C3P0Registry] INFO: {C3P0Registry.banner) Initializing c3p0-0.9.1 [built 16-January-2007 14:46:42; debug? true; trace: 10]
2011-04-16 17-43-51 [com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource] INFO: {AbstractPoolBackedDataSource.getPoolManager)
...
I've tried
Logger.getLogger("com.mchange").setLevel(Level.WARNING);
com.mchange.v2.log.MLog.getLogger().setLevel(MLevel.WARNING);
System.setProperty("com.mchange.v2.log.FallbackMLog.DEFAULT_CUTOFF_LEVEL", "WARNING");
but only way to prevent it that I found for now is
Logger.getLogger("").setLevel(Level.WARNING);
which affects everything - not a good side effect. Google didn't help. Could anyone help please?
The way I found is to set the system property
System.setProperty("com.mchange.v2.log.MLog", "com.mchange.v2.log.FallbackMLog");
in addition to
System.setProperty("com.mchange.v2.log.FallbackMLog.DEFAULT_CUTOFF_LEVEL", "WARNING");
I thought, that absence of any other logging system wil make that optional, but it seems, that I was wrong.
P.S.
Damn those wheel-reinvented custom logging implementations, like the one used by c3p0...
The way I found for achieving this
Create in your classpath a file called mchange-log.properties and put into it properties suggested by Frozen Spider.
com.mchange.v2.log.MLog=com.mchange.v2.log.FallbackMLog
com.mchange.v2.log.FallbackMLog.DEFAULT_CUTOFF_LEVEL=WARNING
Thats work fine even when you are not able to set system properties directly.
It appears that c3p0 logging defaults to DEBUG. That can result in a lot of noise.
By adding a line like this to log4j.properties, you are telling the logger not to bother you with c3p0 messages - unless it's something important:
log4j.logger.com.mchange.v2=WARN
Do you not want to see any c3p0 logging?
If so try:
Logger.getLogger("com.mchange.v2.c3p0").setLevel(Level.WARNING);
OR, if you don't even want to see the first line of the log:
Logger.getLogger("com.mchange.v2").setLevel(Level.WARNING);
This is probably really late, but according to the c3p0 project website it is possible to configure the logging inside the mchange-log.properties so that you can capture the information using slf4j or log4j (and thus also with Logback).
The link http://www.mchange.com/projects/c3p0/#configuring_logging provides this information that in your mchange-log.properties file set the property com.mchange.v2.log.MLog to equal com.mchange.v2.log.slf4j.Slf4jMLog then in your logback.xml you can provide a logger like this:
<logger name="com.mchange" level="warn" additivity="false">
<appender-ref ref="c3p0-log" />
</logger>
Note: you will need to create a logback appender called c3p0-log before you can use this exact piece of code.
create a file called log4j.properties in your root classpath
set the following in there,
# Configure the name of the file for the LOGGER appender
log4j.appender.LOGGER=org.apache.log4j.ConsoleAppender
log4j.appender.LOGGER.layout=org.apache.log4j.PatternLayout
log4j.appender.LOGGER.layout.ConversionPattern=%d{MM-dd#HH:mm:ss} %-5p (%13F:%L) %3x - %m%n
log4j.appender.LOGGER.append=false
# this line logs everything from hibernate package at info level, you can refine this to include only some pachages like log4j.logger.org.hibernate.hql etc.,
log4j.logger.org.hibernate=INFO, LOGGER
log4j.logger.org.jboss.cache=INFO, LOGGER
this is a much better way of implementing the logging because if you set the logging strategy programmatically, then the config sometimes might not take effect at all (like in your case).. if you use the log4j.properties file ,the config is applied at application startup & everything works smoothly.
This only happens on older c3p0 version. So it might also be worth checking if you can just update to a newer version.