Well - since you've asked - Warning: long as well ;-):
I'm using JNLP for some standalone RCP apps (one with a commercial background), only one of those is an EACs. The latter was written about 5-6 years ago and targeted towards JBoss, since its JNP over SSL was the only proto, which did not make a lot of headaches, when firewalls come into play.
Access is provided via the JnlpDownloadServlet coming with the JDK via:
[code]
<url-pattern>*.jnlp</url-pattern>
<url-pattern>/app/*</url-pattern>
[/code]
etc.. Why:
1) IIRC 3-4 years ago, when gf app client was "announced" I tried to make use of it. Unfortunately because documentation was so shallow, or maybe because it didn't simply have, what is/was needed and too much undocumented magic I gave up (sorry, it is a long time ago ...). And since all requirements can be solved via JnlpDownloadServlet, there was actually no need to waist more time, i.e. to dive deeper/try harder to find some useful docs ...
2) Depending on the app, often transport-guarantee:confidential (even if apps are signed) is required
3) Depending on the app, access to it (i.e. to be able to download) requires authentication and authorization
4) Jars to download need to be signed, but not with the certificate of the server which serves those
binaries.
5) Jars to download need to be as small as possible (i.e. < 1 MiB)
IIRC gf sampled them on the fly and only occasionally with pack200
We do not want the "on the fly" stuff - why to bother the server, when we already know BEFORE
deployment, what is needed?
So we use and get the best results wrt. size in 3 stages: Proguard -> *.jar; *.jar -> *.jar.gz; *.jar -> *.jar.pack.gz and put all those variants into the *.war/ear (reduction usually to 5..10% of the original).
6) Usually a project contains packages required by the server (e.g servlets) only, packages required by the client only (e.g. GUI aka swing stuff) and stuff required by server and clients (e.g. POJOs, Utils). IIRC there is no way to tell that gf ... (BTW: we use a std layout: $domain.{client|common|server} ...)
7) Almost all apps have a certain "core" and "supporting" stuff. So we have to be able to give the
right hints to javaws (eager/lazy ; package recursive parts).
8) Yes, specifying all information like homepage, icon, offline-allowed, shortcut is required!
9) Nice to have short std access URLs, like
http://$domain/$appname/start.jnlp and/or
http://$domain/$appname/app/[$dontcare]
10) Nice to have: pass params e.g.
http://$domain/$appname/start.jnlp?Xmx=4g&lang=en
Not sure, if this helps, but at least you get/can deduce some real world requirements.
BTW: To reduce all the template stuff/boiler plate code - a raw idea:
bla.war: WEB-INF/lib/client/{*.jar[.pack[.gz]],start.jnlpx} and the server does the rest ...
Regards,
jel.
PS: Sorry for not reading your 8-pager - no time and formatting makes it too challenging for me ...
[Message sent by forum member 'elkner']
http://forums.java.net/jive/thread.jspa?messageID=476240