I'm facing a strange exception in my Java Web Start application.
It verifies at application start during the loading, then the application crashes with this exception: IllegalStateException: zip file closed.
It doesn't happen in all computer Clients, but I think it doesn't depend on the Java version because I've tried lots of different versions in different O.S..
Also, it doesn't happen at every program execution, only occasionally.
Do you have any ideas of what can cause this?
I used Java Mission Control tool and investigated.
I found some NoSuchMethodError when the application starts. Maybe those Errors could be the problem ?
Related
We have a Spring Boot (v2) powered JavaFX application (v8). More user run it on Windows, from a network share, at the same time (with a batch inside java -jar command). Jar is created by Spring Boot Gradle plugin and runs on Oracle JRE 1.8.
It run properly for months but nowadays sometimes fails to start with error message Error: invalid or corrupted jar file. (Manifest file is correct.) It usually happens when:
A user locked its PC when the application runs. After another user logs in and tries to start the same jar. This happens only on that PC which runs the jar within the locked user session. It happened on multiple machine not on only one.
And we got a bug report: application threw a NoClassDefFoundError but the class is inside the jar. I think these errors have relation.
We release periodically after one or two weeks and the bug is occured in multiple versions.
I dug a lot to find a solution or a detailed description of this error, but I found nothing.
Do you have any idea?
P.S.: We use this code snippet to determine which version of jar is running:
String manifestPath = classPath.substring(0, classPath.indexOf("!") + 1) +
"/META-INF/MANIFEST.MF";
Manifest manifest;
manifest = new Manifest(new URL(manifestPath).openStream());
return "v" + manifest.getMainAttributes().getValue("Manifest-Version");
We started to use this code near the bug is reported. It runs only on startup. I see stream is not closed manually or a try-with-resource block. Can it cause this behavior? I think not because GC will dispose the stream with an undetermined delay and between two application startup is more hours are estimated. And it is not associated with the NoClassDefFoundError.
It is not running reliably, because this is a very un-safe and un-reliable way to run an application. Executable code should be locally on the machine executing it.
So if it has to be on a network drive for some reason then it should be copied to the server it is going to execute it and then executed there.
Since it almost sounds like you are doing some sort of build process here it would be a much better idea to use an actual build tool like Jenkins to do this.
On the log list of issues that can happen executing from a network share:
o More than one user could try executing it at the same time causing conflicts.
o Which ever file sharing protocol could be locking the file(s) while one looking at the file or has it selected in their network viewer
o Different users with different permissions will get different behaviors. If it is trying to look on the drive or config files, or write a log file(s), etc. some users permissions on that file share may not Have the needed access.
o Network file shares are inherently un-reliable causing the file to not be accessible randomly, or to be reported as corrupted randomly.
o Different users on different machines with different versions of the networking protocols will get different behaviors.
o Different share protocols handle the data integrity checking differently and will cause different results.
And this could keep going for quite a while. You get the idea.
Can anyone tell me if Websphere does anything differently in terms of class loading when a profile is restarted as opposed to then an application within that profile is restarted?
I'm dealing with a large scale enterprise application compiled against Java 8 that has 250+ third party JAR files in its \WEB-INF\lib folder and am experiencing different behaviour on Websphere 9.0.0.2 (Build Number: cf021645.01 Build Date: 11/8/16) in that everything works fine with the application when I restart the profile but it breaks with what appear to be class loading related errors deep down in third party JAR code whenever the application itself is subsequently restarted.
I have looked at the class loader viewer, turned on verbose class loading and configured a diagnostic trace and everything appears to me to be being loaded correctly. I have two instances of the same application deployed in different profiles using the same version of Websphere and the behaviour is consistent between both, restart the profile and the application is all good but then restart the application and things go bad.
We have only recently started to deploy our application on WebSphere 9, prior to that we were deploying a version of it that was compiled against Java 6 to Websphere 7 without any issues. Some of the third party JARs being used are quite old as our dependency management (or lack thereof) is in need of some work but at this stage I am reluctant to commence what could turn out to be a significant task of updating libraries when the application works fine in one case but not another.
More info added:
Below is an example of the type of error I get following an application restart. In this particular instance I'm running some of our application code that reads a Word document from the file system and passes it to a third party PDF generation library so the execution goes from our local code into the PDF generation library then into the imageio. I don't always get the same error, it sometimes fails at a different point following another application restart (making it further down into the imageio code) but imageio always seems to lead to the problem.
Caused by: java.lang.NoClassDefFoundError: it/geosolutions/imageio/plugins/arcgrid/raster/AsciiGridRaster$AsciiGridRasterType
at it.geosolutions.imageio.plugins.arcgrid.spi.AsciiGridsImageReaderSpi.canDecodeInput(AsciiGridsImageReaderSpi.java:216)
at javax.imageio.ImageIO$CanDecodeInputFilter.filter(ImageIO.java:578)
at javax.imageio.spi.FilterIterator.advance(ServiceRegistry.java:832)
at javax.imageio.spi.FilterIterator.(ServiceRegistry.java:826)
at javax.imageio.spi.ServiceRegistry.getServiceProviders(ServiceRegistry.java:527)
at javax.imageio.ImageIO.getImageReaders(ImageIO.java:657)
at javax.imageio.ImageIO.read(ImageIO.java:1449)
at javax.imageio.ImageIO.read(ImageIO.java:1363)
From what I can see we don't appear to be using any shared libraries at all.
I did stumble upon this question on here during earlier investigations into my issue Not able to load javax.imageio.ImageIO class in WAS 8.5 and I can confirm we are already doing point 1 (explicitly calling ImageIO.scanForPlugins(), we do it as part of a servlet that executes on our application start up) and I have also configured point 2 (disable the class loader leak prevention in the server with a system property com.ibm.ws.runtime.component.disableMemoryLeakService=true) in attempts to diagnose my problem. I haven't tried point 3 though as it seemed to me to be a bit of a last resort.
With regard to imageio we have the following JARs being deployed as part of the 250+ within our application:
jai_codec
jai_imageio
jai_core
imageio-ext-arcgrid-1.1.10
imageio-ext-streams-1.1.10
imageio-ext-utilities-1.1.10
I'm unsure of the exact versions of the jai JARs but will endeavour to find out.
We also deploy a whole bunch of geotools JARs as well and sometimes it fails down in those following execution through imageio. All of these geotools JARs are version 2.4.0 which I know is quite old and I'm not sure how backward compatible they are running on Java 8 now. They worked fine for us on Websphere 7 Java 6 even though I think geotools 2.4.0 was aligned with Java 1.4. Again I'm reluctant to start updating libraries when the application works fine in one case but not another.
I am downloading a java web start app from the web, and using the jnlp file to run it in my MAC OS. But the application does not start and gives me the following error.
Now, I have read a lot about this error here and how to sign the application here and other places. Plus I have read about the security update which started this error here.
All these articles and answers give the impression that this error can only occur due to the application being from an unidentified developer.
I just wanted to confirm whether that is the case, or can there be some other reason behind this, like expired code signing cert, or a self signed cert?
If there can be multiple reasons for this error, how to find out which one it is?
I'm working on some code that is acting strange. The code is using the Java reflection property, loading the method name from a JSON file. Works perfectly in Linux, yet, importing and running the same code in the same IDE, with the code running in the same version and profile of a Websphere Application server setup, they are both using the same source files through a file server mount. Other parts of the application manipulate these files without a problem in both environments. Yet, somehow in Windows, it is unable to load the method from the file while Linux can. Stepping through the debugger in Windows I find that the null pointer error occurs at the time of trying to dynamically load the method, while stepping through the code in Linux in the same manner it simply proceeds where Windows gets stuck without issues. I'm getting this null pointer error from the application pointing to a method that does not exist due to the failure to load:
java.lang.NullPointerException
at com.mpi.factory.ToolStateFactory.getToolStateExtended(ToolStateFactory.java:19)
at com.mpi.factory.ToolStateFactory.getToolStateExtended(ToolStateFactory.java:33)
at com.mpi.factory.ToolStateFactory.getToolStateExtended(ToolStateFactory.java:41)
Given that the JRE is supposed to be portable and it shouldn't matter in what environment it runs, I suspect it's related to the OS. Has anyone experienced this issue before? I'm wondering if it's something that needs to be addressed at the OS level, or Java security settings? I know Windows is a bit more glitchy when it comes to drive mounts than Linux. I'm wondering if it's an obvious, well known issue with J2EE projects trying to use reflection in Java. I really don't think this has to do with the Webpshere, or project settings (Classpath, Deployment Descriptor, etc) since they are identical in both environments. Can't really find anything online about this quirk.
I have a Java application ready to be deployed. I tried using Java Web Start (JWS) to launch my application. My application was able to launch it loads the MainFrame but some of the functionality does not work. For example my search button (which creates a new thread to search information over the internet) is not working and several other buttons. My application works perfectly as intended when I run it using the typical java -jar or by double-clicking the JAR file. Do you have any ideas why did it happen? Or am I using a wrong technology for deployment? When I read about JWS the thing that I really like is the auto-updating of the application when new versions are released for the app. I really want this feature for future updates.
Solved:
I wasn't aware of the of Web Start Console. My problem is solved now as I was able to see the stack trace. It has something to do with permissions and my JAR file being unsigned.