On 02/25/2010 09:12 AM, Adrian Brock wrote:
On Thu, 2010-02-25 at 08:44 -0600, Mike Clark wrote:
> Hey Adrian,
>
> From reading the links you provided, it doesn't seem to be a sealed
> package thing. Indeed, we do not seal the jars. The error is, for example:
>
> 2010-02-25 08:36:00,621 WARN
> [org.jboss.detailed.classloader.ClassLoaderManager] (main) Unexpected
> error during load of:org.jboss.naming.NamingService
> java.lang.SecurityException: class "org.jboss.naming.NamingService"'s
> signer information does not match signer information of other classes in
> the same package
> at java.lang.ClassLoader.checkCerts(ClassLoader.java:776)
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:488)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
Right, ok. I didn't know this check existed. The only place it seems
to be mentioned is in the javadoc? See the throws SecurtiyException.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ClassLoader.html#define...
One possible workaround solution would be to allow you to somehow
specify that the unsigned jar should create its own local package.
i.e. instead of searching the ClassLoaderDomain for the existing package
you just create one locally.
Out of curiosity, is there a reason we don't do this already (i.e. a javaee
spec or something)? I'd think that by default each JAR should have a
separate package space, but I guess there could be exceptions in certain cases.
- DML