GlassFish does look at the app client JAR's manifest Class-Path. It computes the transitive closure of that Class-Path (that is, the JARs listed there plus any JARs they depend on plus any JARs THEY depend on, etc. etc. etc.) to be sure include what the client expects.
GlassFish 3 behaves as you suggested - if the developer declares dependencies using the Class-Path then GlassFish makes those JARs (and their transitive closures) available to the client. (Also, any JARs in the EAR's library directory are also available, as required by the spec. The spec describes this.)
But GlassFish 2 is stuck with the older, legacy behavior in order to preserve backward compatibility with its predecessors.
- Tim
[Message sent by forum member 'tjquinn']
http://forums.java.net/jive/thread.jspa?messageID=470573