I have two different log4j.properties files. One is for production and the other one is for sandbox. Normally, application uses log4j.properties. But for sandbox version (by using a condition) I want that application should use a properties file which is created by me and named as sandbox-log4j.properties. Only difference between them is a log tracking line is added to sandbox version.
How could I make a switch between two files by using a conditin in a java file?
I found the answer. #Michael's suggestion on JVM helped me to handle the problem. I use Elastic Beanstalk and its JVM options field on Configuration provided to separate log4j.properties files. Setting JVM options to -Dlog4j.configuration=sandbox-log4j.propertiesis enough for solution.
Related
is it possible to specify the logging level for java.util.logging using classpath? I don't want to use for that special file or create java class which overrides the default level.
My point is to say something like this -Djava.util.logging.level=ERROR
I can't find it in documentation, but maybe there are some tricks for that.
No, it is not possible. The Java Logging API can be configured either with a configuration class java.util.logging.config.class or with a configuration file. A default logging configuration file is located at "lib/logging.properties", inside the JRE directory.You could change this configuration file (which is not the best idea as it will be used for all the programs running in this JRE) or
you could set a separate configuration file for your application and set JVM property java.util.logging.config.file to point to this file
-Djava.util.logging.config.file=/tmp/logging.properties
See this tutorial for more details on Java Logging configuration.
We'd like to configure ESAPI property files directory, in JBOSS WildFly
(What usually done by VM argument: -Dorg.owasp.esapi.resources="/path/to/.esapi")
but prefer to do so in OTHER way, to suppurt diffrent property configuration for diffrent projects
does someone know how to do so?
Thaks!
There's really only two methods for loading these files, neither of them care about the application server you use. The first method, as you suggested is to supply the path via JVM properties.
The second method is via the classpath. I've never worked in JBOSS, but in Weblogic there's a config menu where you can place files on the classpath directly. In your case, it sounds like you want a different properties file for multiple applications? A JVM property or a similar classpath edit to weblogic would be the only choices.
The final classpath method, which I'm only including to be complete, is to compile your own copy of the library with your properties files in src/main/resources. Or--really hacky--crack open the jar file and dump them in by hand. The benefit of the "compile yourself" approach is that you'll have all the unpublished bugfixes, so if another CWE gets assigned to it you don't have to wait for the official release.
I am running Websphere Liberty 8.5. My application reads some files from the file system that are obtained via the Java CLASSPATH and I can't seem to find a way to append a directory from the file system to the CLASSPATH Liberty reads from. I've tried manually changing JAVA_CMD and JAVA_DEBUG but none of them take.
Does anyone know how this is possible?
It is not possible to modify the JVM application classpath (normally specified via the -classpath JVM argument or the CLASSPATH environment variable). I would recommend using a <library> to give your applications visibility to the resources. If you need a directory, you should use <library><folder dir="..."/></library>.
(As an aside, modifying the wlp/bin scripts or setting those "internal" script variables is not a supported external.)
ANOTHER WARNING! It only reads JAR files! I had the same issue with endless frustration. Even if you use the <library><folder dir="..."/></library> method above, it will only read jar files from the classpath. I had a bunch of properties files that I read from the classpath in JBOSS, WebSphere (full), and Glassfish, but the same method doesn't work for Websphere Liberty. What I ended up doing is the above, and putting my properties files all in a .jar file. Very annoying but a work-around, in case you need to read non-jar files.
What is the best way to configure log4j for a console application purely in Java.Where exactly we need to place log4j.xml ?
For automatic configuration the log4j configuration file should be on the root of the classpath, e.g. packaged in your .jar on the top level.
There is also a environment variable to specify the location -Dlog4j.configuration=.... This answer may help you further.
If your application is exclusively used standalone, putting the config inside the .jar should be ok. But note, that this causes trouble and hard to find misconfigurations if that .jar is used in context of another application, e.g. a web application. I would suggest to distribute the console application as a bundle with a starting script and the log config outside the .jar.
Observed a rather strange behaviour from apache log4j and thought sharing to get your thoughts.
I have an application which I'm running using an script. So far nothing special about that.
But the CLASSPATH I'm setting using that script, say a directory /home/myName/, have two different log4j properties files. One is simply log4j.properties and other is log4jXYZ.prperties.
The strange thing is when I run this script from different directories, one or the other log4j properties file is being picked-up. My understanding was it should have picked log4j.properties, obviously irrespectively from whereever I run the script.
Do you see some logic which can make a sense of it. Currently I'm at loss.
What I can predict is that log4j is trying any file matching lo4j*.properties expression.I must admit I haven't read all the manual assisting log4j.
Add log4j.debug property, when you run the application (-Dlog4j.debug= for the java command), it should show you the path where it loads the config file from.
I suspect it may load a file with same name from another directory than you think.