Thanks again for your help.
I’ve created a ticket for this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=403486
Regards,
Sven
Von: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Thomas Watson
Gesendet: Freitag, 15. März 2013 16:11
An: Orbit Developer discussion
Betreff: Re: [orbit-dev] Signing issues with commons.beanutils and commons.collections
Sven,
Yes a bug should be opened against Orbit I think.
Tom
---03/15/2013
08:56:30 AM---Hi Tom, many thanks for your really fast response. According to
https://bugs.eclipse.org/bugs/show_b
From:
<Sven.Rottstock@xxxxxxxxxxx>
To:
<orbit-dev@xxxxxxxxxxx>,
Date:
03/15/2013 08:56 AM
Subject:
Re: [orbit-dev] Signing issues with commons.beanutils and commons.collections
Sent by:
orbit-dev-bounces@xxxxxxxxxxx
Hi Tom,
many thanks for your really fast response. According to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=362445 it
seems that the certificate was changed in the first quarter of 2012. This substantiated your statement. Should I create a Bugzilla ticket for Orbit/bundles?
Regards,
Sven
Von: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Thomas Watson
Gesendet: Freitag, 15. März 2013 13:29
An: Orbit Developer discussion
Betreff: 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_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
