Hello, Pablo.
The size - and therefore the download time - of the client bits for GlassFish is something we have always wanted to reduce, but the app client container (which is what actually executes the app client you deploy) depends on many parts of GlassFish. Few of those other parts have been divided into "client" and "server" pieces so, unfortunately, in many cases, GlassFish has to download more than it really needs to the client. Further, recent security-related changes in Java Web Start itself make it necessary for us to sign the GlassFish system JARs. This is something that is done only once within a domain, but it is done during the first Java Web Start app client launch after a new domain is installed or created, so that first user really pays the price.
We continue looking for easy ways to reduce the footprint and we hope to accomplish more for the planned upcoming 3.1 release of GlassFish Server Open Source Edition.
If you want to continue using Java Web Start to launch your client but you want to spare your users that first-time pain, you could consider using the "javaws -import" command on each end-user system to preload the cache. Then, as you pointed out, only the JARs which change - which will typically be your application JARs - will be downloaded after that.
If you want to use the appclient script to start your app clients, then you can use the package-appclient script on the server to create a JAR containing all the GlassFish system files the app client container will need. This does not include your client files. You could use the
asadmin get-client-stubs
command to retrieve the JARs for you client, then you could launch the client using the appclient script. This approach does not do any of the automatic up-to-date checks which Java Web Start offers.
I wish I had better news, but I hope this at least helps to explain the situation.
- Tim
[Message sent by forum member 'tjquinn']
http://forums.java.net/jive/thread.jspa?messageID=478012