Hi, Roll.
I have actually put a fair amount of thought - spread over a long time - into how we might do this. In fact, relatively soon I plan to publish a very early proposal for this on the GlassFish wiki and start gathering community input.
My thinking has been to allow the developer to include a JNLP in the app client submodule, as you mentioned, and have the developer point to it using a new subelement of <java-web-start-support>.
GlassFish already does substantial substitution in generating the JNLP documents, so the framework is already there and in use. The merging step is more involved but quite doable. (I had some simple prototype logic working locally as a simple proof-of-concept.) I have been thinking of asking developers to follow the normal JNLP format, not a specialized one. For one thing, that would allow the JNLP format to evolve without requiring parallel updates to the GlassFish customization format.
There are several other interesting but solvable issues. For example, the current implementation maps the logical paths in the URLs to the physical locations of files in the GlassFish directory. (Among other things, this prevents rogue users from using the Java Web Start support from browsing arbitrary parts of the GlassFish directory.) If a developer's custom JNLP refers to other JNLPs also packaged in the app client, which I'd like to allow, then GlassFish would need to detect that and add such extension JNLPs to its internal maps. Not impossible, but one of those things we'll need to remember to do.
Anyway, I'll post a note in this forum pointing to the proposal when I get it published. I'd welcome your and everyone's continued comments and ideas there.
By the way, such an addition if it appears would probably be in the GlassFish V3 timeframe...just to set people's expectations.
- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]
http://forums.java.net/jive/thread.jspa?messageID=233304