I've inherited some java code that uses the JBoss Logging implementation explicitly. I know that this is normally configured as a JBoss Subsytem, and I'm able to observe various log tuning operations just fine when running on the server. However, I'm not getting any log message output for unit tests. I've dropped several configuration files on the test classpath to include:
logging.properties
log4j.xml
log4j2.xml
but have not seen any results. Has anyone been able to configure the JBoss Logging system such that they're visible outside of the container in unit tests? Is this even possible? The logging configuration guide didn't speak to how to do this.
You can make log4j.xml work, but you need to make sure that you have a compatible vanilla log4j version on the test classpath, e.g. 1.2.17, and that you don't have the modified version, log4j-jboss-logmanager, on the the classpath, which doesn't read log4j.xml.
Details.
See https://stackoverflow.com/a/18323126/1341535.
I take this:
I would recommend you configure the log manager using the logging
subsystem provided with the application server. This is the only way
to configure the server logging.
to imply that it's basically impossible to configure the JBoss Log Manager in tests, because there is no server subsystem configuration and nothing to parse it. Maybe you could configure it programmatically, but that's too inconvenient.
So this leaves us using the JBoss Logging facade with log4j for the log manager, which can be easily configured with log4j.xml.
Now, that I think of it, there is a logging.properties file in Wildfly, that configures logging before the logging subsystem is initialized. That means you can configure the JBoss Log Manager with logging.properties, you just need to put the relevant jars on the test classpath, probably jboss-logmanager and log4j-jboss-logmanager.
I will try to test the code using Arquillian Test Cases, it features the possibility to deploy parts of your code only to test it in a "real environment".
It is reccomended in a lot of RH JBoss documentation.
You can try reusing your junit code, and modify them using this guide: http://arquillian.org/guides/getting_started/
I'm not a guru of that technology. I hope it would help you.
Related
I'm running a web application in a Weblogic server (Im not realy familiar with ).
Via JVM args a log4j config is passed with log level DEBUG to the application.
In the log file I can also find some log entries of DEBUG level.
So far so good.
During debugging I found some calls to logger.debug() that are not in the log file.
private static final org.slf4j.Logger logger = LoggerFactory.getLogger(ActionCtr.class);
The method call is definitely hit but nothing is written to a file.
If I do a step into during debugging I see in the logger:
org.slf4j.impl.JDK14LoggerAdapter(com.example.application.ActionCtr)
"java.util.logging.FileHandler.pattern" -> "%h/java%u.log"
And this leads to some questions for me (as I can not change the running application):
1) how could it bee that it uses the application is using a mixed up log4j and java.util.logging
2) How could I determine what is used in what classes?
3) There is no %h/java%u.log (~/java*.log) so I've tried to provide a java.util.logging conform properties file,
but this changed nothing - how an I determine where the running logger got its config from to configure it right?
1) how could it be that it uses the application is using a mixed up log4j and java.util.logging
Any of those logging frameworks could be used by the application directly or a dependent library that the application is using. It doesn't take too many dependencies to end up with a bunch of logging framework hitchhikers.
The SLF4J manual explains how that logging framework wrangles all of these other frameworks. This why you are seeing the org.slf4j.impl.JDK14LoggerAdapter.
How could I determine what is used in what classes?
Assuming you mean direct usages you can use Jdeps or Javap.
how an I determine where the running logger got its config from to configure it right?
The JConsole tool can access the JUL loggers at runtime. It will also show you all of the system properties which may include paths to logging.properties files.
If the application is pragmatically configuring the logging in an non-standard way then one option would be to use the java.security.debug using the access option. Run the application under a security manager will all or all required permissions but then enable access tracing.
I'm trying to essentially configure logging in three places, independently. Ideally, each component that is logging is fully unaware of the others. I'd like to use logback for this, as it seems to have some decent features and performance.
Here are the places from which I would like to log from and to:
Tomcat (7) should log to ${catalina_home}/logs/catalina.out, and should only log Tomcat events (deployments, server startup, etc)
A web application hosted in Tomcat should log to ${catalina_home}/logs/application.log, and should only log application things, like results of request validations or errors
A library that is included in the web application should log to ${catalina_home}/logs/library.log, and should only log things specific to that library, like time it takes to interact with some other web-service or library-specific errors
I know this is probably not the way it would work, but I would think I need to have a logback.xml file for each concern. Actually, I have created them and added to the classpath such that I get a "logback.xml occurs multiple times on the classpath" error.
I can see why I would need to consolidat my application and my library logback configuration to a single logback.xml file, but how would I keep the container logging config separate from the application+library logging config? Adding a logback config file to my application, as well as logback enabling Tomcat as described here, still yields a "multiple logback.xml" error. And, Chapter 9 of the logback user manual, which talks about separation of logging, doesn't really show how to separate the container and applications (just multiple applications), unless I am missing something there.
I am writing standalone java application which is using Hibernate. Maven brought jboss-logging library for me. I am not using JBoss. The question is: can I log with this library only, or I need to download some logging implementation like log4j?
JBoss Logging is just a logging facade. To configure your loggers, e.g. use/add handlers, you need a log manager like JBoss Log Manager, the J.U.L. log manager, logback or log4j.
JBoss Logging will attempt to discover which log manager is being used. You can specify which log manager you'd like to use with the org.jboss.logging.provider system property. The allowed values for `org.jboss.logging.provider' are:
jboss - for JBoss Log Manager
jdk - For the J.U.L. log manager
log4j - For the log4j log manager
slf4j - For logback with slf4j
Hibernate uses JBoss Logging for it's i18n capabilities, it's vararg logging methods and the ability to not be tied to a log manager.
Of course you can absolutely use JBoss Logging in your project. If you want to configure logging handlers you'd also have to use a log manager as well.
afaik, jboss-logging is more a extra layer on top of normal logging api, to provide more sophisticated feature like i18n etc.
JBoss-logging can use other logging library (e.g. SLF4J) as the underlying handler for log.
I believe if you are writing a simple standalone Java app, you do not need to use JBoss-logging (unless you know you really want and need to do so).
Using SLF4J (with LogBack or Log4J binding) will be a good choice. Visit http://slf4j.org for more information
Make sure you have jboss-logging and your logger implementation in your classpath and set the system property org.jboss.logging.provider to log4j, jdk, slf4j or jboss depending on what you want. In theory autodetection may also work.
https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/org/jboss/logging/LoggerProviders.java#L29
I have a web application consisting of severals modules. All the modules are packaged together in one single ear.
One of them is a brand new groovy app, while others are more old school. This new grails app is not under my responsibility.
Notice that grails is not using any log4j.[properties|xml] file, but it as its own DSL which interact directly with log4j at runtime. This configuration is located inside a config.groovy script, packaged with the application.
Log4j is configured using an external file and the -Dlog4j.configuration option for the JVM.
The problem is the grail configuration is containing a very liberal config:
- set the root level to info
- add a console appender
The result is that the external configuration is hijacked by grails:
now there are two console appender (logging twice the same info) and lots of useless info data are logged.
Is there another solution than a programmatic approach, to tell grails to stop being rude ?
You could just turn off the grails logging so it uses the external logger
http://blog.saddey.net/2010/02/07/grails-how-to-use-native-server-logging-configuration-eg-tomcat-glassfish-jboss/
Enviroment: JSF 2.0, RichFaces 3.3.3, Facelets 1.1.15B1, Spring Framework 3.x, WebFlow 2.1, MyBatis 3.0.1, Oracle 10/11 g backend, SLF4j into Log4j. Well thats probably TMI since my issue is only a logging problem but better to be too thorough than not.
Anyways... I just setup SLF4j & log4j so now all of the internal facelets log msgs are being dumped into log4j & I can actually see them. In addition I setup Tomcat to also dump to log4j instead of it's custom version of JULI. Upon doing this everything appeared to be working great.... until i shut down the app.
Midway through the shutdown process my app started barfing up errors left 'n right because (which makes sense) Tomcat is trying to grab a logger instance AFTER spring has already cleaned up the logger bean.
Anyone familiar with this? I imagine it must be a common problem for anyone who has Tomcat using the non-standard logging mechanism. What is the best way around this?
I thought maybe if I just raised the log level then Tomcat wouldn't even try to log msgs because of the level req.s but the problem occurs when tomcat is trying to retrieve a logger instance so that didn't work.
I would move the Logger higher in the food chain.
I personally never configured log4j with spring relying on its own configuration mechanism (and hunting for where the heck it finds the properties file it is using in the process).
If you can you can opt to completely remove log4j from your war and rely on the log4j in the common tomcat library classpath. Then of course you are at the mercy of the tomcat configuration and you cannot access the log from inside your app, but it is always there during the complete lifecycle of your app.