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

[David M Williams <david_williams@xxxxxxxxxx>]

>    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