Why does GlassFish warn about not finding referenced JAR files?

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
${domain-dir}/applications/j2ee-modules/CustomerCMP-app-client/CustomerCMP-ejb.jar;
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.

Comments:

I think this issue should be reviewed in a broader context since it appears to encapsulate a theme that re-occurs in J2EE/Glassfish/Netbeans. For a fresher using these tools, there is an overwhelming issue of "NOISE". The logs/Output-Windows contain masses of information that is largely ignored until a problem arises; then the novice finds it hard to identify the true problem because it's buried in a morass of verbosity!

As an example, take the issue described in this blog. The 1st para says: "This way the user is aware that an expected JAR file is missing, and so the client may behave differently or may fail altogether.". But the rest of the blog then goes on to explain how the messages may be safely ignored. Each of these messages extends to (in our case) 100 lines approximately. There is a message for each jar. On a production sized application, this adds up to 1000's of lines in the logs. And then it is suggested that we simply ignore them!

Please, can the developers revert to the UNIX golden rule: if successful - shut up; if unsuccessful - shout out.

All the rest of the logging (useful for the original developers, and occasionally useful for the rest of us) should be controlled by verbosity settings. That way, we won't suffer from the "cry wolf" syndrome.

Posted by Joe Robbins on February 11, 2008 at 09:00 PM CST #

It is often hard to know how much logging is too much and how little is too little.

In general I think most would agree with you that "if successful - shut up." I certainly do. Part of the difficulty - and it's present in this case - are cases of "successful but maybe not what you intended."

As I said in my comments in the issue you referred to, GlassFish should certainly not display the stack trace in these cases. And I suppose the server could collect all the URIs to JARs it cannot find when it performs this check and log a single message that lists them all, rather than using separate messages for each.

I feel strongly, though, that logging a warning about JARs that are listed in the manifest Class-Path but seemingly missing from the archive is worthwhile. Granted, in most cases this warning results from GlassFish's own practice of expanding the submodule archives and them deleting them. But not always.

More generally, GlassFish could certainly do a better job with its logging and its an ongoing task for us to improve that. When specific cases come up we try to address them. And speaking for myself, when I'm working on parts of the system for other reasons I always try to look for ways to improve the logging.

Posted by Tim Quinn on February 12, 2008 at 12:42 AM CST #

Your posting suggests that this is mostly a warning that is ignorable - but it seems that, sometimes, there is something actually wrong. We're having an issue along these lines now - a client that fails to start, and the only log message in the server log is exactly this one - and now I don't know whether the problem is somehow related to this, and it is a problem with Glassfish, or a problem elsewhere in my application.

For scenarios like mine, it would be best if Glassfish would not complain about things that are not actually broken - so I could more easily focus on whatever the real issue might be...

It seems that Glassfish could track which jar files references in the manifest it created, then deleted after preserving their content - and it could just not say anything about any of those...

Moises

Posted by Moises Lejter on August 14, 2008 at 06:52 AM CDT #

If the error refers to one of the submodule JARs in the EAR then you can safely ignore it. If it refers to some other JAR your client refers to then there is a problem you need to address.

We agree that the current messages are not adequate, and are confusing, and can cause someone to overlook an actual problem. As with everyone I talk to in this business, we have more that we want to do than we have time to do it in, and something like this which does not break a feature tends to get pushed lower on the priority list.

We plan to address this as part of the v3 work we are doing. It is possible - but we cannot commit to this - that we might address this sooner than that.

Posted by Tim Quinn on August 14, 2008 at 11:02 AM CDT #

I was faced with the same warning message, and was misled thinking it was an application issue. The application did have an issue, and was resolved, but it took time to resolve it because of the misleading warning message. I am using GlassFish Enterprise Server 2.1. Is a workaround already available? (It is more than a year since the last post).

Posted by Arnab Dey on September 24, 2009 at 06:54 PM CDT #

Arnab,

Unfortunately there is no workaround for v2.x. The situation is somewhat better in v3 because the JARs for the submodules (such as the EJB in the original example) are retained during deployment instead of deleted. So, in v3, when this message appears, it really is true that some JAR's manifest Class-Path refers to a JAR that is not packaged in the application.

This might or might not be a problem, depending on whether the developer really intended that JAR to be in the app. But in v3 the message refers to a truly missing JAR.

Posted by Timothy Quinn on September 25, 2009 at 04:09 AM CDT #

Hello, i have the same problem
i don'z understand you when you say "chech the repertory"
where we must serch to find the repertory where Glassfish put the file jar or the others
because for me in default there is the ejb module with librairies of my ear-client
but the probleme that i must let it not selected, if i select it, he'll product an other errors

please tell me where i must check my ejb.jar or what's the configuration that i msut put on.

sabir

Posted by sabir on March 07, 2011 at 11:36 AM CST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

News and musings on the technology I work on at Oracle.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today