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.
e.g.
protected void definePackage(String className, URL codeSourceURL)
{
String packageName =
ClassLoaderUtils.getClassPackageName(className);
if (packageName.length() == 0)
return;
// Ask the policy for the information
PackageInformation pi =
policy.getClassPackageInformation(className, packageName);
// Already defined?
Package pkge = null;
if (policy.isSharePackage(packageName))
pkge = getPackage(packageName);
else
pkge = getPackageLocally(packageName);
if (pkge != null)
//etc.
Cheers,
Mike C.
--
xxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Redhat
xxxxxxxxxxxxxxxxxxxxx