18:16:05,156 http-bio-8095-exec-9 WARN error in `Content.writeTo` for -template-plugin:soy-deps/soyutils.js ] .urlrewrite.UrlRewriteFilter INFO: loaded (conf ok) Whenever the application uses custom class loader then you will face the issue for sure, if using JCEKS keystore from older java versions than JDK 8 Update 151.18:15:49,041 localhost-startStop-1 INFO.
#DO I NEED JAVA 8 UPDATE 151 AND JAVA 9 UPDATE 181 CODE#
For example, for .MockClassLoader, the concrete solution is adding below annotation to involved test have done a complete analysis about the issue and debugged through the code part that involves in JCEKS keystore. Details depend on the ContextClassLoader. Solution: make sure class .SealedObjectForKeyProtector is not loaded by ContextClassLoader by certain configuration. ObjectInputFilter REJECTED: class .SealedObjectForKeyProtector Then, we will get below log and an IOException eventually: Thus below check in JceKeyStore.java:932 will fail due to class doesn't equal: 932 if (rialClass() != SealedObjectForKeyProtector.class)) On the other hand, within .JceKeyStore, unlike ObjectInputStream, SealedObjectForKeyProtector is always loaded by ExtClassLoader. However, once SealedObjectForKeyProtector is loaded by application's class loader, it's class loader no longer equals to ExtClassLoader. In ObjectInputStream, both class loader can load .SealedObjectForKeyProtector successfully, that's simply because ExtClassLoader is the parent of application's class loader (or, parent's parent).
Previously (before 8u171), this method returns $ExtClassLoader, while it returns application's classloader after upgrade. And per my troubleshooting, it is caused by the different return value of this method: .latestUserDefinedLoader() When we try to decompile it with JD-GUI, it fails with internal error, unlike the rest of the classes: The class SealedObjectForKeyProtector.class is somehow different from the rest of the classes in the sunjce_provider.jar. : .SealedObjectForKeyProtectorĪt .(BundleLoader.java:481)Īt .(BundleLoader.java:397)Īt .(BundleLoader.java:385)Īt .(DefaultClassLoader.java:87)Īt (ClassLoader.java:357)Īt 0(Native Method)Īt (Class.java:348)Īt java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:686)Īt java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1866)Īt java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1749)Īt java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2040)Īt java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1571)Īt java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)Īt .JceKeyStore.engineLoad(JceKeyStore.java:850)Īt (KeyStore.java:1445) This looks similar and they also have no solution: ATLAS-2642įor some reason, Equinox fails to see the .SealedObjectForKeyProtector class after the upgrade, even though it is clearly in the JRE that comes with the new JDK: BundleClassLoader.loadClass(.SealedObjectForKeyProtector) failed. It seems to me the JDK-8202506 issue is currently not fixed in any public JRE release. This looks very much like JDK-8202506 but I use Java 8 and I get null in the initial INFO message. This worked fine with earlier versions of the JRE: INFO: ObjectInputFilter REJECTED: null, array length: -1, nRefs: 1, depth: 1, bytes: 70, ex: n/aĬaused by: java.io.IOException: Invalid secret key formatĪt .JceKeyStore.engineLoad(JceKeyStore.java:856)Īt (Unknown Source) I am getting the following exception when I try to open JCEKS type key store with with Oracle Java 8 JRE 172 on Windows.
0 kommentar(er)
