Hi, Steve.
Historically, GlassFish and its predecessors have included any EJB JARs from the EAR when creating the generated app client JAR file. I believe the original intent was to simplify the developer's job so that he or she would not have to explicitly declare dependencies (in manifest Class-Path settings, for example) of the client on EJB artifacts.
In your case, all those EJB JARs are bundled into the generated app client JAR, and then they are all expanded as the ACC prepares to run the client. This is costing a fair amount of time according to the log output. This will happen regardless of how you launch the client - Java Web Start or the appclient script.
I'm not sure I fully understand the design of your app, but if it were possible to reduce the number of JARs marked as EJB JARs and instead deploy them in the lib directory (or any directory of your choice if you specify the <library-directory> element in the descriptor) then that would help. GlassFish would still bundle those library JARs into the app client but the ACC would not have to expand the library JARs as it prepared to run the client.
I still would like to understand why the populateDescriptor takes so long. Thanks for the offer of supplying the EAR file. If you could please send me or point me to the EAR file I'll explore that here so you can return to your real job!
(Please send me any asadmin script fragments for defining anything else I'd need to be able to deploy the app.)
- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]
http://forums.java.net/jive/thread.jspa?messageID=231658