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
Related
See here for original question.
I'm writing a Java service, using Jetty for Webserving and SQLite for database storage. Source is available here.
I found that, although the service ran stably from my laptop, when deployed to an EC2 instance it would crash with no obvious error message in output somewhere between 1 hour and 2 days from starting up. I added some logging options to the startup call (-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=...), and got this crashlog.
This is the first time I've encountered such a file, and at first glance it doesn't seem very obvious which part of it refers to the actual error and which parts are just giving contextual information, so I'd really appreciate any good guides to understanding it. In particular, it looks like it's trying to interact with ZipFiles, which I don't use in my project.
This answer links to a blog which was -1'd in the answer comments
This answer links to some Oracle documentation, which I would normally be overjoyed at, but it appears to be a general debugging guide - can't see anything in there about hs_err files (though that may become clear on further reading)
This result from Google claims that "whatever Java code you execute, JVM should never crash. If it does, it is just a JVM bug. So try to log a defect with Sun with all details and hopefully they will look into that.", which sounds pretty absolutist - I think it's highly unlikely that my little toy project has uncovered a JVM bug!
Crashes in Java_java_util_zip_ZipFile_getEntry are most often caused by concurrent access to .zip files, e.g. a file is overwritten while an open instance exists.
See JDK-8042197, JDK-8031691 for details.
BTW, as to original question, here is a presentation on JVM crash dump analysis.
Looking at the crashlog, it appears that something you were unpacking (jar file or zip file) resulted in a JVM crash.
If this occurs during startup, try adding this to your JVM command line to see which file it was possibly working on.
java -verbose:class [more command line]
In a java application that uses logback, and runs under Windows 7, the sysinternals process monitor (www.sysinternals.com) shows that the java process is READING the application's log file. Why would this be?
Our app is having issues and logback came under scrutiny when this was discovered. We have since found that this is irrelevant to our issues, but I would still like to understand it.
I had thought that an appender would only append to the end of the log file as its name implies and am surprised and embarrassed to see this, especially after I insisted it couldn't be possibly be true.
Can someone explain why logback would need to READ a logfile? I can categorically state that none of the application's code reads the file.
Is there a way to change working dir for JVM when running Java Webstart?
When i use system.setProperties("user.dir", newDir) it sets it(system.getProperties() shows it does) but ignores it.
Is this a limitation in Java Webstart to always use the working dir where i started the jnlp file?
I am using all permissions in the jnlp file.
Please help!
EDIT: Whatever i do now, my webstart always uses user.dir to save files. Frustrating!
I've had this question in the past myself, but I've always found that, in the end, I didn't need it. Why do I say this?
Because your java web start app is not like an executable run from Program Files. It doesn't even exist on your computer like most programs (it is broken up into a bunch of different files and reassembled by the JVM). Therefore, you cannot say that the program has its own directory to do what it needs.
But it doesn't need to. Here's why:
Java has the Preferences API to help when you need to store data. The under-workings of the Preferences API is as mysterious as JWS, thus they are really a perfect fit. Either way, if you need to write things to a file, you should check this API to see if it can meet your needs.
If you need to write files for the user, then prompting them and allowing them to choose the location obviously means you won't use your current working directory to read/write files.
If you need to serialize objects, you should just create a program directory using the user.home resource as #AndrewThompson suggested. This will be "your" directory and is as good (in fact, better) than a directory in Program Files (if you're running on Windows, as an example).
In conclusion, in all cases (that I've come across), there's no need to change your current working directory. If you need your own folder, create one in user.home (because you won't run into file permissions issues there).
..all my settings file i use is created in the user.dir.
There is the mistake. Put them in a sub-directory of user.home & the problem is solved.
In the hypothesis you really really need to divert user.dir property for Java WebStart execution, here is the only option I have found: set this system environment variable (so system wide):
_JAVA_OPTIONS="-Duser.dir=C:\Temp"
But care about it, this option is read and applied to any JVM executions.
Why was it required in my context ? Because Java WebStart ClassLoader was looking for any single resource (class, properties...) in user profile before getting it from jar files in cache. As the user profile has been moved to a network storage, application start up became terribly slow. I am still investigating Java sources to understand (and avoid) this behavior. So my applications work perfectly without setting user.dir but that was the only work-around for the performance issue we got at the moment.
The recommended way to pass runtime parameters or user specific setting is through the jnlp argument
<application-desc main-class=".....">
<argument>user.home</argument>
..............
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
I have recently put together a JWS application which gets it's argument from a dynamically created JNLP file (details can be found here). It's all good except the application ignores the argument (starts without loading the specified number) on my system (linux x86_64). It seems however that the JWS application exactly as intended on the win_64 machine of a colleague of mine. This is rather interesting as I couldn't replicate his success on another similar win_64.
To make things more exciting, the same JWS application works just fine (in other words, doesn't ignore the argument) when I download the JNLP file and run it by javaws on the terminal.
I have compared the java.policy and javaws.policy files and there are no differences. The JNLP file clearly gives all-permissions, and the jar files are signed all fine (which can't be the source of the problem otherwise the application wouldn't start, right?).
Question 1: So what could this problem depend on?
EDIT: I just managed to get proper response from a new (in this particular sense) win32 machine, without any obvious java update. Question 2 : Is there a log file for javaws on which I can check what happens, or alternatively, can I verbose the launch to a console so I can create my own custom logs?
Edit 2: By the way, I have forgotten to mention that I have also posted this question at the Oracle forums, which I should have perhaps mentioned initially as it was politely pointed out there. Anyways, there is more information on the JNLP file there on the thread, in case it might be relevant.
Edit 3: I came to think that the problem could be originating from the properties of the <jnlp> tag, upon generating the JNLP file. Originally the jnlp tag looked like this like this:
<jnlp spec="1.0+" codebase="http://mydomain/myapp/"
href="my.jnlp">
The problem with this is the fact that there is no my.jnlp in the the directory declared in the codebase, instead the JNLP code is created on the fly by a Perl script in the cgi-bin directory and returned as an output stream (I think). So I edited the script to generate the JNLP with the following tag:
<jnlp spec="1.0+" codebase="http://mydomain/myapp/"
href="http://mydomain/cgi-bin/my.jnlp">
The result of this experiment: not even the GUI started this time...
I have found a relevant thread on Oracle forums, where it was advised to define the href property in the following fashion:
href="script.jsp?<%=request.getQueryString()%>">
which unfortunately doesn't solve my problem.
Question 3: Could this modification be applicable to my situation as well? In that case how? If not any insights on what might be causing the problem would be seriously appreciated as I am really at a stalemate on my work right now
After two weeks of wrestling with the JNLP file syntax and my CGI script, I think I finally found the crux of the problem. I am noting this down here (at the risk of looking pretentious enough to answer my own question) in case somebody else runs into the same problem.
The href property of the <jnlp> tag, in my case was apparently unnecessary and when removed the application started working as intended on both linux and win systems. I am not 100% sure if this is the exact reason but my understanding is that as the jnlp syntax is generated from a script and directly returned to the user instead of a jnlp file somewhere in the filesystem, the href property was pointing to a wrong place and perhaps caused some sort of a clash that is handled differently in different OS.
Make sure the JNLP file is not cached. I.e., each time you try something new, have you renamed / relocated the JNLP file?
Regarding your updates,
The only ting that comes to my mind is that you need to make sure that your script responds with the correct mime type: application/x-java-jnlp-file
That is, from your cgi-script, you have to provide the HTTP header field
Content-Type: application/x-java-jnlp-file