Hello, Marco.
Unfortunately, the number and sizes of JARs required to support the app
client container is much larger than we would like. Improving this is
always on our to-do list but the ACC depends on many other modules in
GlassFish which are not optimized for reducing the client-side footprint.
This affects Java Web Start launches in the way you are seeing. When a
system first launches an app client from a new GlassFish domain then Java Web
Start downloads the required GlassFish JARs. The good news is that once you
have launched an app client this way from the domain then later launches
should be much faster - Java Web Start will still check to make sure the JARs
it has in the local client cache are up-to-date but it should not download
those files again from the same domain.
As for the long delay after the download, there is some initialization that
the ACC must do before it launches your client but 30s is a very long
time. Part of that initialization work involves the client ORB contacting
the server ORB so that the names of EJBs can be resolved. This could be a
major part of the delay you are seeing.
One thing you could try is to turn on Java Web Start tracing on your client
system. One way: use
javaws -viewer
You might need to close the list of Java Web Start apps that's displayed.
Then you should see the Java control panel. Go to the Advanced tab and
under Debugging turn on the "Enable tracing" option. Then every time you
launch any Java Web Start app you will get a new .trace file. If you want
to you can also cause the Java console to be opened on every Java Web Start
launch so you can see in real time what's happening when during the launch.
To do this select "Show console" under the "Java console" settings.
The log output might shed some light on what it taking so long. Please note
at what point during the output the long delay occurs.
--
[Message sent by forum member 'tjquinn']
View Post: http://forums.java.net/node/809664