Develop Reference

log4j2 in JNLP results Classnotfoundexception

we have an old desktop application which was running on log4j. this application gets deployed using JNLP on the users system and then is connecting to server at our end. we are in the process of upgrading the application to log4j2. we have upgraded the server side code and it works fine. for the JNLP side of code, though we have done all the changes and deployed the application properly we are ending up with an exception which we dont seem to find the cause off. any help here is appreciated..
the exception is as listed below..
java.lang.ClassNotFoundException: org.apache.log4j.Logger
at java.net.URLClassLoader.findClass(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.getConstructor(Unknown Source)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:429)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:525)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:272)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:246)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:395)
at com.abcxyz.core.log.Logger.<clinit>(Logger.java:150)
at com.abcxyz.core.log.DefaultLog4jHelper.<init>(DefaultLog4jHelper.java:91)
at com.abcxyz.core.log.DefaultLog4jHelper.initLogger(DefaultLog4jHelper.java:44)
at com.abcxyz.ui.main.CMS.<clinit>(CMS.java:115)
at com.abcxyz.ui.main.InitializeCMS.main(InitializeCMS.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
the exception point to a class file in the log4j-1.2.17.jar (our old jar). i am sure i dont have the old jar anywhere in the code or any part of the code referring the the old jarfile.
pasted below is the sysArgs section of the JNLP where i am referring to the new properties file

I am not familiar with JNLP, but according to your stacktrace, program cannot find. In Log4j2 package org.apache.log4j was changed to org.apache.logging.log4j. As a result it is not available.
One of easiest solutions in your case - to use Log4j 1.x bridge (Here is Migration guide)
If you want to use current version add to <argument> param to use log4j2 impl (by default it is uses org.apache.commons.logging.impl.LogFactoryImpl configured for log4j 1.x)
org.apache.commons.logging.LogFactory=org.apache.logging.log4j.jcl.LogFactoryImpl

we have found the solution. in our case there were two issues
the jar signing was not proper. the jars have manifest files under the meta-inf folder. the value of this folder was corrupted. we manually edited the file and preserved the original values for everything except the SHA keys and then resigned these jar.
in the log4j2-api jar there is a log4j-character.properties file which was getting corrupted while signing the jar using ant script. after the signing we replaced this file in the jar with the copy of the file saved from before the signing.
above to steps resolved our issue. i know what i wrote above might not make much sense to someone. happy to provide screen grabs in case on demand someone comes across this issue.

Java Web Start not working after updating Java 8u141 - java.lang.SecurityException: digest missing for org/apache/commons/httpclient

After updating Java 8u141, my java web start application, run by jnlp stopped working. Do not download the application. And throws these exceptions below. Can someone help me?
com.sun.deploy.net.JARSigningException: Could not verify resource signature: http://www.example.com/myjar.jar
at com.sun.deploy.security.JarVerifier.authenticateJarEntry(Unknown Source)
at com.sun.deploy.security.EnhancedJarVerifier.validate(Unknown Source)
at com.sun.deploy.cache.CacheEntry.processJar(Unknown Source)
at com.sun.deploy.cache.CacheEntry.access$2700(Unknown Source)
at com.sun.deploy.cache.CacheEntry$7.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Other:
java.lang.SecurityException: digest missing for org/apache/commons/httpclient
at sun.security.util.ManifestEntryVerifier.verify(Unknown Source)
at java.util.jar.JarVerifier.processEntry(Unknown Source)
at java.util.jar.JarVerifier.update(Unknown Source)
at java.util.jar.JarVerifier$VerifierStream.<init>(Unknown Source)
at java.util.jar.JarFile.getInputStream(Unknown Source)
at com.sun.deploy.security.JarVerifier.authenticateJarEntry(Unknown Source)
at com.sun.deploy.security.EnhancedJarVerifier.validate(Unknown Source)
at com.sun.deploy.cache.CacheEntry.processJar(Unknown Source)
at com.sun.deploy.cache.CacheEntry.access$2700(Unknown Source)
at com.sun.deploy.cache.CacheEntry$7.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

I managed to solve this same issue yesterday. This is what worked for me:
Use 7-Zip to open the original, unsigned jar which is throwing the JARSigningException. Probably a good idea to make a copy of the jar first in case anything goes wrong.
Open the META-INF folder and copy MANIFEST.MF somewhere to your PC.
Open the MANIFEST.MF copy in a text editor. Look for a line that says something like "Name: org/apache/commons/httpclient". There could be a few lines like this, depending on the jar. Below this line will probably be other lines like "Implementation-Vendor:...", "Specification-Title:...", etc. In any case, delete all "Name:..." lines and all the subsequent lines in each block.
Save the file, and replace the existing MANIFEST.MF in the jar with the edited version. 7-Zip allows files to be replaced inside jars in-situ.
Re-sign the jar and deploy.
It seems when jars get signed, the "Name:" lines in the manifest can wind up in the middle of the signed classes, which only now seems to be a problem with the release of Java 8u141 but were obviously fine before.

The issue is already fixed in 8u144, please upgrade to 8u144 to avoid this issue http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

I had the same problem with the commons-httpclient-3.1.jar library. Actually I believe it's a bug in the web start, as It worked before and it works with the 8u152 early access. The solution I described here!

The issue is observed in signed JAR files whose manifest contains package version information[1] and does not have a trailing "/" in the name of the package (e.g.: Name: org/apache/xml/resolver). While we work towards resolving this issue, in the interim, users can work-around the issue as follows:
NOTE: We recommend use of this workaround only if the distributor of the JAR files can "re-sign" the JAR files.
Extract the contents of the signed JAR file (e.g.: jar xf jar-file ).
Modify META-INF/MANIFEST.MF file and add a trailing “/” to the name of the package ( e.g.: Name: org/apache/xml/resolver/).
Remove the current signature files ( e.g.: rm -f META-INF/.SF META-INF/.RSA META-INF/*.DSA ).
Recreate the JAR file ( e,g.: jar cfm jar-file META-INF/MANIFEST.MF input-file(s) ).
NOTE: You must use the jar utility. Other jar creation tools might re-introduce the issue.
Re-sign the JAR file.
[1] https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html#wp91706
Source:
http://www.oracle.com/technetwork/java/javase/8u141-relnotes-3720385.html#KnownIssues

This bug is addressed as part of the bug JDK-8184993 and the fix will be available in an out-of-cycle release of JDK 8u144, which is scheduled to be released on later hours of July 26.

Where does SWT write dll files on windows?

I cannot find on the Internet where SWT tries to write the dll files. I have a computer where the jar does not run only because SWT cannot write DLLs.
UPDATE 1
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
no swt-win32-3738 in java.library.path
no swt-win32 in java.library.path
Can't load library: \\ubz01fst\Students\User2010\Com\xxx\swt-win32-3738.dll
Can't load library: \\ubz01fst\Students\User2010\Com\xxx\swt-win32.dll
at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
at org.eclipse.swt.internal.C.<clinit>(Unknown Source)
at org.eclipse.swt.widgets.Display.<clinit>(Unknown Source)
at install.Main.main(Main.java:162)

I find out the answer myself.
Since SWT 3.3 you don't have to include the native (DLL) library anymore, because they are in the jar itself and they are unpacked as soon as the SWT library is called.
The DLL files are unpacked from the jar and placed in the ".swt" folder under your "System.getProperty("user.home")".
In my case the problem was that System.getProperty("user.home") is set to "\ubz01fst\Students\User2010\Com\xxx" which is a UNC path and that is not writable ( this often happen in companies or organizations computers ).
I donno for which reason the System.getProperty("user.home") in computers is taken from the environment variable "HOMESHARE" of Windows
The solution consists in changing the System.getProperty("user.home") with a writable path, for example:
System.setProperty("user.home", System.getenv("USERPROFILE"));
before calling any SWT code.

Ok, I found the solution. The problem was about the dll generation. I was using 3.7m5 version, I downloaded a previous version (3.7) and the application ran properly.
Regards.

Java applet not loading with Java Plugin 1.6

I created an applet and added it to my JSP page. It was working fine in IE, Chrome when Java Plugin version was 1.5. Recently, I updated Java plugin to 1.6 and now the applet is not loading. The following error is displayed on the console.
load: class GraphApplet.class not found.
java.lang.ClassNotFoundException: GraphApplet.class
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: open HTTP connection failed:http://cwrug26999:8080/fluids/pages/GraphApplet/class.class
at sun.plugin2.applet.Applet2ClassLoader.getBytes(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.access$000(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
... 9 more
Exception: java.lang.ClassNotFoundException: GraphApplet.class
The GraphApplet.class is located in the same location where JSP page is located.
I used IE with Java 1.5 plugin and the applet is loading fine.
Can anyone point out what I am missing here.
The source code that I am using in the JSP file is below:
<br><center><applet code="GraphApplet.class" codebase="pages/" width="450" height="450">
</applet></center>
Sorry, the applet can not be accessed publicly.
I am using Tomcat5 as the web server and under webapps I have my project folder "fluids" and under this folder I have "pages" folder which contains the JSP files and the applet .class files.
Thanks

The URL http://cwrug26999:8080/fluids/pages/GraphApplet/class.class looks as if the plugin interpreted the code attribute as a class name, not a file name. Try using code=GraphApplet instead.
You could also try using the <embed> tag which isn't deprecated.

I found the issue, after lots of trial and errors it was related to Java Cache. I deleted the Java Cache by going to Control Panel->Java->Temporary Internet Folder->Delete Files...
I also changed the location where the cache files were stored and apparently, the default location was write-protected.
Phew...
Anyway, thanks for the replies

UnsatisfiedLinkError on Websphere Application Server 6.1 Data Source

I am unable to start the installed App on my WAS instance. I believe the root cause is an UnsatisfiedLinkError which is shown as follows:
Caused by: java.lang.UnsatisfiedLinkError: no ocijdbc10 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:993)
at oracle.jdbc.driver.T2CConnection$1.run(T2CConnection.java:3147)
at java.security.AccessController.doPrivileged(Native Method)
at oracle.jdbc.driver.T2CConnection.loadNativeLibrary(T2CConnection.java:3143)
at oracle.jdbc.driver.T2CConnection.logon(T2CConnection.java:221)
at oracle.jdbc.driver.PhysicalConnection.(PhysicalConnection.java:441)
at oracle.jdbc.driver.T2CConnection.(T2CConnection.java:132)
at oracle.jdbc.driver.T2CDriverExtension.getConnection(T2CDriverExtension.java:78)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:801)
at oracle.jdbc.pool.OracleDataSource.getPhysicalConnection(OracleDataSource.java:297)
at oracle.jdbc.xa.client.OracleXADataSource.getPooledConnection(OracleXADataSource.java:515)
at oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:159)
at oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:133)
at com.ibm.ws.rsadapter.spi.InternalGenericDataStoreHelper$1.run(InternalGenericDataStoreHelper.java:935)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.rsadapter.spi.InternalGenericDataStoreHelper.getPooledConnection(InternalGenericDataStoreHelper.java:972)
at com.ibm.ws.rsadapter.spi.WSRdbDataSource.getPooledConnection(WSRdbDataSource.java:1625)
at com.ibm.ws.rsadapter.spi.WSManagedConnectionFactoryImpl.createManagedConnection(WSManagedConnectionFactoryImpl.java:1220)
at com.ibm.ejs.j2c.FreePool.createManagedConnectionWithMCWrapper(FreePool.java:1988)
at com.ibm.ejs.j2c.FreePool.createOrWaitForConnection(FreePool.java:1660)
at com.ibm.ejs.j2c.PoolManager.reserve(PoolManager.java:2341)
at com.ibm.ejs.j2c.ConnectionManager.allocateMCWrapper(ConnectionManager.java:932)
at com.ibm.ejs.j2c.ConnectionManager.allocateConnection(ConnectionManager.java:608)
at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:449)
at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:418)
at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectionFromDataSource(Unknown Source)
at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.lookupConnection(Unknown Source)
at org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl.lookupConnection(Unknown Source)
at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection(Unknown Source)
at org.apache.ojb.broker.accesslayer.StatementManager.getPreparedStatement(Unknown Source)
at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown Source)
at org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(Unknown Source)
at org.apache.ojb.broker.accesslayer.RsIterator.(Unknown Source)
at org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(Unknown Source)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery(Unknown Source)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery(Unknown Source)
at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source)
at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source)
at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknown Source)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Unknown Source)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Unknown Source)
at com.ascential.xmeta.persistence.orm.impl.ojb.OjbPersistentEObjectPersistenceRegistry.loadPackageCache(OjbPersistentEObjectPersistenceRegistry.java:371)
... 115 more
My LD_LIBRARY_PATH variable for the 'was' user is /opt/oracle/product/10.2.0/lib
What else should I be checking to fix this error?
Please help.
Thanks

Verify that "Java Library Path" in the trace header of SystemOut.log contains "/opt/oracle/product/10.2.0/lib". If it does not contain the path, then your LD_LIBRARY_PATH setting is not taking effect (perhaps the variable isn't exported, or perhaps you're executing startServer as a different user).
Regardless, I would recommend setting adding "/opt/oracle/product/10.2.0/lib" to the native library path of the JDBC provider rather than trying to set it at the OS level.
Finally, double-check that the server has the proper OS permissions to access the native library.