I have a requirements to enable the console logs for Dev and SIT instances but not in production.
Like if(ENV=SIT) do logging otherwise not
And this should be dynamic so if requires I can enable the console logs in production as well .
It's means I want to have a variable in log4j.xml .
I gone through different filters that that doesn't deal with environment.
Please help with sample.
You can use springProfile in log4j Profile-specific Configuration
about spring profile: Spring profile
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'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.
I'd like to be able to implement a configuration-less deployment for my java application (tomcat7, spring-mvc). For example, right now we are considering creating one context.xml file for each environment (prod, stage, dev) we deploy to:
context_prod.xml
context_stage.xml
context_dev.xml
context.xml (for localhost)
On each of our servers we would have a symlink context.xml which would point to the appropriate context file (e.g. context_prod.xml). So when we deploy, we don't have to worry about changing database references, keys, etc.
I feel like there's probably a better way to do this; perhaps one that is built into spring?
Spring has recently added the functionality to handle environment configuration:
http://blog.springsource.com/2011/02/11/spring-framework-3-1-m1-released/
This still seems a little bit complicated for me and I have done exactly what you are asking in my own Spring MVC applications for our logging. In my DispatcherServlet configuation I have this line:
<context:property-placeholder location="classpath*:/system.properties"/>
<util:properties id="mySystemProperties" location="classpath:/logging/log4j-${system.runMode}.properties" />
system.runMode is just an env variable that we created and is set in CATALINA.SH at startup like this: Setting environment variable TESSDATA_PREFIX in Tomcat
I then use Spring EL to reference any values I want and it works per environment. As you can see I did this for our logging and have a different logging configuration file per environment.
You could use Spring #Profile introduced in Spring 3.1. In your case you could use profiles like dev, stage, prod etc.
This profile value could be initialized run time. So when your application started, Spring could fetch appropriate profile based on configuration.
You could setup profile from environment variable, via deployment descriptor (web.xml) etc. This Spring source tutorial could be interesting for you.
I personally using Maven build to replace the profile value during build time in the web.xml. In the build time I passed profile value as build argument.
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/
I have a server I made in Java that needs to use a database, I chose HSQLDB.
So I have a lot of entries in my server like:
Logger.getLogger(getClass().getName()). severe or info ("Some important information");
When I run my server it goes to System.out which I think its the default configuration of java.util.logging?, so far its ok for me, and later I will make it go to a file ...
But, the problem is, when I start hsqldb it messes up with the default configuration and I can´t read my log entries on System.out anymore..
I already tried to change hsqldb.log_data=false, but it still messes up the default configuration.
Can someone help me??
I dont want to log hsqldb events, just my server ones.
Thanks
This issue was reported and fixed in the latest version 2.2.0 released today.
Basically, you set a system property hsqldb.reconfig_logging to the
string value false.
A system property is normally set with the -D option in the Java startup command for your application:
java -Dhsqldb.reconfig_logging=false ....
See below for details of the change:
http://sourceforge.net/tracker/?func=detail&aid=3195462&group_id=23316&atid=378131
In addition, when you use a fremework logger for your application, you should configure it directly to choose which levels of log to accept and which ones to ignore.
The hsqldb.applog setting does not affect framework logging and only controls the file log.
The hsqldb.log_data=false is for turning off internal data change logging and should not be used for normal databases. Its usage for bulk imports is explained in the Guide.
Try setting hsqldb.applog to 0, that shuts off application logging to the *.app.log file.
Start your server with a property pointing to the location of a dedicated properties file:
-Djava.util.logging.config.file=/location/of/your/hsqldblog.properties"
Which contains the following line to change Java logging for Hsqldb.
# Change hsqldb logging level
org.hsqldb.persist = WARNING
Side note, you can choose from the following levels:
SEVERE WARNING INFO CONFIG FINE FINER FINEST