Why does GlassFish warn about not finding referenced JAR files?
By tjquinn on Dec 13, 2007
As you probably know if you have read other entries in my blog, GlassFish provides automatic support for launching application clients using Java Web Start. As part of this process GlassFish is very vigorous - and vocal - in making sure that every JAR file referred to from another JAR's manifest Class-Path entry is available where expected. If GlassFish cannot find such a referenced JAR file it will display a warning to that effect but will continue. This way the user is aware that an expected JAR file is missing, and so the client may behave differently or may fail altogether.
There is a side-effect to this that, understandably, has concerned some users. Luckily things actually work correctly, despite the worrisome warning.
Suppose you build an EAR that contains an EJB jar and an app client JAR. Further, suppose your app client JAR lists the EJB JAR as a dependent JAR in its manifest Class-Path entry. (Your IDE might even do this for you.) You will see a warning something like this:
Error attempting to process extensions from the manifest of JAR file
ignoring it and continuing
First, you might ask where the EJB JAR has gone so that GlassFish cannot locate it now? When GlassFish deploys an application it expands the EAR file into a directory. Further, it expands submodule JARs such as WARs and EJB JARs into subdirectories and then discards the just-expanded submodule JARs. GlassFish preserves the contents of those submodule JARs, just not in the original submodule JARs that it extracted from the EAR during deployment.
Second, you might wonder why your client seems to work just fine if the EJB JAR is missing? When you deploy an EAR containing an app client, GlassFish creates a generated app client JAR file that contains the original app client JAR's contents plus any other information it may need - such as dependent JARs listed in the app client JAR's manifest. It is this file that GlassFish uses for Java Web Start launches or if you use the --retrieve option on the asadmin deploy command or its GUI equivalent. For historical reasons, this generated app client JAR also contains the submodule subdirectory that holds the contents of the original EJB JAR. When the app client container prepares the class loader for the app client, it includes these subdirectories that are in the generated app client JAR. So although the original EJB JAR file itself is not present, its contents are present and GlassFish makes those files accessible to the app client. So the client works fine, despite the alarming warning message that the JAR itself is missing.
This is a long way of saying "Everything is fine" but I thought it might be helpful for people to understand exactly what is happening.