1

I have an applet that will not load for 1 client who is running IE7 on Vista.

The error is: 

java.lang.SecurityException: class "com.arup.web.printing.WebPrintApplet"'s signer information does not match signer information of other classes in the same package.

The applet code is in a jar file named: WebPrintApplet.jar and it has a dependency on Sun's PdfRenderer.jar. I have signed both of the jar files with the same certificate and we are hosting the jar files from the same folder on our web server.

I am at a loss for what could cause this issue in our case. My applet's code is all within the com.arup.web.printing.WebPrintApplet package and the entire jar file is signed.

Any clues as to the issue and how to resolve it?

Alex K
  • 22,315
  • 19
  • 108
  • 236
Chris Liechty
  • 60
  • 1
  • 5

3 Answers3

0

I have signed both of the jar files with the same certificate and we are hosting the jar files from the same folder on our web server.

If one of the Jars was already signed, it will now have multiple digital signatures. That could cause the error seen.

As an aside, a Java 7 JRE should support deploying embedded applets using JWS, which in turn allows sand-boxed access to the printer. Here is a demo. or the JNLP PrintService.

Community
  • 1
  • 1
Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
  • Sure enough the PDFRenderer.jar was previously signed with a cert that expired in 2009. I removed that signature and resigned the jar with my companies. I will have to wait for the client to try it again. Thanks for the quick reply. (I would give you an up vote but I don't have enough reputation) – Chris Liechty May 11 '12 at 21:15
  • Let me know how it goes. I do not really consider it 'answered' until the client reports success, but they might need to clear the class cache before the new applet loads. – Andrew Thompson May 11 '12 at 21:23
  • Ya I kinda jumped the gun there. I'll post an update. The client will not be able to test until Monday sometime. For now I'll leave it as answered unless the problem persists. – Chris Liechty May 11 '12 at 21:42
  • OK - thanks, we'll wait to Monday to see if it is truly solved. Have a great weekend. :) – Andrew Thompson May 11 '12 at 21:45
  • I finally heard something from the client today. All I heard was that they are still getting an error. I don't know if its the same error or not. I don't have direct communications with the client due to the way my company handles client communication. I'm hoping to find out more soon. – Chris Liechty May 15 '12 at 22:19
  • I'll wait ( not with baited breath, but I'll wait ;) – Andrew Thompson May 15 '12 at 22:20
  • Also one of my co-workers found this bug that we may be encountering which could explain things. [link](http://bugs.sun.com/view_bug.do?bug_id=6805618) The client has JRE 6u31 installed. – Chris Liechty May 15 '12 at 22:21
  • After much testing we found that the issue is not caused by the bug I linked to. We found that our applet will not load if "Enable the next-generation Java Plug-in" under the Advanced Tab in the Java control panel is disabled. Looks like it was because we used an object tag. I have updated our page to use an applet tag and now our applet works regardless of the Next generation plugin enabled value. – Chris Liechty May 17 '12 at 22:47
  • Try deploying the applet using the `deployJava.js` mentioned/linked from the [applet info. page](http://stackoverflow.com/tags/applet/info). – Andrew Thompson May 17 '12 at 23:12
0

As you seem to have long test cycles you may want to investigate another source of failure. This error typically comes up if you have classes in the same package in two different jar files, for example if you have extensions / changes to the pdf renderer in your jar file. I think you should avoid such constructs by design and where not possible, you must have the same signer information for the two jars.

The current plugins support different signers on different jars, but i don't know exactly how the implementation is with many signers on different jars with "shared" packages.

mtraut
  • 4,720
  • 3
  • 24
  • 33
  • 1
    Thanks, for the reply. We are using completely different package names than PDFRenerer.jar has, and we don't have any extensions to any of the PDFRender classes as we use them as is. I'm thinking that we may be running into the jre bug: [link](http://bugs.sun.com/view_bug.do?bug_id=6805618). – Chris Liechty May 15 '12 at 22:25
0

I know this is two years old, but it may help someone in my situation:

Put the jar of the offending class in $JDK/jre/lib/ext/ and retry with a fresh JVM process.

pyb
  • 4,813
  • 2
  • 27
  • 45