Preview of JavaFX Script support in GlassFish V2 UR1 Application Clients

I have added an early, technology preview implementation of JavaFX script support to the app client container in GlassFish V2 update release 1. 

Note:  We may choose to provide this feature in some other way in the future.  This is an early-access, technology preview feature. One goal of this early implementation was to be minimally disruptive to the existing app client container code path and public interface, including the appclient command-line syntax.  Even so, the implementation is (we believe) fully functional.

How to use the feature
Using Resource Injection
Using Command-line Arguments
Other Hints
What about Java Web Start?
Tell us about your Apps
Trivial sample

How to use the feature

You need to do these things to use this early-access feature:

  1. Download (or build) GlassFish V2 update release 1.  Nightly builds contain the scripting support changes.
  2. Place the .fx file you want to execute in your app client making sure the manifest specifies the Main-Class as the path to your script.  Then deploy the app client (or the EAR that contains it) as usual.  When you launch the app client (using either Java Web Start or the appclient script), GlassFish will use the Main-Class: entry from the app client's manifest to look first for a script at that path.  If no script is found, the Main-Class is used to load and run the .class as before.  (Using the appclient script you have always been able to override the manifest setting using the -mainclass option and you can continue to do that.  Just remember that you are specifying the dotted path to the main class or script without the .class or .fx file type.)
  3. Make the JavaFX library JARs available to the app client container.  For now probably the easiest way to do this is to package the JavaFX JARs with your EAR. 
  4. Run the client on a Java SE 6 system.  The scripting support required from the Java runtime is not available in Java SE 5.

Using Resource Injection

The app client container (ACC) that actually runs your app client will also search the app client for an actual main class using the same Main-Class element from the manifest.  The ACC will not run this class if it finds a script of that name, but it will process that class for annotations and inject any required references - to EJBs or web services, for example.  This means that your JavaFX script can very easily make use of those injected references using the JavaFX script features for accessing Java classes and objects. My suggestion is to write public static convenience methods on a Java class in your app client (it could be the main class or some other class) that refer to the resources that will be injected into the main class.  Then your JavaFX script can refer to those convenience methods to work with the back-end resources.

Using Command-line Arguments

In case you need them, when launched by the ACC the JavaFX script has access to any command-line arguments specified in the launch via the JavaFX script variable

arguments:java.util.Collection

For a long time I have used a simple Java example for private testing that just displays in a list box all the command line arguments passed to appclient.  Here is how I accomplished the same thing in my test JavaFX script:

ListBox {
  cells : bind foreach (arg in arguments:<<java.util.Collection>>.toArray())
    ListCell {
      text: (String) arg
    }


(JavaFX script does a really good job of encouraging the model-view-controller design approach.  The "bind" concept fosters this.)

Other Hints

  1. Be sure to set the main Frame in your JavaFX script to exit on close:

      onClose: operation() {System.exit(0);}

    For me, at least, the JVM stayed running after the top-level Frame was closed if I did not do this.

  2. Although the main motivation behind this made was JavaFX script support, the ACC will support any scripting engine that is present in the runtime environment.  So, for instance, if you make the JavaScript libraries available to your app client you can have the ACC run a .js script you write and package in the app client.  
In fact, this works for any scripting engine that advertises itself to the runtime according to the requirements in JSR-223, the scripting JSR.  Using the standard APIs the ACC finds all registered scripting engines and gets from each one its list of supported file types.  Then the ACC searches for a script of one of those types using the Main-Class for the script name.  As soon as it finds one the ACC launches the script using that engine.  

I would not assume that the order in which scripting engines are made available through the API is not predictable, so my advice is to avoid packaging scripts of different types but the same name into one same app client in the same location where they could be found by the Main-Class searching algorithm I summarized above.

What about Java Web Start?

You can launch your app client using the built-in Java Web Start support for app clients as well as the appclient script and still get the same JavaFX support.  You don't need to do anything differently.

Tell us about your Apps

If you use this feature, please let us know by adding a comment to this entry - preferably with a link to some information about your app or to your app itself!

Trivial Sample

Here is the ridiculously trivial sample JavaFX script I wrote for displaying the command line arguments.  (I want to post a better example that uses injected references to EJBs as I described earlier.  I just have not had the time yet.)  I provide the sample here as-is with no warranty and no support and no claim that it's particularly clever JavaFX script!  There may well be better ways to accomplish this with JavaFX script.  I do not claim to be anything close to an expert on the language.  But I'm learning!

/\*
 \* Main.fx
 \*/

import java.lang.System;
import javafx.ui.\*;


Frame {
  title: "JavaFX via GlassFish!"
  width: 300
  height: 250
  centerOnScreen: true
  content: BorderPanel {
    top:
      Label {
        text: "Sample Application Client U/I"
        font: Font {
          faceName: "Arial"
          size: 18
        }
      }
  center: BorderPanel {
    top: TextField {
      text: "Below are the command line arguments received during launch"
      editable: false
    }
  }
    center: ListBox {
      cells : bind foreach (arg in arguments:<<java.util.Collection>>.toArray())
      ListCell {
        text: (String) arg
      }
   }
  }
  visible: true
  onClose: operation() {System.exit(0);}
}



Comments:

Good work, Tim.

Posted by Kedar Mhaswade on October 03, 2007 at 06:28 AM CDT #

What about a real life situation where firewall prevents the RMI/IIOP from working ?.

Posted by gustav trede on October 03, 2007 at 09:45 AM CDT #

[Trackback] GlassFish v2 already has Java WebStart support ( TA entries ) but Tim just added JavaFX Scripting support

Posted by Mirror on October 03, 2007 at 11:06 AM CDT #

[Trackback] GlassFish v2.1 is out today, and as for v2.0, here is a list of cool features the official documentation is not talking about: Comet, Cometd, Apache, JavaFX, etc...

Posted by Jean-Francois Arcand's Blog on December 19, 2007 at 09:44 AM CST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

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.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today