| Web app-centric model The developer uses a value of the form
path-to-WAR-in-EAR!path-to-JNLP-in-WAR
for the
element in
glassfish-application-client.xml
. The developer packages any referenced JNLPs and any extra JARs in the web application given by the
expression. GlassFish sets the
in the generated JNLP to the web app's context root. As a result relative hrefs in the developer's JNLP are resolved within the web app. Dealing with the URL is challenging in the web app-centric model. Each JNLP document's
must be an absolute URL. In the app client-centric model GlassFish uses placeholders in the JNLP document which our dedicated Grizzly adapter knows to replace before serving the JNLP document. In the web app-centric model, the Web container's default servlet or a developer-provided servlet would serve the JNLP document. A developer accustomed to building non-app-client Java Web Start apps would be familiar with the general problem of having to replace tokens in JNLP documents at request-time and would almost certainly have used a servlet to accomplish this in his or her past implementations of regular, non-app-client Java Web Start apps. (Java Web Start provides an example servlet that does this.) GlassFish would rely on the developer providing the servlet and the mapping so the servlet handles .jnlp requests and performs any token substitution correctly. In the web app-centric case GlassFish would not own the
setting. Instead the developer's JNLP would set that value using whatever placeholders his or her servlet was written to process. This is further complicated by the fact that with a developer servlet handling the .jnlp files then when GlassFish combines the developer JNLP with the GlassFish-generated JNLP GlassFish would have to make sure that the generated JNLP was served when an HTTP request for the developer's JNLP arrived. We would not want to overwrite the developer's file in the expanded web app directory. If the EAR had been directory-deployed then we'd be writing into the user's directory which we have avoided up to now. Plus we would have altered what was otherwise the as-deployed contents of the user's app. Another option: Intercept all requests for .jnlp content (using a valve?) to see if the request is for a web app-centric app client JNLP. If so, then GlassFish would merge the developer's JNLP with the GlassFish-generated JNLP. A question is how expensive such intercepts are, considering at some level they would affect all inbound traffic to Grizzly.
|
