There is a check that the ClassLoader does when two or more classes in
the same package are defined with different CodeSource objects on the
same ClassLoader. The first class defined in a package for a given
ClassLoader decides what certificates ALL the other classes in that
package must be signed with. When run within Eclipse/OSGi by default the
bundle class loaders use CodeSource objects that do not contain the
certificates of the signers. So the ClassLoader check is short
circuited. In Equinox you can enable an option to to use CodeSources
that contain signing certificates (but this is disabled by default and
it has a rather expensive overhead). This is only an issue if one or
more fragments of a host contribute to the same package which exists in
the host or you have inner jar on the bundle class path that contribute
to the same package. In this case the host and all the fragment contents
are loaded with the same class loader (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=173673 and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=267150).
When running in a JavaSE environment (non-Equinox), if the two jars are
loaded with the same URLClassLoader then you will see this issue because
of the class loader cert check. The same URLClassLoader will be used if
the two jars are placed on the -classpath. I must say the requirement to
have the implementation of SDO be in the same package (commonj) seems
like an ill thought out design. I cannot think of another example where
an implementation of some API (or SPI) must be placed in the same
package as the actual API they are implementing.
Tom
Inactive hide details for David M Williams---05/21/2009 08:57:29
AM---Many mysteries ... and if you sign both there is no problDavid M
Williams---05/21/2009 08:57:29 AM---Many mysteries ... and if you sign
both there is no problem?! And it happens in Eclipse/OSGi and
non-Eclipse/OSGi environments?
From:
David M Williams/Raleigh/IBM@IBMUS
To:
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
Date:
05/21/2009 08:57 AM
Subject:
Re: [orbit-dev] Jar Signing and the Orbit Build
------------------------------------------------------------------------
Many mysteries ... and if you sign both there is no problem?! And it
happens in Eclipse/OSGi and non-Eclipse/OSGi environments?
And, yes, buddy-class loading would only help for OSGi/Eclipse
environments (but in non-Eclipse environment, usually direct
manipulation of the classpath would accomplish the same thing). Sounds
more complicated than that.
I'd have to study this some to understand it, and I'm hoping one of the
signing and OSGi experts will chime in before I have to study it :)
but let's plan that if not fixed/understood by next Tuesday, we add
'commonj.sdo.jar' to the "no sign" list. Please open an Orbit bugzilla
to remind me.
Perhaps there would be the best place to carry on the discussion. But,
one way or another, we'll get you running with next Orbit RC.
Sounds like you just might have stumbled upon a true technical reason
not to sign a jar. And, if so, I'm sure you'll work with the standards
body to get them to fix that broken part of their spec. :)
Thanks,
Inactive hide details for Tom Ware ---05/21/2009 09:19:47 AM---Hi David,
I, too, am surprised this is issue appears to be reTom Ware
---05/21/2009 09:19:47 AM---Hi David, I, too, am surprised this is issue
appears to be related to signing, but all
From:
Tom Ware <tom.ware@xxxxxxxxxx>
To:
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
Date:
05/21/2009 09:19 AM
Subject:
Re: [orbit-dev] Jar Signing and the Orbit Build
Sent by:
orbit-dev-bounces@xxxxxxxxxxx
------------------------------------------------------------------------
Hi David,
I, too, am surprised this is issue appears to be related to signing,
but all
the evidence points to the fact that it does.
In the scenario I mentioned below, if we either remove signing from the
commonj.sdo.jar or sign implementation.jar, the problem goes away. No
other
changes are required.
The issue only occurs outside of OSGi. The case that is failing for us
is a
pure Java SE set of JUnit tests. Additionally, SDO needs to work in a
variety
of cases including OSGi, various application servers, spring, and Java
SE. As a
result, whatever solution we come up with needs to be quite general. As a
result, I am not sure how buddy classloading can help.
I have not been able to find much documentation about what is supposed to
happen when packages are split between jars and one jar is signed and
the other
is not. The following post to the hibernate forum describes a similar
problem
where a combination of signed classes and unsigned classes fails when
packages
are split.
_
__https://forum.hibernate.org/viewtopic.php?t=946925&start=0_
<https://forum.hibernate.org/viewtopic.php?t=946925&start=0>
-Tom
David M Williams wrote:
>> The SDO specification requires that a class in commonj.sdo.jar
>> reflectively
>> instantiate a well known class from implementation.jar that is in the
> same
>> package as it. (i.e. commonj.Foo.class in commonj.sdo.jar must
> reflectively
>> instantiate commonj.Bar.class based on a well known name and
>> expected to be in
>> implementation.jar)
>
> I can't imagine how this is related to signing. Or are you saying the
> "fix" really is
> to modify commonj.sdo.jar dynamically? That doesn't sound good.
>
> If the issue is how to get 'implementation.jar' on the classpath of
> 'commonj.sdo.jar',
> without listing it in commonj.sdo.jar's manifest.mf, then the answer is
> likely to specify
> "buddy classloading". Have you tried that?
>
>
>
>
>
> From:
> Tom Ware <tom.ware@xxxxxxxxxx>
> To:
> Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
> Date:
> 05/20/2009 04:20 PM
> Subject:
> Re: [orbit-dev] Jar Signing and the Orbit Build
> Sent by:
> orbit-dev-bounces@xxxxxxxxxxx
>
>
>
> Hi David,
>
> Thanks for your response. We've been working on narrowing down the
> issue.
>
> Here is the problem:
>
> We start with 2 jars:
>
> 1. commonj.sdo_2.1.1.v200905011800.jar - SDO specification classes
> downloaded
> directly from Orbit and used unchanged (signed). I'll refer to this as
> commonj.sdo.jar from now on.
> 2. implementation.jar - any SDO implementation (not signed)
>
> The SDO specification requires that a class in commonj.sdo.jar
> reflectively
> instantiate a well known class from implementation.jar that is in the
same
>
> package as it. (i.e. commonj.Foo.class in commonj.sdo.jar must
> reflectively
> instantiate commonj.Bar.class based on a well known name and expected to
> be in
> implementation.jar)
>
> In our Java SE-based tests, this causes ClassNotFoundExceptions in
the
> scenario where commonj.sdo.jar is signed and implementation.jar is not
> signed.
>
> The issue does not exist in OSGi.
>
> I hope that I have missed some simple solution to this issue, but
if I
> have
> not, I think this means that the SDO specification is incompatible with
> having
> the spec-classes in a signed jar.
>
> -Tom
>
> David M Williams wrote:
>>> i.e. Do jars in Orbit have to be signed.
>> Yes. Well, " ... unless there is a technical reason not to ... ".
>>
>> And usually that technical reason would have to do with performance and
>> even then those performance problems can often be fixed ... judging
from
>
>> the Platform's early experiences. As a counter example, "the bundle has
> to
>> be modified after it is installed" would not be a good technical
reason.
>
>> What kind of problems are you having? Is there a bug number?
>>
>> A recurring issue, in the past, is that sometimes consumers have had
>> trouble because they "accidentally" condition the signed jars from
> Orbit,
>> or even innocently re-signed them, but I assume you've checked and
ruled
>
>> out those types of problems?
>>
>>
>> _______________________________________________
>> 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_
>
>
>
> _______________________________________________
> orbit-dev mailing list
> orbit-dev@xxxxxxxxxxx
> _https://dev.eclipse.org/mailman/listinfo/orbit-dev_
_______________________________________________
orbit-dev mailing list
orbit-dev@eclipse.org_
__https://dev.eclipse.org/mailman/listinfo/orbit-dev_
_______________________________________________
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