And another thing... Tim Quinn's Blog

Today marks the release of GlassFish v3.0 which complies with the Java EE 6 specification!  Other postings highlight a number of other areas.  I'll talk briefly about the app client container (ACC) in v3.  Much of this information appears in the release notes accessible from the main v3 page as well, but here it's all focused on the ACC.

The v3 ACC is feature-compatible with the v2 ACC.  You should see no difference in functionality, whether you launch using the appclient script or the built-in Java Web Start support...except for some exceptions I've described below.  Below I've noted a few highlights that users might find useful or interesting: stricter access from clients to other JARs in the EAR, a change in the downloaded file format, and the new embeddable ACC.

Stricter JAR Access

The Java EE 6 spec imposes stricter rules than Java EE 5 about what JARs in an EAR an app client should have access to.  In v2 an app client would see EJB modules as well as any JARs at the top level of the same EAR.  In v3 this is no longer true by default when you deploy an EAR.  You can add elements to the client manifest's Class-Path to refer to such JARs, or for library JARs move them to the library directory in the EAR (/lib by default or settable using the <library-directory> element in the application.xml).  

You can request the older, v2 behavior by specifying --property compatibility=v2 on the deploy command when you deploy an app.  Note that if you have deployed an app under v2 and then use the upgrade tool then v2 compatibility happens automatically.   

Downloaded File Changes

When you deploy an app and specify --retrieve localdir, or use the get-client-stubs command, GlassFish downloads not just the app client but other application files the client needs -- such as library JARs and some files GlassFish generates.  In v2 GlassFish would group all of these files into a single, large JAR file and download that.  Then, as the first step in any app client launch, the ACC had to expand that large JAR file into a temporary directory before it could start the client.  GlassFish v3 does not package all these files into a single large JAR.  Instead, GlassFish downloads these files individually into a subdirectory below the directory you specify on the deploy or get-client-stubs command.  

This helps the ACC launch the client faster, because there's no need to expand any files first.  

You still launch the client using the exact same command as in v2.  For example, if you deploy myApp.ear which contains the app client myClient.jar, then in v3 as in v2 you launch the client using

appclient -client downloaddir/myAppClient.jar

Note: We have never officially published or documented the format or content of the downloaded directory, but in v2 some users have copied downloaded app clients by simply copying the single downloaded myAppClient.jar file.  This no longer works in v3.  Instead, use the get-client-stubs command to download the client files to the new location.

Embedded ACC

Beginning in v3 you can "call" the ACC from inside a running Java application of your own.  (For many users the appclient command or the built-in Java Web Start support will continue to meet their needs.)  The functional spec for the v3 ACC described the API, as does the published javadoc, but the basic programming model is that your application creates an app client container builder, invokes methods on that builder to configure the app client container (security, etc.) then gets the app client container from the builder.  Your application can then pass the app client to be run to the just-configured ACC's launch method, and the client class starts with the full support of the ACC behind it.

In fact, the appclient command implementation itself uses the embedded ACC API.   

As we are working on the support for app clients in GlassFish v3, I've posted a "request-for-opinions" in the GlassFish forum.

Rather than repeat it all here, please go visit the topic.  If you develop app clients please take a few moments to add your thoughts as replies to the forum topic there (not to this blog). 

Supporting new types of applications in GlassFish v3 is as easy as 1...2...3...literally.  Implement three interfaces GlassFish prescribes, package them as an OSGi module accessible to GlassFish, and then you deploy and run apps of the new type. 

In GlassFish v3 prelude deployment is mostly what you know from v2...only quite a bit faster.

A short while ago I finished presenting the CommunityOne session on JavaFX Script and GlassFish to a gratifyingly large audience.  I was also pleasantly surprised that so many of the attendees had worked with app clients (although, admittedly, the population was somewhat self-selecting given the topic!).  I ran a little long but there were still some patient developers with interesting questions afterwards. 

In a departure (for me) from most previous formal sessions I've done, this one included a live demo, including creating some web services from scratch for GlassFish to host and building pieces of an app client that referred to those web services.  Although I showed some of the JavaFX Script code Josh Marinacci had written I didn't alter any of it!  Luckily it all ran very smoothly.

Josh did a lot of work in a short period to pull together the JavaFX part of the demo which turned out very slick.  I held up the GlassFish server-side and app client pieces.  We plan to do a bit of clean-up and then publish a screencast or the source code or both.  Stay tuned for a pointer once it's ready.

Back to JavaOne next week!

Using GlassFish app clients that access web services with Java SE 1.6 has become easier with the release of Java SE 1.6.0_04.  This is especially true when users launch such app clients using the automatic Java Web Start support that is part of GlassFish.

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

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

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.

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.)

NumberGuess example using JavaFX script now available.

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.

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.

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.