signer information does not match signer information of other classesin the same package

[albert kao]

I compile my Swing program with some third party jar files
successfully but running it has the following error in Eclipse 3.3.2,
JDK 6 & Windows XP.
However, I do not use any log statement in my program.
I cannot modfiy the third party jar files.
Please help.

Exception in thread "main" java.lang.ExceptionInInitializerError
at com.mycom.myprod.proj.client.swing.MyApp.main(MyApp.java:121)
Caused by: org.apache.commons.logging.LogConfigurationException:
java.lang.SecurityException: class "org.apache.commons.logging.Log"'s
signer information does not match signer information of other classes
in the same package (Caused by java.lang.SecurityException: class
"org.apache.commons.logging.Log"'s signer information does not match
signer information of other classes in the same package)
at org.apache.commons.logging.LogFactory$2.run(LogFactory.java:579)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:
517)
at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:
308)
at
com.mycom.myprod.proj2.swing.logging.LogFactoryHelper.getFactory(LogFactoryHelper.java:
88)
at
com.mycom.myprod.proj2.swing.logging.LogFactoryHelper.getFactory(LogFactoryHelper.java:
61)
at
com.mycom.myprod.proj2.swing.DesktopContext.<clinit>(DesktopContext.java:
287)
... 1 more
Caused by: java.lang.SecurityException: class
"org.apache.commons.logging.Log"'s signer information does not match
signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:775)
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:487)
at java.lang.ClassLoader.defineClass(ClassLoader.java:614)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:
124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.newInstance0(Class.java:326)
at java.lang.Class.newInstance(Class.java:308)
at org.apache.commons.logging.LogFactory$2.run(LogFactory.java:531)
... 7 more

 

[albert kao]

I compile my Swing program with some third party jar files
successfully but running it has the following error in Eclipse 3.3.2,
JDK 6 & Windows XP.
However, I do not use any log statement in my program.
I cannot modfiy the third party jar files.
Please help.

Exception in thread "main" java.lang.ExceptionInInitializerError
        at com.mycom.myprod.proj.client.swing.MyApp.main(MyApp.java:121)
Caused by: org.apache.commons.logging.LogConfigurationException:
java.lang.SecurityException: class "org.apache.commons.logging.Log"'s
signer information does not match signer information of other classes
in the same package (Caused by java.lang.SecurityException: class
"org.apache.commons.logging.Log"'s signer information does not match
signer information of other classes in the same package)
        at org.apache.commons.logging.LogFactory$2.run(LogFactory..java:579)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:
517)
        at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:
308)
        at
com.mycom.myprod.proj2.swing.logging.LogFactoryHelper.getFactory(LogFactory­Helper.java:
88)
        at
com.mycom.myprod.proj2.swing.logging.LogFactoryHelper.getFactory(LogFactory­Helper.java:
61)
        at
com.mycom.myprod.proj2.swing.DesktopContext.<clinit>(DesktopContext.java:
287)
        ... 1 more
Caused by: java.lang.SecurityException: class
"org.apache.commons.logging.Log"'s signer information does not match
signer information of other classes in the same package
        at java.lang.ClassLoader.checkCerts(ClassLoader.java:775)
        at java.lang.ClassLoader.preDefineClass(ClassLoader.java:487)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:614)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:
124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
        at java.lang.Class.getConstructor0(Class.java:2699)
        at java.lang.Class.newInstance0(Class.java:326)
        at java.lang.Class.newInstance(Class.java:308)
        at org.apache.commons.logging.LogFactory$2.run(LogFactory..java:531)
        ... 7 more

However, running my Swing program as a Java web start program on the
command line is ok: javaws http://localhost:7001/webstart/myapp/launch.jnlp

 

[Roedy Green]

However, I do not use any log statement in my program.
I cannot modfiy the third party jar files.

Obviously you CAN modify third party jars. There is nothing
technically stopping you. What you need is permission to do so. That
is a political problem. Perhaps that limitation can be bypassed if
you can't find another solution.

What you can do is open them the jars up and bundle them back into a
big jar that you sign.

I have heard it is possible to have different signers on different
jars if you use Java WebStart.

You might also explore the possibility of resigning an already signed
jar so that all jars have the same signer.

Another possibilty it so pre-install the needed jars in the client ext
dirs. You might write a little installer to do that. I think then it
does not matter how they are signed.

 

