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

Discussion in 'Java' started by albert kao, Feb 10, 2011.

  1. albert kao

    albert kao Guest

    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, Feb 10, 2011
    #1
    1. Advertising

  2. albert kao

    albert kao Guest

    Re: signer information does not match signer information of otherclasses in the same package

    On Feb 10, 11:05 am, albert kao <> wrote:
    > 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
     
    albert kao, Feb 10, 2011
    #2
    1. Advertising

  3. albert kao

    Roedy Green Guest

    Re: signer information does not match signer information of other classes in the same package

    On Thu, 10 Feb 2011 08:05:08 -0800 (PST), albert kao
    <> wrote, quoted or indirectly quoted someone who
    said :

    >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.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    Your top priority should be fixing bugs. If you carry on development,
    you are just creating more places you will have to search for them.
     
    Roedy Green, Feb 11, 2011
    #3
  4. albert kao

    Lew Guest

    Re: signer information does not match signer information of otherclasses in the same package

    albert kao wrote, quoted or indirectly quoted someone who said :
    >> However, I do not use any log statement in my program.
    >> I cannot modfiy the third party jar files.


    Roedy Green wrote:
    > 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|
    |_____|_____|
    |===========|
     
    Lew, Feb 11, 2011
    #4
  5. albert kao

    Roedy Green Guest

    Re: signer information does not match signer information of other classes in the same package

    On Fri, 11 Feb 2011 07:46:52 -0500, Lew <> wrote,
    quoted or indirectly quoted someone who said :

    >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, Feb 12, 2011
    #5
  6. albert kao

    Roedy Green Guest

    Re: signer information does not match signer information of other classes in the same package

    On Fri, 11 Feb 2011 07:46:52 -0500, Lew <> wrote,
    quoted or indirectly quoted someone who said :

    >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.
    ..
     
    Roedy Green, Feb 12, 2011
    #6
  7. albert kao

    Lew Guest

    Re: signer information does not match signer information of otherclasses in the same package

    On 02/12/2011 02:04 PM, Roedy Green wrote:
    > On Fri, 11 Feb 2011 07:46:52 -0500, Lew<> wrote,
    > quoted or indirectly quoted someone who said :
    >
    >> 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.


    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
    Honi soit qui mal y pense.
     
    Lew, Feb 12, 2011
    #7
  8. albert kao

    Lew Guest

    Re: signer information does not match signer information of otherclasses in the same package

    On 02/12/2011 02:07 PM, Roedy Green wrote:
    Lew wrote, quoted or indirectly quoted someone who said :
    >
    >> Approaches that isolate you from responsibility for third-party products
    >> should be considered first.

    >
    > 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.

    --
    Lew
    Honi soit qui mal y pense.
     
    Lew, Feb 12, 2011
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Arn Cota

    Determine jar signer

    Arn Cota, Jun 28, 2005, in forum: Java
    Replies:
    8
    Views:
    920
    Roedy Green
    Jun 30, 2005
  2. clercmedia
    Replies:
    2
    Views:
    32,388
    clercmedia
    Dec 9, 2005
  3. Replies:
    0
    Views:
    2,995
  4. lerenard001
    Replies:
    0
    Views:
    434
    lerenard001
    Jul 7, 2008
  5. lerenard001
    Replies:
    0
    Views:
    480
    lerenard001
    Jul 9, 2008
Loading...

Share This Page