Hi Tim,
here are the results of my investigations that may be useful for the community.
I've been able to recreate a custom jnlp from the one auto generated by glassfish.
I can now still use the ACC to launch my application (so i have all with all the features, security, dependency injections etc) and deploy my application to users who have low bandwidth to our servers.
Here is how it is done:
We assume that users with low bandwith to our servers have some local central repository accessible where the bandwidth is not a problem to them (like shared file or web server on their intranet ). So the idea was to copy all the ACC needed jars there and let the application client jar be deployed from our server.
This is because we assume that the acc jars dont need to be changed as often as the application evolves (only in the case where the app server is upgraded) so this manual intervention can be acceptable .I hope you see the idea.
I wanted to go further and also make the third party jars the application needs to be locally accessible too but i've hit some classloader problems i ll detail later.
So, here is the logical structure of the custom jnlp:
E:/acc is the shared folder, located on their intranet file server, the users will have access from their pc.
* main.jnlp:
<jar href="file:///E:/acc/appserv-jwsacc.jar" main ="true"/>
<extension href="main-ext.jnlp" />
<extension href="client.jnlp" />
and all the properties needed by the acc and particularly:
<property name="com.sun.aas.jws.iiop.defaultHost" value="glassfish_server"/>
* main-ext.jnlp
codebase to "file:///E:/acc" and all the jars needed by the ACC are stored there and referenced here
* client.jnlp
<jar href="
http://glassfish_server/__JWSappclients/__application/MyApp/MyAppClient.jar"/>
I tried to make the 3rd party jars referenced locally too (with an extension or jar elements), having the client jar lighter
(doing so in netbeans, unchecking the packaging options on them) but I've hit some mysterious (to me) classnotfoundexception, so
The client jar is the normal one .
I know that the solution is not really portable as is, but some ideas came on top of my head.
The shared folder can be parametrized, for example making the jnlp delivered by a jsp and passing to it the shared folder location parameter, which can be unique for each user like that.
Or more generally, i was thinking of a feature which could automatically generate a zip package with the jnlps and all the ACC jars which can then be copied on a central repository for low bandwidth users (in the same idea of the download client stubs feature).
This package could be also a war application (including the jnlp servlet), which can be deployed on a remote servlet container (locally to the users, bandwidth talking) which could act as a local "repository" server.
Just some ideas which could help the low bandwidth users and developers not to feel too much the pain about application clients ;)
Yves.
[Message sent by forum member 'ygillet' (ygillet)]
http://forums.java.net/jive/thread.jspa?messageID=209683