Thursday Dec 13, 2007

Why does GlassFish warn about not finding referenced JAR files?

The warning message "Error attempting to process extensions from the manifest of JAR file..." during a client launch might not always indicate a problem.

[Read More]

Friday Nov 09, 2007

JavaFX Script in a GlassFish app client - featuring persistence this time

This example of an app client with JavaFX uses a local persistence unit to implement a simple address book application.

[Read More]

Friday Oct 19, 2007

Midwest Java Technology Days - Chicago event

I spent yesterday at Sun's Midwest Java Technology Days event in Chicago (actually, Rosemont, a suburb right next to O'Hare).  I live and work in the Chicago area and the Sun marketing folks who ran the event were nice enough to let me attend.  I had a chance to attend some of the sessions and talk informally to several individuals and small groups about GlassFish.  As a software engineer (with a checkered past that includes stints as a consultant and university instructor as well as a software engineer and architect) I usually find it refreshing, humbling, and encouraging to spend time with people actually using the sort of software I work on , and yesterday was no exception.

One very interesting conversation I had was with a project manager who wanted to know how open source projects really work.  From his point of view as someone who might consider using open source software in a project for one of his clients. (I answered from my experience on GlassFish, not that this makes me much of an expert.)

  • How to ensure quality of the code in the project. (Require clean unit test runs and peer review before changes go into the repository.  Run automated builds and tests.  Promote thoroughly-tested weekly builds and releases we do on GlassFish.) 
  • What kind of support can people in his position get for open source projects.  (No-cost advice from the community and paid product support from a vendor like Sun.)

(It was far less of a sales pitch than I just made it sound like; I really enjoyed that conversation.)

One developer who had downloaded GlassFish wanted to know how to do something specific that would be equivalent to what he was doing with another app server.  Luckily for me, GlassFish does what he wanted and I was able to point him in the right direction.  Maybe the most rewarding single moment of the day for me was when this developer left our conversation clearly very excited about working much more with GlassFish.

In case anyone I met with reads this, many thanks for taking the time to talk.

Tuesday Oct 16, 2007

Style Change

I decided that the old style, though eye-catching, was just too hard to read.  I have also added a hit counter that is embarrassingly low (I tell myself this is because I have only just now added it and it will go up quickly.)

Friday Oct 12, 2007

NumberGuess example - JavaFX script in an app client

NumberGuess example using JavaFX script now available.

[Read More]

Thursday Oct 11, 2007

Using injected resources from JavaFX Script in an app client

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]

Wednesday Oct 03, 2007

Preview of JavaFX Script support in GlassFish V2 UR1 Application Clients

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]

Monday Sep 17, 2007

GlassFish V2 and out-of-the-box Java Web Start support for App Clients

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]

Monday May 07, 2007

GlassFish V3 technology preview available

You can download and use the GlassFish V3 technology preview today!

[Read More]

Tuesday Apr 24, 2007

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!



Wednesday Mar 14, 2007

Specifying icon and splash images for Java Web Start launches of app clients

Java Web Start allows the developer to specify his or her own files to use for the icon and splash screen images. The GlassFish support for launching app clients using Java Web Start now allows the app client developer the same ability.

[Read More]

Wednesday Oct 11, 2006

Addressing locked JAR problems

Many users have encountered problems on Windows when JAR files remain open, causing problems during undeployment and redeployment. Recent changes to GlassFish will resolve many of these difficulties.[Read More]

Tuesday Oct 10, 2006

Open Source and Product Support

Open source and product support are not mutually exclusive. In this brief tale I describe a recent experience that shows that people can get good support (lower-case "s") from the community and yet paid Support (upper-case "S") from a product vendor has its own added value.[Read More]

Wednesday Aug 02, 2006

Tool for Diagnosing Failed GlassFish Redeployments/Undeployments on Windows due to Locked JARs

GlassFish redeployments and undeployments can fail on Windows if one or more JAR files in the application is opened but never closed. There is now a tool (unsupported!) that you can use on your own system to help identify which code has opened the file.[Read More]

Sunday May 14, 2006

How does GlassFish know about Java Web Start app client URLs?

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.

GlassFish Java Web Start


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.


« September 2015