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.
Eligible App Clients
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.
Enabled App Clients
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.
What do you think?
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!
