By Tim Quinn-Oracle on May 14, 2006
How does GlassFish know how to respond to the Java Web Start URLs?
If you have used or read about the new Java Web Start support for app clients in GlassFish, then you know about the URLs you use to launch app clients via Java Web Start. You know that the app server provides defaults for the URL paths for each app client, and that developers can override those defaults in the runtime deployment descriptor for the app client. Those URLs specify regular http requests, which you might (correctly) expect are handled by the web container in the app server.
But how? The application you built and deployed contains no web component to respond to such requests.
ad hoc Servlets
The answer is that the Java Web Start support uses a new enhancement to the web container known as the ad hoc servlet mechanism. Jan Luehe has blogged about this and he describes very nicely how this works from the web container's perspective. Briefly, this feature provides an API that allows the app server to create servlets in the web container at runtime, without a developer building a web app or an administrator deploying one. Servlets created this way can also be removed using calls to the API. This ability is an absolute necessity for Java Web Start support. This blog gives a quick look at how the Java Web Start support uses this feature.
How does the Java Web Start support use ad hoc servlets?
When you deploy an application that is an app client or contains one, the app server checks to see if the developer wants the app client to be eligible for Java Web Start support. If so, the app server then checks to see if the developer specified a URL path to be used to access the app client. Both of these optional settings are in the runtime deployment descriptor (sun-application-client.xml) for the app client. Unless you specify otherwise, the app server marks all app clients eligible for Java Web Start support and builds default URL paths for each.
Now that it has either your specified URL path or the default one, the app server needs to ask the web container to respond to that path and route requests for that URL to a Java Web Start support system servlet – one that GlassFish provides automatically as part of the app server. (Just to be clear, this servlet is part of GlassFish, not part of the Java Web Start technology itself that is part of Java SE.) The app server does this by using the ad hoc registration API that com.sun.enterprise.web.WebContainer provides. From that point on, the web container will route requests addressed to the Java Web Start path for the app client to the Java Web Start support system servlet.
This app server registers the URL path when you deploy an app client or when the app server starts up and initializes a previously-deployed app client. Similarly when you shut down the app server or undeploy an app client, the app server uses the ad hoc registration API to unregister the path for that app client. By asking the web container to unregister the app client's path, we break the connection between that path and the app client. From then on, requests to that URL will follow the normal web container processing which will typically result in a 404 error because the web container will no longer recognize that URL as one that it should respond to.
“Why do I need to know this?”
The good news is that you don't need to know any of this to use the Java Web Start support for app clients in GlassFish. Perhaps the even better news is that this feature of the web container is generic and is already being used not only for Java Web Start support for also for web services support. Jan's blog tells more about that and about the inner workings of the ad hoc mechanism itself. But we thought some people might be interested in learning how this actually works behind the scenes.