By tjquinn on Oct 12, 2007
NumberGuess example using JavaFX script now available.[Read More]
NumberGuess example using JavaFX script now available.[Read More]
Starting from an existing app client that uses injected resources, I was able to write an similar JavaFX script U/I that also used the injected resources with minimal changes to the original Java code.[Read More]
GlassFish V2 update release 1 will execute a JavaFX script you package into your app client. This is available with the current nightly builds of UR1 and will be present in the released UR1.[Read More]
Today's GlassFish V2 release includes some enhancements to Java Web Start support that allows developers to specify the icon image and splash screen image that their users will see when they download and launch app clients using Java Web Start.[Read More]
I've just completed the process of writing, with the able help of Rick Palkovic, a new article on Java Web Start support for app clients in GlassFish and publishing it in the technical articles section of java.sun.com.
Those of you who have read this blog routinely probably won't find much that is new there, but as always we're trying to reach a broader audience and promote the use of app clients in general and the Java Web Start launch feature in particular. This article should help!
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.
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.
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.
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.
Some of the details of the Java Web Start support in GlassFish have changed. You can still launch any app client you deploy using Java Web Start, so that this outward behavior has not changed. But what happens inside the app server has evolved, and you have some new options for controlling some of that processing.
Basically, we are trying to help end-users protect themselves even more vigorously from the risks of downloading programs over the network, which is after all what the Java Web Start feature of GlassFish does. Very briefly, two types of jar files downloaded via Java Web Start from the app server are now always delivered in signed form:
the appserv-jwsacc.jar (which contains key parts of the app client container that actually executes an app client), and
the generated app client jar files (which contain the contents of the original app client jar from the developer plus some additional information needed to run the client correctly).
The app server will sign them automatically for you using a self-signed certificate that is created any time you create a new app server domain. This auto-signing behavior is very convenient in a development environment since it requires you to do no additional set-up. But the default auto-signing behavior it is not very secure, because anyone can create a self-signed cert claiming to be anyone. In fact, this is why Java Web Start warns you, when it downloads a jar signed with a self-signed certificate, that the cert is invalid. The end-user can still choose to run the downloaded code, but at his or her own risk.
If you have your own certificate, you can arrange for the app server to use it instead of the domain's self-signed certificate in this auto-signing mechanism. If your certificate is in a trusted chain to a certificate authority, then your end-users can be much more confident that the code is trustworthy.
In either case, the auto-signing behavior signs every jar file with the same cert. If you want to, you can manually sign individual jars with different certs.
The steps to trigger the non-default behavior – either to have the app server auto-sign the jars with your cert or for you to sign the jars manually – are actually fairly simple, but there's some important background information that you'd need. I have written up this rough document that tries to explain this. The content will probably form the basis for the product documentation for this aspect of the Java Web Start feature, so I would very much appreciate any feedback people have on the description as well as the feature itself. I already know of several ways in which I would like to improve the overall process, but I'd love to hear what others have to say.
Today is our launch of the Sun Java System Application Server 9.0 Platform Edition beta. Download this software and use it to build and deploy enterprise applications that conform to the latest Java EE 5.0 specification.
This is one of Sun's products based on the GlassFish project. As such, it is the first of our app server product downloads (other than the GlassFish builds themselves) to support launching app clients using Java Web Start technology. I've written quite a bit about this lately, and below are some links to those notes. There are many other new features in this download. Go to the download page to find out much more. And I'll be adding new entries to the blog about the Java Web Start feature soon.
You are probably used to just putting these settings on the appclient command line like this:
appclient -client myclient.jar -Dcolor=red -shape rectangle
It's not quite that simple when you launch the client using the Java Web Start feature in GlassFish. But it's not too bad.
You can specify arguments and properties by adding a query expression to the URL you use to launch your app client. Any query parameter with the name arg is passed exactly as-is as a command-line argument to the app client. If your client expects arguments like this:
then you will pass two arguments like this:
(See my earlier posts about the default URL path and how you can customize the path.) Note that the minus sign that introduces the “shape” keyword is included in the first query parameter value. It's your client – not any GlassFish code – that interprets the minus sign as a keyword introducer, just as with any Java application you might write that deals with command-line arguments. That's why you set “-shape” and “rectangle” up as two separate arguments in the query string.
Suppose your client works with a property that you might normally specify on a Java command line using
for example. You can specify properties via the Java Web Start feature using prop query parameters in the URL:
Notice that the GlassFish Java Web Start feature will interpret everything after the first equals sign in the “prop” expression as <property-name>=<value>. So in this example the property “color” will be set to the value “red.” The setting ?prop=equation=y=2\*x would set the property “equation” to the value “y=2\*x” when your client is started. The setting ?prop=xyz would set the property “xyz” to the empty string.
You can combine arguments and properties in any order. Your client will receive the arguments in the order they appear in the query string. Here is an example that assigns the arguments and properties from the earlier examples in one URL:
You probably do not want end-users to have to type such URLs into their browsers to launch the app client. Consider building a web page with a link that includes the query string. Or perhaps a dynamic page would gather some input and prepare the URL for the user accordingly.
We think most users will welcome the ability in the GlassFish project to launch app clients using Java Web Start technology, but it may not be for everyone. Developers and administrators can control for each individual app client whether end-users can use this feature or not.
Before the app server starts Java Web Start support for an app client it makes sure that the developer has declared the app client eligible for Java Web Start access. Before the app server actually responds to requests for an eligible app client it makes sure that the administrator has enabled the app client for Java Web Start access. Both conditions must be true, and both are true by default.
In earlier posts I have described some additions to the sun-application-client.xml runtime descriptor. The new element eligible lets developers set whether the app server should support Java Web Start launches of that app client. Here's an example:
<?xml version="1.0" encoding="UTF-8"?> <sun-application-client> <java-web-start-access> <eligible>false</eligible> </java-web-start-access> </sun-application-client>
The default is “true,” but in the example the developer has chosen to turn off Java Web Start launching for this app client. End-users will still be able to use the appclient script to launch the app client as in prior releases of the app server but they cannot launch it using the Java Web Start feature.
Redeploy the app client if you decide to change its “eligible” setting.
The administrator can control which eligible app clients actually can be launched using the Java Web Start feature. The administrator cannot make an app client accessible to Java Web Start if the developer marked it as ineligible. But the admin can enable or disable eligible app clients. In the current release of GlassFish administrators enable or disable this support at the application level. This means that an administrator enables or disables all app clients within an application together. If you deploy an app client by itself, then the administrator can control it individually. App clients deployed as submodules inside an EAR are all enabled or disabled as a unit.
Administrator use the asadmin command to control this setting and use the set command and “dotted notation” to do so. An example works best here. Support you deploy an application using
asadmin deploy –name MyTestApp testapp.ear
The administrator can use
asadmin set domain.applications.j2ee-application.MyTestApp.java-web-start-enabled="false"
where domain is the name of the domain in which the EAR was deployed. Whatever value you assign governs all app clients in that application.
On the other hand, if you deployed an app client in its own module like this
asadmin deploy -name MyClient testclient.jar
then you can use
asadmin set domain.applications.appclient-module.MyClient.java-web-start-enabled="false"
to control that app client's setting.
If you disable Java Web Start support you can reenable it later by setting the value to “true” in these commands. Keep in mind that if you undeploy an application or an app client, the app server discards such settings. When you deploy the application or app client again later the Java Web Start feature will be enabled by default for the relevant app clients unless and until you change it again.
As we planned the Java Web Start feature we expected that developers and administrators would want some level of control like this. We're very curious to hear from the community what use people are making of the Java Web Start feature, whether we have provided the right type of control for developers and administrators, and what changes you might want to see – or implement yourself. Let us know!
An earlier post explained the default URL that the GlassFish project's Java Web Start feature app server recognizes for launching a particular app client. Today I'll describe how you can control what that URL will be.
Actually, what you can control is the path part of the URL. The host and port will just be those of the running app server. Yesterday I explained how to customize the splash screen which end-users see when they launch an app client using the Java Web Start feature – simply by setting some values in the sun-application-client.xml runtime deployment descriptor for the app client. That's how you set the URL path as well. This example shows setting the path (using the context-root element) and the vendor:
<?xml version="1.0" encoding="UTF-8"?> <sun-application-client> <java-web-start-access> <context-root>/InventoryClient</context-root> <vendor>Sun Microsystems, Inc.</vendor> </java-web-start-access> </sun-application-client>
Once you deploy the app client with this runtime descriptor your end-users can use http://host:port/InventoryClient to launch it.
That's all you need to do!
News and musings on the technology I work on at Oracle.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.