Please correct me if I'm wrong, but it seems the log4j2.xml must be in the classpath of the program, and everything in the classpath gets packaged up into a .jar file when you make a standalone runnable .jar file of the program.
If that's the case, then the XML file cannot be changed after the program has been exported to the .jar file. Thus, it doesn't seem that there is any way to change the logging level without re-exporting the program.
Please tell me I'm wrong about this and that there is a way that I can change the logging level while the program is running by using, say, a drop-down list in JFrame so that the user can select the logging level.
You can change the logger level by using the Java Management Extensions Bean (JMX Bean) included in the library:
Enable the JMX port in your application start up:
-Dcom.sun.management.jmxremote.port=[port_num]
Use any of the available JMX clients (the JVM provides one in JAVA_HOME/bin/jconsole.exe) while executing your application.
In JConsole look for the "org.apache.logging.log4j2.Loggers" bean
Change the level of your logger
The thing that I like most of this is that you don´t have to modify your code or configuration for managing this. It´s all external and transparent.
More info:
http://logging.apache.org/log4j/2.x/manual/jmx.html
I've used this in the past
LogManager.getRootLogger().setLevel(Level.DEBUG);
You can change to any of the log levels that way.
Related
Our application is deployed in websphere and uses lots of custom jvm properties.
Right now we are adding the properties one by one through admin console.
This is a pain during development phase.
Because every day after syncing their code, each and every developer needs to find out if a new property has been added/renamed and do those changes in their own console. Else the application wont start.
It also takes a lot of application setup time, while deploying to various testing environments.
Could you help me identify the place where websphere stores these custom properties? We are thinking of writing a code to update that file (?) directly instead of adding one by one through admin console.
Please help.
P.S:- We are not allowed to use jython in our local :(
In the server.xml configuration for that given server, located somewhere like
Dmgr/config/cells/cellName/nodes/nodeName/servers/server1/server.xml
You can inspect the <processDefinitions> element and add a "systemProperties" stanza like:
<systemProperties xmi:id="Property_1460665921900" name="someName" value="someValue" required="false"/>
DO THIS AT YOUR OWN RISK. The "Property_1112223334445" part is fragile, and you need to make sure it has a unique 13-digit number at the end.
Or, you can modify the "genericJvmArguments" tag in the same file, using a format more like -DsomeName=someValue
Finally, if you do have jacl scripting access, there is an article on updating using scripting here.
I'm getting an error in my program about a class not being found. I have double (and triple) checked and the class is definitely in my jar - it's finding other classes from the same jar just fine.
To help with debugging this, I want to turn on verbose class loading logging as described here:
http://java.dzone.com/articles/how-use-verbose-options-java
That doesn't say how exactly to turn on this option if you're using WebSphere Liberty Profile, though, so I looked around some more and found this:
http://www-01.ibm.com/support/knowledgecenter/SSD28V_8.5.5/com.ibm.websphere.wlp.doc/ae/twlp_admin_customvars.html
This says that I need to place the line in ${server.config.dir}/jvm.options.
So I wrote a simple file which consists only of:
-verbose:class
And I saved that to wlp/usr/servers/defaultServer/jvm.options, which means the new file is in the same directory as my apps folder, my logs folder, and my server.xml.
I stopped my server and started it back up and looked in the logs directory. It generated the same logs as always, nothing new: console.log, messages.log, status.log, and trace.log. I checked all of these log files and none of them have anything like the output from my first link.
So I don't think I'm doing this properly. Here are the three points where I think I may have gone wrong:
Was my file too simple? Is there more that I need to put in it than just -verbose:class? Does that perhaps need to be nested in something? Are there more parameters that I must have? Prior to this I didn't have any jvm.options file at all, so I assume that it'll use default values for anything I'm not explicit about.
Did I put the file in the proper place? As far as I can tell from the documentation, I think I put it in the proper spot, but the docs are a bit less explicit than I would like.
Am I looking in the right place for the logs? What will the name of the log file be? Where will it be placed? I assumed it would be in the logs directory just like all of the other logs generated by WebSphere Liberty Profile, but maybe I'm incorrect?
While writing the third bullet for my question, I realized that console.log was actually a new file that didn't previously exist, and I hadn't actually checked what was in it. I just opened it up and lo and behold, it's exactly the class loading logs that I was looking for.
So to recap, here are the answers to my bullets:
You can have a file with nothing but -verbose:class
You save it to wlp/usr/servers/<server name>/jvm.options
The output is in wlp/usr/servers/<server name>/logs/console.log
I wrote a simple Java app which I have placed in the start up folder of my programs which makes the program starts when the computer starts up. what is the easiest way to make it open a command line or something which I can see the System.out.println results instead of just running in the background?
You should familiarize yourself with logging frameworks such as logback and log4j. Instead of using System.out.println you use some special API and the logging library redirects all messages to preconfigured appenders like console or file.
In your case you can configure your application to log on console while developing and switch to file when configuring an application to run from startup.
This won't really open a new command line window on startup, but instead it will store all messages to some predefined file on disk - which is actually even better.
You can use Log4j API for logging the details with the predefined outputs. It is far better then using SOP. Because it is light waighted and also very simple to configure the logs in the other files with the output format whichever you want to make.
http://logging.apache.org/log4j/1.2/ Go to this url where you can find log4j api available.
Hope this work for you
Enjoy !!!
May be it is simpler than I think but I am confused on the following:
I want to be able to present to a user (in a graphical interface) the logs produced by Log4j.
I could just read the files as it is and present it, but I was wondering if there is a standard way to do it to so as to also get any updates that happen at the same time from the other parts of the application that log concurrently.
The log4j files could be multiple i.e. rolling appender
Also the presentation could be while there is no logging happening.
I.e. view of logs up to date
UPDATE:
I am constraint to Java 6
You can use Java 7's NIO2 libraries to get notified when one of multiple files get's modified in a directory, and reread & display it:
http://blogs.oracle.com/thejavatutorials/entry/watching_a_directory_for_changes
Have you tried the following tools :
Chainsaw
Xpolog
Perhaps add a database appender (JDBCAppender) and present the log entries from that?
Fro the official documentation of log4j:
Is there a way to get log4j to automatically reload a configuration file if it changes?
Yes. Both the DOMConfigurator and the PropertyConfigurator support automatic reloading
through the configureAndWatch method. See the API documentation for more details.
PropertyConfigurator#configureAndWatch
DOMConfigurator#configureAndWatch
For the on-demand reload of log4j config using GUI I would suggest expose it via a servlet in your J2EE application so that whole file can be edited in a web page (text area may be) and once saved you can overwrite your existing log4j file and reload the log4j config.
Maybe you could think about more "OS-level" solution.
I don't know if you are using win or linux, but on linux there is this realy nice command "tail".
So you could use ProcessBuilder to create OS process which goes something like "tail -f yourLogFile.txt".
And then read the OutputStream of the returned Process. Reading the stream will block waiting for new output from the process to be available, and will immediately unblock when such is available, giving you immediate feedback and possibility to read the latest changes of the log file.
However, you might have problems shutting this process down from Java.
You should be able to send SIGTERM signal to it if you know the process id. Or you could start a different process which could lookup the id of the "tail" process and kill it via "kill" command or something similar.
Also I am not sure if there is similar tool available on windows, if this is your platform.
If you write your own simple appender and have your application include that appender in your log4j configuration, your appender will be called whenever events are written to other appenders, and you can choose to display the event messages, timestamps, etc. in a UI.
Try XpoLog log4j/log4net connector. It parses the data automaticly and has predefined set of dashboards for it:
Follow the below steps
Download and install XpoLog from here
Add the log4j data using the log4j data connector from here and
deploy the log4j app here
As far as I can tell, it can write to console on production environment, it also can create log files on my local glassfish. Any thoughts on this issue? Thank you!
First of all, check if log4j is configured correctly. You won't get any log files if you didn't ask for them.
Second, as ckuetbach suggested, check if your paths have adequate permission. If you have problems of this kind, you should see log4j's error trace in Glassfish's log files. They won't halt your application, since logging systems are supposed to be non intrusive, but a trace should exist. And from it, you will know what (if anything) went wrong.
I think it may be the filepermissions or absolute Paths
in the log4j config.
Give this a try
Put log4j.xml in domains//lib/classes.
create and permission log folder as expected by log4j config e.g. ${com.sun.aas.instanceRoot}/applogs/myapplication.log