Knowing exactly how the generated client JAR is created and what is inside it might be useful but please do not rely on it. You have already discovered that things have changed from GlassFish 2 to GlassFish 3.
To clarify a few things:
GlassFish 2 will not put all non-WAR JARs into the generated app client JAR. It will place the transitive closure of all EJB module JARs, all non-module JARs at the top of the EAR, and all JARs in the EAR's library directory (if any). In many cases this might look like "all non-WAR JARs" but it's not necessarily the same set.
Also, the GlassFish 2 app client container must always expand the generated app client JAR into a temporary directory, then it can add the JARs that were in the generated JAR to the class path. This happens as part of every app client launch and is obviously wasteful.
That is partly why we redesigned how GlassFish 3 does things. I summarized the changes in this blog posting
http://blogs.sun.com/quinn/entry/app_client_container_features_in if people are interested. The basic idea is that GlassFish 3 downloads multiple files now instead of a single large JAR that contains those multiple files. Deployment is faster (no need to create the big generated JAR), download is basically the same (the same amount of data is sent), and launching is faster because the ACC does not need to expand any files before it can get started.
I would suggest that people really interested or concerned about this should read the relevant parts of the Java EE spec. It describes in detail what JARs are required to be on the class path of an app client (and all other module types for that matter). (The Java EE 6 spec section EE8.3.3 discusses app clients in particular.)
Naturally, exactly how GlassFish or any other implementation accomplishes this should not affect how you write your applications or how end-users run them. You should be able to rely on the behavior mandated by the spec.
- Tim
[Message sent by forum member 'tjquinn']
http://forums.java.net/jive/thread.jspa?messageID=470954