Re: [orbit-dev] Jar Signing and the Orbit Build

[David M Williams <david_williams@xxxxxxxxxx>]

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,



Tom 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

-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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev