We want to improve several things with app clients, in particular the launching performance when you use the appclient script. (This topic does NOT apply to the Java Web Start support for app clients in GlassFish.)
We have some choices to make and we want your feedback. The options have advantages and disadvantages. Please read the summary below and reply to this entry to let us know what you think. If you see other pros and cons or think of other options we should consider please mention them.
In v2, when you deploy an app client or an EAR containing an app client, GlassFish generates a new JAR file containing the app client JAR itself, all JARs listed in the Class-Path of its manifest, and all JARs in the EAR's library directory
When you use the "deploy --retrieve" or "get-client-stubs" commands, GlassFish downloads this generated JAR file into the end-user's directory that is specified on the command.
During an app client launch the GlassFish app client container (ACC) expands the downloaded JAR into a temporary directory, then builds a class path including the JARs in that temp directory. This is how GlassFish makes sure that you app client has access to all the classes and resources it needs. The expansion occurs into a new temporary directory every time an end-user launches an app.
We have received complaints that start-up time is too long, especially for larger app clients or clients using large library JARs, and part of the reason is this expansion step. We are considering how to address this in v3.
Option 1 - Just-in-time extraction of nested JARs from the enclosing JAR
Deployment would generate a JAR as in v2. But the ACC would not expand the entire downloaded JAR at the start of the launch. Instead it would extract an inner JAR to the temp directory only when the app client needs a class or resource from that JAR.
Option 2 -No enclosing JAR
The download that occurs as part of "deploy --retrieve" or "get-client-stubs" would deposit the individual JARs into the download directory. The ACC would not expand any JAR before launching the client.
Pros and Cons
Because option 1 delivers an enclosing JAR as in v2, if you have been copying the single downloaded file to other places that will continue to work.
Depending on the specifics of each app client, the just-in-time extraction can spread the overhead of extracting the nested JARs over the run of the client. If a particular JAR is never needed during a particular run it would never be extracted.
It is possible, of course, that a particular client might need something from all of the JARs early in the run, so the net improvement in performance would be minimal in such cases with Option 1.
Option 2 skips all expansion and would even speed up deployment by avoiding the creation of the enclosing JAR. There are at least two disadvantages:
a. If you have scripts (or work habits) based on v2 which involve downloading the enclosing JAR and then copying it elsewhere, those would break in Option 2. You would need to copy *all* of the files from the download directory to the new location.
b. Downloading two or more different app clients into the same directory works in v2 without problem. This could cause problems in Option 2 if JARs of the same name appeared in different clients. GlassFish could detect such a collision but they might or might not be OK. For example, downloading a new version of a client into the same directory would be likely to cause collisions but overwriting the old files is probably OK. Doing so when downloading different clients to the same directory is probably wrong.
One possibility: GlassFish v3 could insist that the download directory be empty (or non-existent) before using it. But that's a change from v2 behavior.
In short, following Option 2 would give better improvement in but at the cost of breaking some scenarios that work in GlassFish v2.
Thanks for staying with me through this long description. Now, it's your turn. Please post your thoughts, ideas, reactions, and comments as replies here to this topic.
Thanks in advance.
- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]
http://forums.java.net/jive/thread.jspa?messageID=333289