[Lew]

albert kao wrote, quoted or indirectly quoted someone who said :

Obviously you CAN modify third party jars. There is nothing
technically stopping you. What you need is permission to do so. That

But there is something technically shouting, "NO! Don't do that!"

On projects where they've done that, I've seen maintenance headaches. You end
up locked into old, often obsolete or unsupported versions of those
third-party JARs lest you lose your customizations. At best you become a
maintainer for someone else's product. This is expensive and in every case
I've seen so far, foolish and unnecessary.

is a political problem. Perhaps that limitation can be bypassed if
you can't find another solution.

It's a technical problem. It's a maintenance problem. It's a headache. Go
to nearly any length to avoid modifying other people's code for your project.

What you can do is open them the jars up and bundle them back into a
big jar that you sign.

In this limited scenario where you're only changing the signature the cost
might be somewhat less than when you actually change the content of the JAR,
but you still have to think. By signing the JAR yourself, you become the
certifier of its worthiness and safety. That's a lot of trust to put in the
third party, to assume responsibility for that assertion.

I have heard it is possible to have different signers on different
jars if you use Java WebStart.

WebStart seems like a solution to a lot of web-distribution matters.

You might also explore the possibility of resigning an already signed
jar so that all jars have the same signer.

Another possibilty it so pre-install the needed jars in the client ext
dirs. You might write a little installer to do that. I think then it
does not matter how they are signed.

Approaches that isolate you from responsibility for third-party products
should be considered first.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|

 

[Roedy Green]

On projects where they've done that, I've seen maintenance headaches. You end
up locked into old, often obsolete or unsupported versions of those
third-party JARs lest you lose your customizations. At best you become a
maintainer for someone else's product. This is expensive and in every case
I've seen so far, foolish and unnecessary.

On the other paw, you don't usually want people upgrading libraries
your code depends on without you testing them first.

If you repack it and resign it, that is like putting your stamp of
approval on the new library.

I guess it depends on just how paternalistic you are with your users
and how technically competent they are, and how much control you have
of their upgrades which way would work best.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Refactor early. If you procrastinate, you will have
even more code to adjust based on the faulty design.
..

 

[Roedy Green]

Approaches that isolate you from responsibility for third-party products
should be considered first.

We work in different worlds. My users are generally pretty
inexperienced. If I use a third party tool to solve a problem, that
is MY problem. It is like sub contracting. The end user deals
directly with me for all problems. I am responsible for bugs in the
third party product since I chose it. You need a corporate client
before you can play fingerpoint.


--
Roedy Green Canadian Mind Products
http://mindprod.com
Refactor early. If you procrastinate, you will have
even more code to adjust based on the faulty design.
..

 

[Lew]

On the other paw, you don't usually want people upgrading libraries
your code depends on without you testing them first.

If you repack it and resign it, that is like putting your stamp of
approval on the new library.

I guess it depends on just how paternalistic you are with your users
and how technically competent they are, and how much control you have
of their upgrades which way would work best.

This has nothing to do with users, but the development team alone, on the
projects I've seen. The users take a ZIP (JAR + libs), or a WAR, or an EAR,
with a specific app server for the latter two. They never change the libs.

The headaches of which I speak are caused the developers who take it upon
themselves to throw libraries or frameworks into a project willy-nilly.

I agree that you don't want people upgrading, adding, removing or otherwise
futzing with libraries without oversight, including testing. That is another
aspect of build maintenance, in addition to the headache of third-party
library customization. For the latter, it's usually better to write a wrapper
layer so you can avoid being a maintainer of another's lib.

 

[Lew]

We work in different worlds. My users are generally pretty

Users have no play in the issue that I described. It's strictly a
development-team matter.

inexperienced. If I use a third party tool to solve a problem, that
is MY problem. It is like sub contracting. The end user deals
directly with me for all problems. I am responsible for bugs in the
third party product since I chose it. You need a corporate client
before you can play fingerpoint.

No, you need only to be unwilling to keep up with all the versions of
third-party products that you've modified. Adapt, don't alter.

I didn't speak against use of a third-party lib, as you seem to imply. You
don't think I did that, do you?

I am hugely in favor of using libraries over reinventing them. That's part of
what motivated my advice not to alter them.