[jboss-dev] Refactoring packaging/packages to reduce "signed jar groups"

David M. Lloyd david.lloyd at redhat.com
Thu Feb 25 12:17:37 EST 2010


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#defineClass%28java.lang.String,%20byte[],%20int,%20int,%20java.security.ProtectionDomain%29
>
> 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



More information about the jboss-development mailing list