Multiple jnlp's for signed jars

Hi,
I'm trying to solve the issue where you have several different certificates trying to sign the jars ... I've found out that you can just add extentions to your main jnlp and add the jars there.
Problem: I have loads of jars, all with different certificates.
At the moment I just generate my jnlp by usign a template, and entering $dependencies to list all jars in the file. That didn't work (JAR resources in JNLP file are not signed by same certificate), so I added my main jar in the main jnlp, and all the other jars in the extended jnlp, which is not working. Probably because (correct me if I'm wrong) I have to split every jar with another certificate into another jnlp ?
Is there any way I can split up the signed jars without having to add them manually in the jnlp file ?
Edited by: ReggieBE on May 16, 2008 1:17 AM

Oh, and I'm using webstart-maven-plugin from mojo.codehouse.org ;)

Similar Messages

Specifiy certificate in jnlp, so mutliple signed jars aren't a problem

Is it possible to specify my certificate in the jnlp?
Webstart can ask the user the accept that one, while some of my jars are actually signed by other certificates too.
I have several 3th party jars that I sign but that are already signed, for example acegi-security, ... It's hard to unsign them automatically and it doesn't feel right to have to unsign them (it's like being signed is a bad thing).
PS: I am using maven2 and it's webstart plugin to generate my jnlp which works perfectly with non-signed dependend jars.

Problem is I have about 30 dependencies, of which a couple are already signed.
I don't want my user to have to click through 20 certificates.

Tool for signing jars

hi
Is there any tool with gui form. so that we can just fill values and click on a button and the applet is signed thanx alot

I've had great success with JDeploy - you can download it here:
http://www.tiobe.com/jdeploy.htm
IF not, you might want to check out the resource listing at google:
http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Deployment/?il=1
Best regards,
Bj�rn B�rresen

Mail: choosing one of multiple valid keys to sign

If I have multiple, valid keys for signing an email message, how do I chose which one Mail should use? If possible, I'd like to configure this on a per-message basis.
Thanks in advance,
Joe

Hi Balaji bhau
Just maintain the Overhead group in FG material master.. It will be done.. This too is required, if you want to charge diff overhead for diff FG.... If your overhead rate is same across, you dont even need Overhead group
Assign a costing sheet to your Valuation Variant....
If you want to apply diff OH to diff RM based on FG, then
1. Then assign Origin Group in RM Master In the Costing sheet BASE, use Cost Ele & Origin Group
2. Maintain Org Group X in RM A, Org Grp Y in RM B
And
Ovh Grp 10 in FGA & Ovh Grp 20 in FG B
you can maintain 10% Ovh on RM A and 7% on RM B for FG A & 20% Ovh on RM A and 17% on RM B for FG B
Refer Std Costing Sheet A00001 for your requirement...
Br, Ajay M

SunOne ignores signed jars -- bug?

This is a follow-up to http://softwareforum.sun.com/NASApp/jive/thread.jsp?forum=69&thread=18672.
The use of signedBy grant blocks appears to be broken, at least for signed jars that are deployed as part of an ear file. I created and signed a small jar that attemps to do a few normally forbidden things, then added these entries to the server.policy file:
keystore "file:${/}C:${/}Sun${/}AppServer7${/}codesign.keystore";
grant signedBy "codesign" {
permission java.util.PropertyPermission "*", "read,write";
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
Then I included the jar in a small enterprise app in which an EJB called the "forbidden" methods. In spite of the entires in server.policy, the code still fails due to AccessControlExceptions.
Running with -Djava.security.debug=policy reveals:
[04/Apr/2003:09:56:46] WARNING ( 2176): CORE3283: stderr: policy: getPermissions:
[04/Apr/2003:09:56:46] WARNING ( 2176): CORE3283: stderr:      PD CodeSource: (file:/C:/Sun/AppServer7/domains/domain1/server1/applications/j2ee-apps/cms_3/./lib/SignedJarTest.jar <no certificates>)
Note the <no certificates>
Running the class from the command line -- using the exact same jar, and using the SunOne JVM and server.policy file -- is successful.:
java -cp ./Sun/AppServer7/domains/domain1/server1/applications/j2ee-apps/cms_3/lib/SignedJarTest.jar -Djava.security.manager -Djava.security.policy=C:/Sun/AppServer7/domains/domain1/server1/config/server.policy -Djava.security.debug=policy com.seabase.scratch.crypto.SignedJarTest
policy: getPermissions:
PD CodeSource: (file:/C:/Sun/AppServer7/domains/domain1/server1/applicat
ions/j2ee-apps/cms_3/lib/SignedJarTest.jar [
Version: V1
Subject: CN=Patrick Jones, OU=DOE Project, O=SEA, L=New Orleans, ST=Louisiana,
C=US
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@72ffb
Validity: [From: Tue Apr 01 12:34:18 CST 2003,
               To: Sun Jul 20 01:34:18 CDT 2003]
Issuer: CN=CA, OU=DOE Project, O=SEA, L=New Orleans, ST=Louisiana, C=US
SerialNumber: [    4a821187 ]
... etc
SunOne evidently ignores the fact that this jar is signed. This appears to be a bug.

Java Plug-in 1.6.0_26
Using JRE version 1.6.0_26-b03 Java HotSpot(TM) Client VM
User home directory = C:\Users\dbladorn
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
o:   trigger logging
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
x:   clear classloader cache
0-5: set trace level to <n>
exception: exit(-1).
ExitException[ 4]java.lang.RuntimeException: exit(-1)
     at com.sun.javaws.Main.systemExit(Unknown Source)
     at com.sun.javaws.security.AppPolicy.grantUnrestrictedAccess(Unknown Source)
     at com.sun.javaws.LaunchDownload.checkSignedResourcesHelper(Unknown Source)
     at com.sun.javaws.LaunchDownload.checkSignedResources(Unknown Source)
     at sun.plugin2.applet.JNLP2Manager.prepareLaunchFile(Unknown Source)
     at sun.plugin2.applet.JNLP2Manager.loadJarFiles(Unknown Source)
     at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)
Exception: ExitException[ 4]java.lang.RuntimeException: exit(-1)

JNLP: Signed jars but still not trusted

I have an applet that has signed jars that were signed by the same key, the applet shows the correct warnings on startup and works fine (allows access to the local file system, etc), however there still exists the 'yellow triangle warning' on one of two popups frames that the applet produces (but not the other one).
The applet does use native code (packaged in a signed jar and referenced in the JNLP). The jars are all signed by the same certificate from a CA. I originally didn't have the JNLP signed (by placing it in the main jar in JNLP-INF/APPLICATION.JNLP) but this didn't help. Also I didn't have the JNLP codebase set to a real URL (and really cant in production because its a solution we deploy to customers servers - its packaged software not hosted) but even after I tested with a codebase to a test server, it still didnt remove the famed yellow triangle. I have all-permissions set in the JNLP.
So two related questions:
1) Other than having not having signed jars (or not signed correctly), what other reasons cause the 'yellow triangle'?
2) The warning only appears on one of the popup Frames. What could be the possible reasons for that? Are there some privileges that show the icon whether the applet is signed or not?
Note: While changing the client policy setting (showWindowWithoutWarningBanner) works, this cant be a solution.
From the Java Console:
...It goes through all the jars (I only included one for brevity - there are 23 of them). Note it says 'have 1 common certificates'.. which I think indicates everything is signed by the same cert.
Is there any indication in the console logs I can use to determine why it is not trusted? It looks (to me) that everything is OK, until it says 'istrusted=false'.
security: Validating cached jar url=http://10.192.252.26/QMDesktop/native.jar ffile=C:\Documents and Settings\bunkowm\Application Data\Sun\Java\Deployment\cache\6.0\34\1df0b62-2c3ce377 com.sun.deploy.cache.CachedJarFile@d964af
cache: Reading Signers from 995 http://10.192.252.26/QMDesktop/native.jar | C:\Documents and Settings\bunkowm\Application Data\Sun\Java\Deployment\cache\6.0\34\1df0b62-2c3ce377.idx
security: Have 1 common certificates after processing http://10.192.252.26/QMDesktop/native.jar
security: Istrusted: null false
security: Loading certificates from Deployment session certificate store
security: Loaded certificates from Deployment session certificate store
security: Validate the certificate chain using CertPath API
security: Obtain certificate collection in Root CA certificate store
security: Obtain certificate collection in Root CA certificate store
security: Start to check whether root CA is replaced
security: The root CA hasnt been replaced
security: No timestamping info available
security: Found jurisdiction list file
security: No need to checking trusted extension for this certificate
security: The CRL support is disabled
security: The OCSP support is disabled
security: This OCSP End Entity validation is disabled
security: Checking if certificate is in Deployment denied certificate store
security: Checking if certificate is in Deployment permanent certificate store
security: Checking if certificate is in Deployment session certificate store
security: Mark trusted: null

Andrew - of course you were correct about the signed cert - I misspoke when the CA signed applet didn't show a warning. (You were also right that I must have checked 'always accept' the certificate on the server I had the CA signed cert on).
I think you guys are on to something about the privileged actions. It would explain where one popup has the icon and the other doesn't. We have Javascript making calls into the applet and we do use JNI (although I don't think there are any calls back). We do wrap these calls in privileged actions but maybe we missed something. What I've seen before is a security exception is thrown if we don't wrap them - but maybe there are areas where we don't and it doesn't throw an exception or it does and we eat it somehow (and for whatever reason doesn't cause anything noticeable).
Now that I know it could likely be the applet code and not necessarily a build issue with signing the jars, I have another place to look...
I'll check it out and let you know what I find.

A few questions about signing JARs for Web start

I'm still a bit new to all this, so just want to clear a few things up.
I'm currently trying to publish an application using Web start, so i know I have to sign all the JARs, as it needs to do some writing to the hard drive.
1. I have my main JAR file, and then two "third party" JAR files in the /lib subfolder, I take it I need to sign those two as well, does it matter that I don't have the .class file for those two, as I didn't write them?
2. I'm running the JARSIGNER program with exactly the same command line apart from the filename of the .jar file, is that correct? or do I need a different certificate for each .jar file?
Just can't seem to get all three signed, Web start says one different one isn't signed each time I try it out.
3. When signing, does it add something to the end of the JAR file itself? as I can't see any extra files created.

Signing adds entries in the mainifest, not in the main file list in the jar file.
You can sign third party jar files, but it is not advisable. An alternative is to put third party jars in a seperate extension jnlp file, if they need all-permissions, you can get the third party jars already signed by whoever supplied them. If not, you do not need to request all-permissions in the extension jnlp file, and that part of the code will be run in the secure sandbox.
/Andy

SSL Cert used to sign Jars for distribution via WebStart

Hi,
I have an SSL cert (Comodo InstallSSL) for my website and wondered if I can use it to sign jars so, when distributed via webstart, the old "untrusted source" message doesn't get displayed. I've been doing a lot of reading but, to be honest, I can't really find my bearings! I have imported the cert into my keystore but get the message when I try to sign a jar:
Certificate chain not found for: myalias myalias must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.I have the following files in relation to my cert:
xxx.cabundle (this can be imported into keytool easily)
cert/xxx.crt (looks like a PGP file, cannot be imported (-import) into keytool)
private/xxx.key
My questions I suppose are:
1. Can I use a cert issued for SSL to sign jars for webstart distribution?
2. If yes to 1; what steps other than importing the cert alone (which generates the message above) do I need to do to achieve this?
Any help would be appreciated!
Rich

Hi,
yes, the pkcs12 certificate includes the private key, as opposed to pb7 which does not.
Sent from Cisco Technical Support Android App

Updating to signed JARs causes problems for older Java versions?

Bear with me on this one -- not a Java developer, but an end user of Java products looking for a little clarification.
We use a product which delivers a Java application via JAR file / web to end users (GlobalScape's EFT server). With the recent release of Java 7 Update 51, users have been running into issues running these JAR files as they are not properly "signed". We're working with the vendor to get updated signed JAR files in place, but they've warned us that these new JAR files will cause errors (or maybe not work at all) on folks who aren't running Java 7 Update 51.
Trying to wrap my head around why that might be. Best theory I can come up with from perusing threads here along with the Java team blogs is that the new security attributes used in the updated JAR files aren't "trusted" by older versions of Java (prior to Update 51?).
We're pushing our vendor for clarification, but curious if someone here could help explain.
Thanks!

I suspect the problem with 'new JAR files will cause errors' is mainly because the vendor keeps enhancing their product, and may not any more support older JREs, or the new jars are no more compatible For example, we build our product on JDK 1.5 ... as some users out there must use that one because the 'newer and better' release does not work for them.
But so far, we have not seen any problems running the 'JRE 7 Compliant' applications on older releases ... provided you can make your application run on latest JRE 7.
In most cases, one can simply remove the previous signature, add (now required) attributes, and sign the same jar again.
But I have yet to find a vendor that would simply add attributes to some older release and re-sign those. Perhaps they can't repeat the build / QA cycle, and would not 'trust' the re-signed jars.
Our curse are signed Cryptographic Provider jars.
Those must be signed by certificates rooted by Sun/Oracle, and adding attributes invalidates that signature - we can re-sign them, but then they won't work. In our case, we are stuck with 5+ year old Bouncy Castle jars, and it does not help us that their 'current' jars are signed with attributes - they are completely incompatible..
IMHO, Oracle failed to think this all thru - or does not care.

Signing Jars For JWS

My company just got me a Java coding signing cert from Verisign for signing the jar files used by our JWS application. At first I could not get cert to inport using keytool. So based on a suggestion from someone, I imported the cert into IE to verify it was a valid cert. This worked fine, so I exported the cert from IE in 509 format. I was then able to import the cert into a keystore. The problem is when I attempt to sign my jar files I get the error: jarsigner: Certificate chain not found for: signfiles. signfiles must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.
What does this mean, and how do I fix it?
Thanks,
Jim Urban

I got the same error.
But then I found out that a pkcs12 file could be used directly as a keystore by jarsigner. So you can skip the keytools step.
I exported my certificate from Netscape Communicator using the Security tool as a .p12 file. Then I pointed jarsigner at my pkcs12 file.
jarsigner -storetype pkcs12 -keystore cert.p12 MyClasses.jar keyname
You can find your keyname alias by entering:
keytool -list -storetype pkcs12 -keystore cert.p12

I look for guider in signing jars

Hi everybody
for what signing jars is good,for applet jars or desktop applications jars???
and how can I use it? please i need the answerer explanations not url to tutorials
Thanks to every reader to this topic

i need the answerer explanations not url to tutorialsA stupid remark. The tutorials are explanations, and they have already been reviewed, debugged, etc. Why on earth would you prefer someone's random opinion to a properly produced piece of documentation?
At best this is just lazy thinking.

Error when i try to sign .jar for webutil

i have try to use signwebutil.bat in webutil 1.0.6 but i have the follow error_
Generating a self signing certificate for key=webutil2...*
Errore keytool: java.lang.Exception: Non è stata generata la coppia di chiavi, l'alias <webutil2> è già esistente*
+.+
There were warnings or errors while generating a self signing certificate. Please review them.*
+.+
Backing up d:\w\jacob.jar as d:\w\jacob.jar.old...*
+1 file copiati.+
Signing d:\w\jacob.jar using key=webutil2...*
+.+
There were warnings or errors while signing the jar. Please review them.*
Generating a self signing certificate for key=webutil2...*
Errore keytool: java.lang.Exception: Non è stata generata la coppia di chiavi, l'alias <webutil2> è già esistente*
+.+
There were warnings or errors while generating a self signing certificate. Please review them.*
+.+
Backing up d:\w\frmwebutil.jar as d:\w\frmwebutil.jar.old...*
+1 file copiati.+
Signing d:\w\frmwebutil.jar using key=webutil2...*
+.+
There were warnings or errors while signing the jar. Please review them.*

Maybe you could try to change the values in your sign_webutil.bat file:
REM Give your alias key here.
REM
SET JAR_KEY=webutil3
REM
REM Key Password for the given key to be used for signing.
REM
SET JAR_KEY_PASSWORD=webutil3
REM
REM Number of days before this certificate expires
REM
SET VALIDDAYS=360
Francois

Problem Packing Signed JARs of more than 10 MB

Hi friends of Java,
there seems to be a size issue when packing signed JARs.
When I try to pack a signed JAR of about 5 MEGs (such as the jbossall_client.jar file) it works (i.e. jarsigner can verify the result),
but if i try doing it with a JAR of about 11 MEGs the jarsigner can't verify the packed (and unpacked again) file.
Example:
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>dir temp\webstart\BasisWebClient.jar
06.03.2009 17:32 10.943.963 BasisWebClient.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 --repack temp\webstart\BasisWebClient.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -storepass xxxxxx -keystore resources\build\key\BasisWebKeystore temp\webstart\BasisWebClient.jar BasisWeb
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify temp\webstart\BasisWebClient.jar
jar verified.
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 temp\webstart\BasisWebClient.jar.pack.gz temp\webstart\BasisWebClient.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>unpack200 temp\webstart\BasisWebClient.jar.pack.gz test.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify test.jar
jarsigner: java.lang.SecurityException: SHA1 digest error for basisweb/vg/presenter/SchluesselBezeichnungDialogPresenter.class
The same with a smaller file:
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>dir temp\webstart\jbossall-client.jar
31.08.2007 07:31 4.895.807 jbossall-client.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 --repack temp\webstart\jbossall-client.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -storepass xxxxx -keystore resources\build\key\BasisWebKeystore temp\webstart\jbossall-client.jar BasisWeb
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify temp\webstart\jbossall-client.jar
jar verified.
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>pack200 temp\webstart\jbossall-client.jar.pack.gz temp\webstart\jbossall-client.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>unpack200 temp\webstart\jbossall-client.jar.pack.gz test.jar
C:\p\u\ccm_wa\basis_web\santafu~tnagel\santafu>jarsigner -verify test.jar
jar verified.
It also works when I split the original JAR in multiple parts. Any ideas?
Used Java Version:
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
OS: Windows XP Pro Version 2002 SP2
PC: Intel Pentium 4 3.2GHz, 2GB RAM, 160 GB HD
Regards from Germany,
Thomas Nagel

Hello Bryan,
I dont have a solution yet. Currently we use the jars uncompressed. Sad, but that works.
For the future, we are not really sure wether we can stick with JWS, as the signed JNLP-file-issue might make us even more trouble.
I've done some error search. Look at the following.
Try for your own with some different sized jar's, and maybe post the results (definitely if they all pass):
--- snip ----
package ctest;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.Enumeration;
import java.util.Map;
import java.util.jar.*;
import java.util.jar.Pack200.*;
* @author tnagel
public class PackTest implements Runnable {
     String test1 = "junit";
     String test2a = "xalan";
     String test2 = "jbossall-client";
String test3 = "BasisWebClient2";
String dir = "/tmp/";
String ext1 = ".jar";
String ext2 = ".jar.pack.gz";
//String infile = "/tmp/BasisWebClient.jar";
//String outfile = "/tmp/BasisWebClient.jar.pack.gz";
//String testfile = "/tmp/testaus.jar";
* @param args the command line arguments
public static void main(String[] args) {
     PackTest me = new PackTest(args);
public PackTest(String[] args) {
this.run();
public void setProperties(Packer packer) {
// Initialize the state by setting the desired properties
Map p = packer.properties();
// take more time choosing codings for better compression
p.put(Packer.EFFORT, "9"); // default is "5"
//// use largest-possible archive segments (>10% better compression).
// p.put(Packer.SEGMENT_LIMIT, "-1");
//// reorder files for better compression.
//p.put(Packer.KEEP_FILE_ORDER, Packer.FALSE);
//// smear modification times to a single value.
//p.put(Packer.MODIFICATION_TIME, Packer.LATEST);
//// ignore all JAR deflation requests,
//// transmitting a single request to use "store" mode.
//p.put(Packer.DEFLATE_HINT, Packer.FALSE);
//// discard debug attributes
//p.put(Packer.CODE_ATTRIBUTE_PFX+"LineNumberTable", Packer.STRIP);
// throw an error if an attribute is unrecognized
p.put(Packer.UNKNOWN_ATTRIBUTE, Packer.ERROR);
//// pass one class file uncompressed:
//p.put(Packer.PASS_FILE_PFX+0, "mutants/Rogue.class");
@Override
public void run() {
     doTest(test1, true);
     doTest(test2, true);
     doTest(test3, true);
     doTest(test3, true);
     doTest(test3, true);
private void doTest(String test, boolean compare) {
String infile = dir + test + ext1;      // "/tmp/BasisWebClient.jar";
String outfile = dir + test + ext2; // "/tmp/BasisWebClient.jar.pack.gz";
String testfile = dir + test+ "-aus" + ext1;
try {
     countJar(infile, false);
     JarFile jarFile = new JarFile(infile);
FileOutputStream fos = new FileOutputStream(outfile);
// Create the Packer object
Packer packer = Pack200.newPacker();
setProperties(packer);
// call the packer
long startTimeMethode =System.currentTimeMillis();
packer.pack(jarFile, fos);
System.out.println("Time for Pack: " + (System.currentTimeMillis() - startTimeMethode));
jarFile.close();
fos.close();
File f = new File(outfile);
FileOutputStream fostream = new FileOutputStream(testfile);
JarOutputStream jostream = new JarOutputStream(fostream);
Unpacker unpacker = Pack200.newUnpacker();
// Call the unpacker
startTimeMethode =System.currentTimeMillis();
unpacker.unpack(f, jostream);
System.out.println("Time for Unpack: " + (System.currentTimeMillis() - startTimeMethode));
// Must explicitly close the output.
jostream.close();
     countJar(testfile, false);
     if(compare) compareJars(infile,testfile);
} catch (IOException ioe) {
     System.err.println(ioe);
ioe.printStackTrace();
private void countJar(String filename, boolean showDetails) {
     JarFile jarFile1 = null;
     try {
          int entries = 0;
          long sizeTotal = 0L;
          long compressedSum = 0L;
          jarFile1 = new JarFile(filename);
          Enumeration e = jarFile1.entries();
          while(e.hasMoreElements()) {
               JarEntry jarE = (JarEntry) e.nextElement();
               entries ++;
               sizeTotal += jarE.getSize();
               compressedSum += jarE.getCompressedSize();
               if(showDetails) {
                    System.out.println( jarE.getName() + " s= " + jarE.getSize() + " c= " + jarE.getCompressedSize() );
          System.out.println( filename + ": " + entries + " entries, " + sizeTotal + " Byte, compressed " + compressedSum + " Byte" );
} catch (IOException ioe) {
     System.err.println(ioe);
ioe.printStackTrace();
} finally {
     try { if(jarFile1 != null) jarFile1.close(); } catch (Exception e) { }
private void compareJars(String erstes, String zweites) {
     JarFile jarFile1 = null;
     JarFile jarFile2 = null;
     try {
          int fehler = 0;
          int entries = 0;
          jarFile1 = new JarFile(erstes);
          jarFile2 = new JarFile(zweites);
          Enumeration e1 = jarFile1.entries();
          Enumeration e2 = jarFile2.entries();
          while(e1.hasMoreElements()) {
               JarEntry jarE1 = (JarEntry) e1.nextElement();
               if(e2.hasMoreElements()) {
                    JarEntry jarE2 = (JarEntry) e2.nextElement();
                    entries++;
                    if(!jarE1.getName().equals(jarE2.getName())) {
                         System.out.println( "Name different at Index= " + entries+ " n1=" + jarE1.getName() + " n2=" + jarE2.getName() );
                         fehler ++;
                         break;
                    if(jarE1.getSize() != jarE2.getSize()) {
                         System.out.println( "Size different at bei " + jarE1.getName() + " Index= " + entries + " s1=" + jarE1.getSize() + " s2=" + jarE2.getSize());
                         fehler ++;
                    if(jarE1.getCrc() != jarE2.getCrc()) {
                         System.out.println( "CRC different at " + jarE1.getName() + " Index= " + entries + " s1=" + jarE1.getCrc() + " s2=" + jarE2.getCrc());
                         fehler ++;
                    if(jarE1.getMethod() != jarE2.getMethod()) {
                         System.out.println( "Method different at " + jarE1.getName() + " Index= " + entries + " m1=" + jarE1.getMethod() + " m2=" + jarE2.getMethod());
                         fehler ++;
          System.out.println( "Errors= " + fehler + " entries=" + entries );
} catch (IOException ioe) {
     System.err.println(ioe);
ioe.printStackTrace();
} finally {
     try { if(jarFile1 != null) jarFile1.close(); } catch (Exception e) { }
     try { if(jarFile2 != null) jarFile2.close(); } catch (Exception e) { }
--- snip ----
Cheers,
Thomas

DownloadService.loadResource for external jars for 1.6.0-19+

First, be kind with my english, i'm french (nobody's perfect...)
I have a JNLP into which i declare a signed jar resource main.jar. This application retreive at execution a list of signed jar names (+a.jar, b.jar+...) that i dynamically load on my need through DownloadService.loadResource. My a.jar, b.jar are cached and it rules! But if i made a new main.jar, a.jar and b.jar, and deploy them on my server, here what's happend:
- main.jar is tested for modification date on server (thanks to "If-Modified-Since" HTTP header), cache date is before this date, so JWS update main.jar by downloading this new main.jar. This is the behaviour described into specs and it is perfect for me!
- but for others resources (a.jar, b.jar) i was excpected the same behaviour but JWS does not seems to check for modification date. So a.jar and b.jar are not updated.
So my first question: Is there a way to tell to DownloadService.loadResource to check for modification date? i could deal with jar version but this basic date checking was great for me...
Except this cache minor problem, external jar download works just fine except i get the warning security problem [Mixing Signed and Unsigned Code |http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html].
All my jars are signed with the same certificate, so i was a bit confused.
Anyway, i follow indications and put the Trusted-Only: true attribut into the manifest of main.jar.
But it leads to this exception:
java.lang.SecurityException: Trusted-Only loader attempted to load sandboxed resource from http://monserveur/a.jar
     at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1400(Unknown Source)
     at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
     at java.net.URLClassLoader$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(Unknown Source)
     at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at my.package.a$5.run(a.java:348)
     at java.lang.Thread.run(Unknown Source)I found some posts that deal with similar problems but it does not give me a working solution. The difference seems to be the fact that i load external jars (not defined into JNLP).
My JNLP is validated though JaNeLA.
I cannot set a.jar, b.jar as resources into jnlp because i retreive their location during execution...
My JNLP also declare:
<security>
        <all-permissions/>
</security>I think i'm a bit confused with the sandbox notion and the Trusted-Only: true attribut of the manifest. I also tried to add it to a.jar, b.jar and not main.jar but vainly. I also tried to set it on all jars but it does not work better.
Is there a way to load external jar without having the Mixing Signed and Unsigned Code warning popup? What do i not well understand?
Sorry to be so chatty...
Thanks in advanced for any answer.

So, I finally succed in finding a solution.
But this solution seems perhaps a barbarian way to solve my problem but it works.
The idea (as far as i understand) is that when you define "all-permission" into JNLP file, then these permission are granted for JNLP ClassLoader. When you load external jar through DownloadService.loadResource, then another classloader is used. It seems that this classloader does not inherit security policy from JNLP ClassLoader.
My solution is to define my own policy:
Policy.setPolicy(getAllPermissionPolicy());
    * @return a {@link Policy} with all permission granted
   private Policy getAllPermissionPolicy()
      Policy policy = new Policy() {
         private PermissionCollection m_permissionCollection;
         @Override
         public PermissionCollection getPermissions(CodeSource p_codesource)
            return getAllPermissionCollection();
         @Override
         public PermissionCollection getPermissions(ProtectionDomain p_domain)
            return getAllPermissionCollection();
          * @return an AllPermissionCollection
         private PermissionCollection getAllPermissionCollection()
            if (m_permissionCollection == null)
               m_permissionCollection = new AllPermission().newPermissionCollection();
               m_permissionCollection.add(new AllPermission());
            return m_permissionCollection;
      return policy;
   }For sure, you can decline this with permission you need. Here, all permission are allowed.
I'm not quite satisfied because it's seems to be a barbarian style solution. But for now, it fits my uses => no warning popup!
If anybody has a more proper way to deal with such an issue, i'll be glad to hear it!
Hope it helps.

Signed jar works differently than unsigned jar - why?

I'm having a problem with one of my JWS applications (out of six!) -- the application runs fine locally out of the jars. However, when I sign the main jar for running with JWS, it goes into a loop trying to read a property file contained within the main jar. This occurs whether I run it locally or from the JWS server.
The only difference I can see is that the manifest file is affected, but they both have the same reference to the main class and it's also in the jnlp file.
Any thoughts?

I'm having a problem with one of my JWS applications
(out of six!) -- the application runs fine locally out
of the jars. However, when I sign the main jar for
running with JWS, it goes into a loop trying to read a
property file contained within the main jar.If several jars are involved, I would try to have each one signed. And then test again.
This
occurs whether I run it locally or from the JWS
server.Weird.
The only difference I can see is that the manifest
file is affected, but they both have the same
reference to the main class and it's also in the jnlp
file.So far I too believed that the signing just causes additional entry lines in the Manifest file, where for each jar entry some cryptographic hash (md5, sha-1, ..) value will be written.
What happens if you mention the main class as well, in case you test from running from a jar from the command line?
Regards,
Marc

Multiple jnlp's for signed jars

Similar Messages

Maybe you are looking for