[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [orbit-dev] Signing issues with commons.beanutils and commons.collections
|
This is an indication that the two jars are signed with different certificates AND that both jars are trying to contribute to the same package org.apache.commons.collections AND both jars are being loaded with the same class loader. The checkCerts code in the VM will not allow for such a discrepancy. This typically is not an issue when running in Equinox since we disable defining classes with code path that contains the certificates so the check is avoided, but here you are using the SecureClassLoader that tomcat uses and there is no way to disable the check there (that I am aware of).
The timestamp qualifier on org.apache.commons.collections_3.2.0.v201005080500.jar is from 2010. It is possible that the eclipse signing certificate has changed signing certificate has changed since then. Perhaps we just need to touch the org.apache.commons.collections in orbit CVS to get it to be resigned in the next build?
Tom
---03/15/2013 06:57:07 AM---Hi all, the Stardust project is using the org.apache.commons.beanutils_1.8.0.v201205091237.jar and o
From: <Sven.Rottstock@xxxxxxxxxxx>
To: <orbit-dev@xxxxxxxxxxx>,
Date: 03/15/2013 06:57 AM
Subject: [orbit-dev] Signing issues with commons.beanutils and commons.collections
Sent by: orbit-dev-bounces@xxxxxxxxxxx
Hi all,
the Stardust project is using the org.apache.commons.beanutils_1.8.0.v201205091237.jar and org.apache.commons.collections_3.2.0.v201005080500.jar bundles from the R20130118183705 Orbit repository. We’re deploying these bundles into a web archive which is published to a Tomcat server. Unfortunately we get the following exception during the runtime:
java.lang.SecurityException: class "org.apache.commons.collections.BeanMap"'s signer information does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:806)
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:487)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:625)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
If we remove the signing entries of the MANIFEST.MF files in both bundles the exception is no longer thrown.
Has anyone a clue how we can fix that? The only solution which comes into my mind is either to upload new bundles without signing entries or to fix the signing information.
Kind Regards,
Sven_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev