New article published on about GlassFish support for Java Web Start

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  

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!




Thanks for this article. I have been deploying my Swing apps using webstart (they use a JAX-RPC web service in a J2ee 1.4 container) for a few years. What additional features does the ACC give me. I have not used GlassFish that much. Is this ACC a GlassFish specific thing? Secondly one difference I found out with WebStart is its interaction with JAAS. With a stand-alone Swing app I could supply login modules that authenticate, get the Subject, Principals and JAAS permissions. I could then use the permissions for access control in my Swing app. However all WebStart docs I have seen require an <all-permission> in the jnlp file. Without this even a signed webstart app does not work. I have been searching various forums for sometime now and I have not seen a good solution to this problem. Probably not too many are using JAAS and Swing? We use JASS with our web apps and would like the same functionality in the WebStart apps. May be ACC lets us do some of these in a better way?

Posted by Vamsee Lakamsani on June 10, 2007 at 04:06 AM CDT #

Hello, Vamsee. The idea of an application client container (ACC) is described in the Java EE spec. The basic idea is that the ACC provides services that make it easier to write client programs that use enterprise components (like EJBs), much the same way an EJB or web container makes it easier to develop those types of components on the server side. The GlassFish ACC provides automatic support for annotations and dependency injection, security, and logging for example. This link to the GlassFish documentation on developing clients will explain a little more: To answer your specific questions about security and Java Web Start, Java Web Start enforces a security sandbox similar to applet security sandboxes to protect users from downloaded software that might harm their systems. As you point out, Java Web Start requires that if the downloaded code needs to do things that the sandbox does not permit then the downloaded JAR must be signed and the JNLP that lists that JAR must specify <all-permissions>. When Java Web Start starts to launch the application it makes sure that the code is to be trusted, either by prompting the user or by checking that the certificate used to sign the JAR can be traced to a trusted certificate authority. The GlassFish ACC does help with security in the following way. (Again, reading the Java EE platform spec section about the ACC will help as well.) A developer can write his or her app client code that refers to a guarded EJB without having to write the authentication code. When the app client tries to contact a guarded EJB the ACC automatically prompts the user for a username and password. The ACC provides a simple form for this purpose that it uses by default, but the developer can provide a custom one instead if he or she wants to. The ACC works with the back-end to perform the actual authentication to make sure that the username and password the user entered should be granted access to the EJB.

Posted by Tim Quinn on June 11, 2007 at 01:33 AM CDT #

Post a Comment:
  • HTML Syntax: NOT allowed

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.


« February 2016