glassfish-webtier

Executing Groovy Programs in-memory

Sat, 14 Apr 2012 22:37:07 +0000

Now that we've gone over some Groovy basics, it's time to switch back to writing in the Java language, and talk about how to run Groovy programs inside your Java programs. Like most general purpose programming languages, there's more than one way to do things in Groovy, and that's never more true when it comes to executing Scripts - I once counted 7 ways to use the String "System.exit(0)" to shut down the VM, and I'm quite sure that I missed a few. For this example, we'll use the method I consider to be the best and most extensible, which uses the class GroovyShell.

Before we get started, be sure to include the Groovy libraries in your Java class path, so that you can use the same classes as Groovy. In the current distro, it's the file named groovy-all.jar. Once that's there, you should be able to execute the following code:

import groovy.lang.GroovyShell;
import groovy.lang.Script;

public class Test {

    public static void main(String[] args) {
        <strong>GroovyShell shell = new GroovyShell();</strong>
        <strong>shell.evaluate("println 'hello world'");</strong>
 
    }
}

I won't bother including the surrounding cruft in the future, but wanted to illustrate that this is just a (very) simple Java program. We create a GroovyShell object, and call the evaluate method on it, passing a String. That String, in turn, is evaluated by the Groovy parser, a class is (invisibly) created, and the class is run - the end result is that "hello world" is printed to std out.

There's a problem with this code though - it's kinda slow. About 10ms on my machine (for a warm run, where all the required classes are already loaded and initialized - the initialization is actually 300ms, but that's a one time hit). Now, that might be perfectly acceptable for your application - but if you're going to be executing this thing multiple times, that could really add up in a multiuser environment. One of the things that's happening here is a full compile of the generated script code. And while compiler technology has certainly gotten faster in the last few years, it'd be nice to skip that step on occasion. The GroovyShell API offers a way to separate out the compilation and execution steps.

GroovyShell shell = new GroovyShell();
<strong>Script script = shell.parse("println 'hello world'");</strong>
<strong>script.run();</strong>

Here, we've separated out the compile phase from the run phase. The compile phase still takes 10ms, but the run phase only takes whatever the Java class run time is. In this case, it's a sub 1ms run time. This separation also opens things up for us to use other APIs as well, and we're going to use this technique going forward.

Under the hood, here's what's happening: Groovy is taking your input String, and converting it into a class, of type Script. Script contains a method, run. The contents of that run method are populated with the parsed contents of the String you pass in as an argument. So, when we call script.run(), the println method is called, which prints out the message. One last important note is that the run method actually returns Object - so we can also use these scripts to compute values. And if you don't specify a return, the final statement executed in the script will be automatically returned as the value. Thus, if the final line in your script is "x < y", the run method will return a Boolean equal to whatever the result of the comparison is. You can also define inline methods (as we did in the intro post I did), and those methods will be placed on the generated Script - you can even access those methods via reflection.

Next up, using the Groovy Binding class.

(As usual, this article is cross posted on my main blog site.)

A quick introduction to the Groovy language (part 2)

Sat, 14 Apr 2012 22:35:44 +0000

In my previous post, I started with a simple Java program (which also worked in Groovy), and slowly stripped out the cruft until I was left with the following Groovy script:

def sayHello(name) {
    println("Hello $name!")
}
def name = 'world'
sayHello(name)

<br />

Now, let's add a little change to use an array. Since Groovy is a rough superset of Java, you might be tempted to do something like:

def sayHello(name) {
        println("Hello $name!")
}

<strong>String[] names = {"SintSi", "Kaitlyn", "Keira"}

for (String name : names) {
    sayHello(name)
}</strong>

<strong><br /></strong>

But this won't work. This is one place where Java syntax differs from Groovy's. To create a static array, you'd instead do:

def sayHello(name) {
        println("Hello $name!")
}

String[] names = <strong>["SintSi", "Kaitlyn", "Keira"]</strong>

for (String name : names) {
    sayHello(name)
}

As before, we can eliminate the type declarations:

def sayHello(name) {
        println("Hello $name!")
}

<strong>def</strong> names = ["SintSi", "Kaitlyn", "Keira"]

for (<strong>def</strong> name : names) {
    sayHello(name)
}

But a more Groovy way of doing the same thing would be to use the "in" keyword:

def sayHello(name) {
        println("Hello $name!")
}

def names = ["SintSi", "Kaitlyn", "Keira"]

for (<strong>name in names</strong>) {
    sayHello(name)
}

Note that under the hood, this code is no longer creating an array - rather, Groovy is (invisibly) creating an ArrayList. This gives us a number of new options - for instance, sorting:

def sayHello(name) {
        println("Hello $name!")
}

def names = ["SintSi", "Kaitlyn", "Keira"]

<strong>names.sort()
</strong>
for (name in names) {
    sayHello(name)
}

You can also add and remove entries to the list, like so:

def sayHello(name) {
        println("Hello $name!")
}

def names = ["SintSi", "Kaitlyn", "Keira"]

<strong>names += 'Jim'
names -= 'SintSi'</strong>
names.sort()

for (name in names) {
    sayHello(name)
}

But this still isn't the way that many Groovy coders would do it. They'd probably use the built in method each, which takes a closure as an argument. If you aren't already familiar with closures (I knew them already from JavaScript), they're similar in many ways to method pointers. And you might as well start learning about them, they're coming to Java (finally). To use a closure, you define it using enclosing curly braces, and you can call it with the call method, like so:

def sayHello(name) {
        println("Hello $name!")
}

<strong>def clos = {name -&gt; sayHello(name)}
clos.call('world')</strong>

This will print "Hello world!". Note that if you're trying this in groovyConsole, you'll see an additional value at the end - this is because Groovy scripts always return the last value as the return value, and groovyConsole is showing you the value of the names ArrayList. In this example, the "name ->" preamble defines a single parameter that the closure takes. Now let's use the closure with the each method:

def sayHello(name) {
        println("Hello $name!")
}

def names = ["SintSi", "Kaitlyn", "Keira"]

names += 'Jim'
names -= 'SintSi'
names.sort()

def clos = {name -&gt; sayHello(name)}
<strong>names.each(clos)</strong>

Under the covers, names.each is iterating through the collection, and passing each value to the closure as the first parameter, just as in our previous example. We can simplify this by creating the closure in place. And since in Groovy, method parenthesis are optional when the method takes one or more parameters, we can say:

def sayHello(name) {
        println("Hello $name!")
}

def names = ["SintSi", "Kaitlyn", "Keira"]

names += 'Jim'
names -= 'SintSi'
names.sort()

<strong>names.each {name -&gt; sayHello(name)}</strong>

Which is pretty darn readable. One more thing: by default, the first parameter of a closure is named "it". So, you could instead say:

def sayHello(name) {
        println("Hello $name!")
}

def names = ["SintSi", "Kaitlyn", "Keira"]

names += 'Jim'
names -= 'SintSi'
names.sort()

names.each {<strong>sayHello(it)</strong>}

That's it for now. If you've followed along so far, you've gotten more than enough Groovy under your belt to deal with anything you might see in my coming posts, as well as being able to say "Sure, more or less", when someone says "Do you know any Groovy?"

(As usual, this article is cross posted on my main blog site.)

A quick introduction to the Groovy language (part 1)

Sat, 17 Mar 2012 15:51:40 +0000

Before I start talking about using Groovy's capabilities to create a DSL (mostly in Java), let's take a few minutes to go over what Groovy is.

Groovy is a general purpose scripting language which runs on the JVM, and can largely be viewed as a superset of Java. Take the following program:

public class Hello {
   String name;
    
    public void sayHello() {
        System.out.println("Hello "+getName()+"!");
    }
    
    public void setName(String name) {
        this.name = name;
    }
    
    public String getName() {
        return name;
    }
    
    public static void main(String[] args) {
    
        Hello hello = new Hello();
        hello.setName("world");
        hello.sayHello();
    }
}

Is this a Groovy program or a Java program? Yes, it is - it will compile and run in both. This basic program is a bit wordy, and we can certainly do things more simply in Java, but this contains a number of patterns that you'd commonly see, including the use of the bean pattern, as well as the use of the main method to make the class executable via the java command line program. When we run it, it simply prints out "Hello world!", as is customary in these sorts of things.

To try this out in Java, you can use your favorite IDE. You can also use an IDE to try this in Groovy, but you may just want to use the groovyConsole program, which is available as part of the GDK. Download it now, and play along via cut and paste...

Now, as I said, Groovy is a rough superset of Java - one difference is that things are public by default. That means we could just as easily say the following:

<strong>class</strong> Hello {

    String name;
    
    <strong>void</strong> sayHello() {
        System.out.println("Hello "+getName()+"!");
    }
    
    <strong>void</strong> setName(String name) {
        this.name = name;
    }
    
    <strong>String</strong> getName() {
        return name;
    }
    
    <strong>static void</strong> main(String[] args) {
    
        Hello hello = new Hello();
        hello.setName("world");
        hello.sayHello();
    }
}

Accessors and mutators are automatically created for your class variables, so we can also shorten it by taking those out:

class Hello {

    String name;
    
    void sayHello() {
        System.out.println("Hello "+<strong>getName()</strong>+"!");
    }
    
    static void main(String[] args) {
    
        Hello hello = new Hello();
        <strong>hello.setName("world");</strong>
        hello.sayHello();
    }
}

Now we're getting somewhere. In Groovy, System.out.println can be shortened to just "println" as a convenience, so you can also say:

class Hello {

    String name;
    
    void sayHello() {
<strong>        println("Hello "+getName()+"!");
</strong>    }
    
    static void main(String[] args) {
    
        Hello hello = new Hello();
        hello.setName("world");
        hello.sayHello();
    }
}

There's also a difference in how Groovy deals with String objects - double quote strings allow for variable substitution. There's also single quote strings, which do not:

class Hello {

    String name;
    
    void sayHello() {
        println(<strong>"Hello $name!"</strong>);
    }
    
    static void main(String[] args) {
    
        Hello hello = new Hello();
        hello.setName(<strong>'world'</strong>);
        hello.sayHello();
    }
}

Groovy also allows dot notation to get and set fields of classes, just like Java. Unlike Java, this will actually go through the getter/setter methods (which, you'll recall, are automatically generated in our current example):

class Hello {

    String name;
    
    void sayHello() {
        println("Hello $name!");
    }
    
    static void main(String[] args) {
    
        Hello hello = new Hello();
        <strong>hello.name = 'world'</strong>;
        hello.sayHello();
    }
}

Typing information is also optional - instead of specifying a type, you can just use the keyword def. Use of def is mandatory for methods, but optional for parameters on those methods. You should also use def for class and method variables. While we're at it, let's take out those semicolons: They're optional in Groovy.

class Hello {

    <strong>def</strong> sayHello(<strong>name</strong>) {
        println("Hello $name!")
    }
    
    static <strong>def</strong> main(args) {
        Hello hello = new Hello()
        <strong>def</strong> name = 'world'
        hello.sayHello(name)
    }
}

OK, that's nice, but we can get this even shorter. Because Groovy is a scripting language, there's automatically a wrapping class (called Script, which will become very important to us later). This wrapping class means that we can get rid of our own wrapping class, as well as the main method, like so:

def sayHello(name) {
    println("Hello $name!")
}
def name = 'world'
sayHello(name)

That's all for now, I'll do a second part to this later. But for now, if someone asks you if you know Groovy, you can now say "Sure, a bit".

Credit for the idea behind this post goes to Guillaume Laforge - I saw him give a variation of this as an intro to his talk at JavaOne, and loved it.

(As usual, this article is cross posted on my main blog site.)

DSLs with Groovy JavaOne talk

Sat, 10 Mar 2012 21:33:30 +0000

I've been neglecting my blog, but just a quick note to mention that my latest talk at JavaOne, DSLs with Groovy, is posted up on Slideshare.

The talk's designed for someone with no significant Groovy experience (unlike most Groovy DSL talks), so if it's interesting to you, check it out.

I'm hoping (but not promising) to turn the talk into a series of Blog entries in the coming weeks. So if you want, just wait, and I'll send you explanations in more digestible bits and pieces in the coming weeks.

(As usual, this entry is cross posted to my main blog site.)

JSF 2 And HTML5 Server Sent Events

Thu, 05 Jan 2012 01:15:03 +0000

Recently I had the privilege of writing an article for Java Tech Journal about using HTML5 Server Sent Events in a JSF 2 User Interface. I've made that article available here.

Call for nominations for expert group members for Servlet 3.1 - JSR 340

Sat, 09 Apr 2011 06:20:50 +0000

The JSR for the next revision of Servlet specification - Servlet 3.1 is approved and we are now in the process of forming the expert group. If you would like to contribute to the development of the next version of the servlet specification, please nominate yourself and, if possible, please explain how you plan to contribute to the specification.

If you would like to track the progress of the spec, and see the folowings of the JSR, the spec will now be done using java.net infrastructure. Anyone can sign up to the users mailing list of the servlet-spec.java.net project and will be able to see the proceedings of the expert group mailing list. Please go the JCP site here and click on "I would iike to join this Expert Group". Please make sure that your JSPA is up-to-date. Feel free to provide feedback directly to me if you rather prefer that.

GlassFish 3.1: using the master password and managing instances

Wed, 02 Mar 2011 20:38:25 +0000

GlassFish 3.1 supports creating and managing instances on multiple hosts from a central location (the DAS).

GlassFish 3.1 supports creating and managing instances on multiple hosts from a central location (the DAS). The server software uses SSH to communicate to the remote systems where the instances reside and Joe's blog contains useful information on setting up SSH in a way that GlassFish can take advantage. In this blog I talk about managing those instances when the user sets the master password to something other than the default.

It is recommended that users change the default master password for security reasons. Since GlassFish never transmits the master password or associated file over the network, the user must take action on the remote hosts to allow the system to manage the instances from a central location. Commands such as start-instance do not have a mechanism that allows the user to enter the master password but they do look for a master password file in the agent directory of the node associated with that instance. This means that each instance on that node uses the same master password. We have updated the command change-master-password so that it creates the master-password file for a node. Commands with the --savemasterpassword option will create or update the master-password file.

Let's look at an example. In this case, I create a new domain setting the master password to 'welcome1' and start the domain. I create an SSH node for the remote host I plan to use for the instances. I then create an instance on a remote node using the command create-instance which I run on the DAS. Note that I can create the instance from the DAS but I can not start it unless the master password for the instance matches the master password for the DAS. At that point I have to go to the instance machine and run the change-master-password command with the --savemasterpassword option set to true so that the master-password file is created in the node's agent directory. Once I do that I can go to the DAS machine and manage the instance. Since the master pasword is associated with the node I can then create additional instances from the DAS machine and start or stop them without having to go to the remote host. I have added the commands that need to be run below.

1) Create and start a domain with the master-password set to "welcome1" using the command . Note that I did not set a password for admin user.

asadmin create-domain --savemasterpassword true domain2
asadmin start-domain domain2

2) Create an SSH node

asadmin create-node-ssh --nodehost glassfish1.sfbay.sun.com --installdir /export/glassfish3 node2

3) Create an instance from the DAS. This creates the instance configuration information and the instance file system.

asadmin create-instance --node node2 ins2

4) At this point the instance is created but it can not be started by the start-instance command because there is no master-password file in the agent directory for that node. That file must exist and it must have the same password as the master password on the DAS. To create that file run the following command on the instance machine. If I try to start the instance I get the following error:

asadmin start-instance ins2
remote failure: Could not start instance ins2 on node node2 (glassfish1.sfbay.sun.com).

Command failed on node node1 (glassfish1.sfbay.sun.com): The Master Password is required to start the domain. No console, no prompting possible. You should either create the domain with --savemasterpassword=true or provide a password file with the --passwordfile option.Command start-local-instance failed.

To complete this operation run the following command locally on host glassfish1.sfbay.sun.com from the GlassFish install location /export/glassfish3:

asadmin start-local-instance --node node2 --sync normal ins2
Command start-instance failed.

Go to the instance machine (glassfish1.sfbay.sun.com in this case) and create the master password file for node2 by typing the following command.

asadmin change-master-password --savemasterpassword true --nodedir /export/glassfish3/glassfish/nodes node2

Important note: At the prompt I have to enter the old master password ('welcome1') which is what I had set when I created domain2 on the DAS. It is not the default master password 'changeit' because the keystore was copied over when the instance was created and it is encrypted with the master password from the DAS. So the passwords are the same but since start-instance doesn't have an option to take the master password it looks for a file called master-password in the agent directory to access the keystores. Once that file is created, start-instance can be run centrally (from the DAS).

5) Start the instance from the DAS

asadmin start-instance ins2

At this point you can create additional instances from the DAS and start them without going to the instance machine.

A slightly different scenario is below. In this case I will begin by creating a domain with the master password set to 'welcome1' as in the previous example, create an SSH node to point to the remote host where the instance will run but I will create the instance locally on the instance machine. At some future time I want to manage the instance from the DAS so I still need the master-password file created in the node's agent directory.

On DAS machine:

1) Create and start a domain with the master-password set to "welcome1" using the command

asadmin create-domain --savemasterpassword true domain2
asadmin start-domain domain2

2) Create an ssh node pointing to the remote host where the instances will run.

asadmin create-node-ssh --nodehost glassfish1.sfbay.sun.com --installdir /export/glassfish3 node2

Now we move to the instance machine and create the instance locally and as long as there is no master-password file in the node we need to create one. The command create-local-instance can do that for us.

asadmin --host DASHost create-local-instance --node node2 --savemasterpassword true insL2

In this case, the master password for the keystore in the instance is 'changeit' or the default. Nothing was copied over from the DAS so the password is what is on the instance machine. Again, once the file master-password has been created with the passwordthat matches the one on the DAS, then instance insL2 can be administered from the DAS. Additional instances can be created, started and stopped from the DAS machine.

If the master password is changed on the DAS then you must go to each instance machine and run the change-master-password command as in step 4 above to reset the master password file for each node.

JSF Hudson View Support

Mon, 14 Feb 2011 21:51:15 +0000

Recently, we've enabled a "view" to simplify the monitoring of JSF automated tests through the Hudson framework. The introduction of clustering support in GlassFish has expanded our JSF automated test suite coverage. The URL for the view is:

http://hudson.glassfish.org/view/JSF%20Mojarra/

On a side note - http://jsf.java.net and http://jsf-spec.java.net redirect to http://javaserverfaces.java.net and http://javaserverfaces-spec-public.java.net respectively.

Testing JSF

Sat, 22 Jan 2011 21:16:33 +0000

It's been a while since I've blogged last (ok, it's been a year), but I recently came across a question that I have a little insight into, and I thought I'd tackle it briefly.

The question was simple: "How do I test my JSF application?"

I've used two different test frameworks to do so, and besides being two of the most popular, they also offer a good example of the two different patterns used for Web testing. The two programs are HTMLUnit and Selenium. (Please note, there are certainly others - FacesTester, and JSFUnit (which actually uses/extends HTMLUnit), to name just two - but I'm going to stick to the two that I've used.)

HTMLUnit is a framework which uses browser simulation to test web pages - this means that no browser is launched, which also means that you can do things like test IE7 on Linux without a copy of Windows, as well as running testing in "headless mode", meaning that you don't even need a windowing system to be running (which is handy, and also very efficient for performance). There are downsides to this, of course - for one, it's possible that the simulation may not be perfect (though I've never found a case where it wasn't). The other disadvantage is that you can't actually see what's going on during testing, which can be awkward when figuring out why your test failed. HTMLUnit supports emulating FF2, FF3, FF3.6, IE6, IE7, and IE8.

Selenium, on the other hand, uses browser automation - meaning that it's actually using the browser you're testing your web app in. But that, in turn, means you'll need different browsers installed to test - and in Windows, that means that you'll also need multiple machines to test all the myriad versions of IE. And since you're running a browser in a windowing system, the machine requirements are also a little more substantial. I've also found that configuring the browsers to be a bit tricky at times. However, any inconvenience in setup is more than made up for by the Selenium IDE, which is really just a Firefox plugin that records mouse and keyboard actions for later playback. Selenium supports automation of FF2, FF3, IE7, IE8, Safari2, and Safari3.

In both frameworks, you use their Java API to get a copy of a webpage, find components on that page (such as a button), and perform actions on those components (such as a click). As such, the usage of both is pretty easy, and I'm not going to give a introductory tutorial of either. (Selenium also offers a couple of other automation scripting methods in addition to Java, though I've never used them, so the topic is really much too big for a simple blog post.)

Which should you use?

I suspect that if you're writing your first JSF test, Selenium is really the way to go, for one simple reason: JSF id generation. As I'm sure you know already, every HTML tag can have an id, and that id needs to be unique on that page. For both APIs, the simplest way to find those tags within your code is to use the id. There's just one problem: the id that's in the generated HTML may be quite different from the id you use in your JSF page.

Take this (simplified) example:

<h:form id="frm">
<h:outputText id="out" value="#{whatever}">
</h:form>

Now, say you wish to read the contents of the outputText... What id would you use? Answer: "frm:out". Because templating can be used to insert one page into another, and all id's need to be unique on the page, JSF has the idea of a "naming container" - every component inside a naming container has its naming container id prepended to the id of the component itself. A form is one such naming container, but there are many more.

Now, it's generally possible to figure out what the id will be (though not always easy, given some component libraries), so probably the easiest way to find the component's id would be to use the Selenium IDE, and use it to find the id's of the generated code. The other ways to do this would be to use View Source on your browser, or dump the page contents in the Java code that you're creating to System.out, and examine it that way.

Other factors may influence your decision, of course. HTMLUnit has much better support for Ajax, Selenium has (somewhat feeble) support for Webkit based browsers, which HTMLUnit has none.

Anyhow, as I mentioned, I'm hardly an expert in this area, but I thought I knew enough to at least be helpful to the novice. If you're not a novice, and you've got any additional comments (such as corrections or additional frameworks that folks should check out), please comment...

(Note: This post is crossposted to my personal blog)

JSR 330 Style Injection Support For JSF Managed Beans

Fri, 23 Jul 2010 17:58:11 +0000

One of the features that had been lacking in JSF has been the ability to use the JSR 330 @Inject annotation for injecting object instances into JSF managed beans. The feature now has been enabled in GlassFish 3.1 - starting with the latest July 22 nightly builds, or a current source build. So now, you should be able to use it in a JSF managed bean as follows:

import javax.inject.Inject;

....

@ManagedBean
@SessionScoped

public class UserNumberBean implements Serializable {

@Inject
private Count count;
...

    public String getCount() {
        if (null != count) {
            return count.getCount();
        } else {
            return "";
        }
    }
...

}

Cheers...

GlassFish 3.1 m2 supports creating and starting instances on remote hosts.

Thu, 24 Jun 2010 16:46:06 +0000

One of the main features in GlassFish 3.1 is clustering and for m2 we have added support for creating and starting instances on remote hosts. The underying GlassFish 3.1 code uses SSH to connect to the remote hosts and introduces the concept of a node which is used by the system to deterimine where the instances will be created or started. At this time the only connection type supported is SSH. Users now have a few new commands to manage nodes.

create-node-ssh creates a node that describes the hostname where the instance will run and location of GlassFish installation.
delete-node-ssh and list-nodes are useful in deleting and listing nodes respectfully.

Below is a simple example of creating a cluster, creating an instance and starting the instance all from the administration host or the DAS (Domain Administration System).

First, some assumptions about the setup for GlassFish. For m2, users will have to install and start GlassFish on all hosts that are part of the cluster. We do not currently support installing or starting GlassFish on a remote host and this is planned for a future release. Second, SSH needs to be setup on both hosts as it is the underlying mechanism that is used to run commands on the remote hosts. Currently we have only tested on UNIX (MacOs, Ubuntu, and OpenSolaris) but for m3 we will be including Windows as a tested platform. There are many blogs that talk about setting up SSH so I won't go into all details here. I found this blog useful. To summarize how I set up the authentication key, I used ssh-keygen -t dsa to create the key file in my .ssh dir. Note: a limitation for m2 is that we don't support encrypted key files so you must not set a passphrase when creating keys. I then used scp to copy the key file id_dsa.pub to the host I want to log in to. I put it in the .ssh dir and called it authorized_keys2. Also I had the same username on both systems which further simplified things. At that point I can ssh into the remote host without supplying a password. This is a good test to see if you are set up correctly before you try the commands below.

In this example, we will create a cluster with two machines, foo and bar. foo will be the DAS which has all the information about the servers running in the cluster. Recall that in this release we have introduced a new CLI command create-node-ssh to create a node which is used to locate the host for a particular instance.

create-node-ssh has three required parameters,

--nodehost: the name of the host where the instance lives
--nodename: the GlassFish installation directory
--name: name of the node being created

All other parameters will default to reasonable values. We default the ssh port to 22. If no username is provided we default to the user running the command and we look for the key file in the home directory of that user. All instances are now required to reference a node element which GlassFish uses to determine where the instance will be created or started. This means that we have added a --node option to the create-instance command. As a convience we have a default node for localhost so if the node option is not specified when the instance is created a reference is automatically added to the localhost node. The localhost node contains only a node name of localhost. We can get the GlassFish installation directory from the server.

Let's see how this works. All commands are run on the DAS machine and as long as there is SSH access to the other host we will be able to create and start instances.

Install and start GlassFish 3.1 m2 on foo and bar.

On host foo (the DAS) we run all the commands.

$asadmin create-cluster c1

Command create-cluster executed successfully.

$asadmin create-node-ssh --nodehost=bar --nodehome=/home/cmott/glassfishv3/glassfish nodebar

Command create-node-ssh executed successfully.

$asadmin list-nodes
localhost
nodebar

Command list-nodes executed successfully.

$asadmin create-instance --cluster=c1 --node=nodebar instance1

Command create-instance executed successfully.

$asadmin create-instance --cluster=c1 instance2

Command create-instance executed successfully.

$asadmin list-instances
instance2 not running
instance1 not running

Command list-instances executed successfully.

$asadmin start-cluster c1

Command start-cluster executed successfully.

$asadmin list-instances

instance2 running
instance1 running

Command list-instances executed successfully.

Notice that when creating instance2 I did not specify a node and so the default node lcoalhost is used. In a future release of GlassFish, create-node-ssh will test if a connection can be made to the remote host when the node is created. If not reachable the user can create the node if the --force option is set to true.

JSF 2 / HTML 5 Jazoon 2010 Slides Posted

Wed, 09 Jun 2010 15:06:10 +0000

My slides for "Exploring HTML5 With JavaServer Faces 2.0" slides are available at Slideshare: Available at: http://www.slideshare.net/rkitain/jsf2-html5jazoon

Testing HTML5 Feature Availability In Browsers

Tue, 25 May 2010 09:55:22 +0000

The ongoing HTML5 specification offers many features to promote a "rich" web user experience. If you've worked wth HTML5, you know that some features are available in some browsers and not available in others. Here's a handy tool to tell you the HTML5 features that are available in your favorite browser. All you need to do is fire up a browser and visit: http://html5test.com . With this, you'll see a nice breakdown of the features that are available in the current browser version. It will also tell you, the strengh of support for each feature. For example, for the current version of Firefox I'm using (3.6.3), it says it has a total score of 101 out of 160. Here's a breakdown for each of the current browsers I'm using:

Firefox 3.6.3	101/160
Safari 4.0.3	115/160
Opera 10.10	38/160
Chrome 5.0.375.55 beta	142/160

Of course if you really like an HTML5 feaure that is not available in your favorite browser, you can always check the "development" versions for the browser - as HTML5 support is still a work in progress.

JavaOne CFP Opens

Thu, 11 Feb 2010 20:15:56 +0000

Although I'm not involved in the talk selection process this year, I'm still paying attention to JavaOne.

The Call For Papers appears to be open now, through March 14th.

Be sure to read the Submission Criteria before submitting a proposal for a paper. Trust me, it'll help your ideas get noticed.

Good luck, everyone.

HTML5 Semantic Tags

Tue, 09 Feb 2010 02:06:46 +0000

Over the weekend, I was reading Mark Pilgrim's great book on HTML5 - and when I got to the part about the semantic tags, I thought it might be worth a quick mention.

In case you've missed out on HTML5 in general (and don't want to take the time to read that book I linked above), the idea behind semantic tags is that many sites use div blocks to mark out the same kinds of content, over and over. Content like headers, footers, and nav bars. Changing straight <div> tags to tags like <header>, <footer>, and <nav> is granting these tags semantic meaning, hence the name - semantic tags.

Semantic tags are a great idea. They offer a lot advantages over plain vanilla divs, especially for screen readers... but support in IE is pretty broken... The essential problem is this: unlike all other major browsers, IE doesn't know how to style unknown tags. So the following code won't work:

&lt;style&gt;
    .border {
        border: solid black;
    }
&lt;/style&gt;
...
&lt;section class=&quot;border&quot;&gt;test3&lt;/section&gt;

Ah, I hear the more informed folks in the audience say, there exists a library to fix this problem: the HTML5 Shiv. You can use it like so:

&lt;!--[if IE]&gt;
&lt;script src=&quot;http://html5shiv.googlecode.com/svn/trunk/html5.js&quot;&gt;&lt;/script&gt;
&lt;![endif]--&gt;

This simple script will allow styles to be placed on unknown tags in IE... So, that's a good start, but there are a few problems with it. For one thing, it relies on JavaScript, so if JavaScript is disabled, your styling will fail catastrophically. Similarly, applying print styles may not work, since JavaScript won't necessarily be run as part of the print process (note: I haven't tested this fully, but that's sure what it looks like in brief testing). There are reports that nesting seems to mess stuff up applying styles correctly, but my testing hasn't found anything broken in this way that isn't already broken in IE's CSS support.

Of course, there is a way around even that: If you are running JSF or some other server side processing on your backend, you could do User Agent detection, and emit <div>'s to IE and the semantic tags to all other browsers. Then, by styling the tags solely with classes and ID's, it should be possible to make something that gets around the client side issues. Here's a section from a component that does just that.

@FacesComponent(value = &quot;navtag&quot;)
public class NavTag extends UIComponentBase {
    
    @Override
    public void encodeBegin(FacesContext context) throws IOException {
        boolean isIE = false;
        UIComponent component = getCurrentComponent(context);
        String style = (String) component.getAttributes().get(&quot;style&quot;);
        String styleClass = (String) component.getAttributes().get(&quot;styleClass&quot;);
        ResponseWriter responseWriter = context.getResponseWriter();
        String ua = context.getExternalContext().getRequestHeaderMap().get(&quot;User-Agent&quot;);
        if (ua != null &amp;&amp; ua.contains(&quot;MSIE&quot;) &amp;&amp; !ua.contains(&quot;Opera&quot;)) {
            isIE = true;
        }
        if (isIE) {
            responseWriter.startElement(&quot;div&quot;, null);
        } else {
            responseWriter.startElement(&quot;nav&quot;, null);
        }
        responseWriter.writeAttribute(&quot;id&quot;, getClientId(context), &quot;id&quot;);
        responseWriter.writeAttribute(&quot;name&quot;, getClientId(context), &quot;clientId&quot;);
        if (styleClass != null) {
            responseWriter.writeAttribute(&quot;class&quot;, styleClass, &quot;styleClass&quot;);
        }
        if (style != null) {
            responseWriter.writeAttribute(&quot;style&quot;, style, &quot;style&quot;);
        }
    }

Should JSF add these tags to JSF 2.1? I'd love to hear your comments, below...

Progressive Enhancement with JSF

Sun, 07 Feb 2010 08:09:49 +0000

Progressive Enhancement is a philosophy of web design - start with simple pages, and build them up based on the capabilities of the browser viewing the page. It’s related to (and in some ways, the opposite of) the idea of Graceful Degradation, starting with a nice, fancy page, and dealing with any browser faults in an elegant manner.

Prehaps the simplest example to see this in action is the case of JavaScript being disabled in the browser - this is occasionally true for certain corporate clients concerned about security, and sometimes the case for very old browsers.

JSF handles this usecase pretty well - consider the following code:

   1
   2 <f:ajax render="grace :text">
   3   <h:selectBooleanCheckbox value="#{grace.checked}"/>
   4 </f:ajax>

This creates a checkbox input with an onclick event handler registered. If there’s no JavaScript enabled, it will continue to function as thought the ajax tag wasn’t there at all. But the user will need to submit the form with a button press...

There is another way to handle this: we could instead create a link, which uses view parameters:

   1 &lt;f:metadata&gt;
   2     &lt;f:viewParam name=&quot;checked&quot; value=&quot;#{grace.checked}&quot;/&gt;
   3 &lt;/f:metadata&gt;
   4 &lt;h:link value=&quot;check me&quot;&gt;
   5     &lt;f:param name=&quot;checked&quot; value=&quot;#{!grace.checked}&quot;/&gt;
   6 &lt;/h:link&gt;

That works, but isn’t as clean looking as the first, ajax method. Combining these approachs should provide a better user experience - and doing so isn’t especially difficult:

   1 &lt;f:metadata&gt;
   2     &lt;f:viewParam name=&quot;checked&quot; value=&quot;#{grace.checked}&quot;/&gt;
   3 &lt;/f:metadata&gt;
   4 &lt;h:outputText id=&quot;text&quot; value=&quot;Checked: #{grace.checked}&quot;/&gt;
   5 &lt;h:form id=&quot;form&quot;&gt;
   6     &lt;h:panelGroup id=&quot;grace&quot; layout=&quot;block&quot;&gt;
   7         &lt;h:panelGroup id=&quot;default&quot;&gt;
   8             &lt;h:link value=&quot;check me&quot;&gt;
   9                 &lt;f:param name=&quot;checked&quot; value=&quot;#{!grace.checked}&quot;/&gt;
  10             &lt;/h:link&gt;
  11         &lt;/h:panelGroup&gt;
  12         &lt;h:panelGroup id=&quot;enhanced&quot; style=&quot;display: none&quot;&gt;
  13             &lt;f:ajax render=&quot;grace :text&quot;&gt;
  14                 &lt;h:selectBooleanCheckbox value=&quot;#{grace.checked}&quot;/&gt;
  15             &lt;/f:ajax&gt;
  16         &lt;/h:panelGroup&gt;
  17         &lt;script type=&quot;text/javascript&quot;&gt;
  18             var def = document.getElementById(&quot;form:default&quot;);
  19             var enh = document.getElementById(&quot;form:enhanced&quot;); 
  20             def.style.display = &quot;none&quot;;
  21             enh.style.display = &quot;block&quot;;
  22         &lt;/script&gt;
  23     &lt;/h:panelGroup&gt;
  24 &lt;/h:form&gt;

First, create two divs, one with the link and the other with the checkbox, which is hidden by default. If JavaScript is enabled, then hide the link and show the checkbox. This is the basic idea behind Progressive Enhancement - first, create something that you’ll be happy with in any browser, then add features (in this case, an Ajaxified checkbox) as needed.

That’s all for today. One personal note: Today is my last day officially employed by Sun Microsystems - I wasn’t offered a position at Oracle, and I’m currently actively looking for something. Please feel free to checkout my resume, and let me know if you know of any openings that you think might be a fit for me.

IE, Memory Management, and You

Fri, 13 Nov 2009 20:59:01 +0000

In a recent blog, commenters took me to task for a perceived IE 6 memory leak. It wasn't actually there (they were wrong), but in attempting to prove myself right, I found a couple of memory leaks under IE in JSF's Ajax support. Since I just spent a week learning how all this functioned, I thought I'd set it down so that others could learn from my efforts.

Now, none of the information that I'll present here is new - it's been discussed among Ajax programmers for at least the last 4 years. If you're a web guru, it's likely that you're not going to learn anything new here (thought I'd welcome any additional information and corrections). But at least a couple of the points I'll illustrate below are either poorly communicated or misunderstood. I'll include a number of links at the end of this article. There are also very significant differences between IE 8 (which mostly works), IE 7 (which is bad), and IE 6 (which is just awful). I'll try to point out the differences as they matter for each.

Tools

First - use the right tool for the job: In order to spot leaks, you'll need to download a tool that can detect them. By all accounts, sIEve is the way to go. It uses IE itself, and introspects to get it's data. The UI is pretty primitive, but I can't recommend it enough - it's truely invaluable. Since it uses IE for it's work, you'll need to run it on a machine that has IE6 installed - presumably in a VM. You'll also want to have it running on a machine that has IE 7 and IE 8 as well, just to be sure. XP fits nicely on a VM that runs on my Mac, and this is how I use it.

Cyclic Leak

Now that that's out of the way, it's time to talk about the very worst of the memory leaks in IE - the dreaded cyclic reference, which the commenters thought that I'd committed. Under certain conditions, IE 6 will "leak" DOM nodes, retaining them, and the javascript objects that point to them, until the browser is either shut down, or crashes entirely due to lack of memory. Ugh! To understand how this happens, you really only need to know two things:

IE 6 (and 7!) reportedly has very primitive garbage collection using reference counting
There are two memory spaces in IE, one for JavaScript, and the other for the DOM, and they don't communicate well.

What could go wrong? Well, lots. The commenters thought that the rule was: A leak will occur if any reference is made in JavaScript to an element that isn't eventually set to null. That's close, but not quite correct. The real rule is: A leak will occur if the JavaScript code contains any reference to the DOM that isn't released in some way, either by going out of scope or being explicitly unset.

When IE 6 sees a JavaScript variable that is pointing to something in the DOM (typically, an element or node), it will record that reference, and not collect it - even when you surf over to a new page. And the DOM won't be collected, since there's a reference to it from JavaScript. These two objects, and all the stuff that references them, will stick around until shutdown. In IE 7, the geniuses at Microsoft saw the bug, and said "Hey, I know how to fix that, let's garbage collect everything when we leave the page.". Nice improvement, but it still doesn't fix the bug, since if you're developing a page that is designed to be used for a long period of time (like many page-as-application apps are now), it'll still crash the browser. Apparently, they saw the error of their ways eventually, since this behavior is no longer present in IE8. (All this is confirmed by my testing with sIEve.)

So, in the example that had in my previous blog, there was no memory leak, because the variable that pointed to the element eventually went out of scope. So - how to you create variables that don't go out of scope? The easiest way is to put them in an object - this was the leak that I eventually found in JSF. The fix there was to null out the object manually. But there's another, more insidious way to create an object - create a closure. That creates a function object implicitly under the window object, and that will never go out of scope. But the key thing to remember is that you need to be aware of when things go out of scope when coding in IE, and act accordingly.

But wait! There's more

If that was the only problem, life would have been fairly easy for me the last week. But that's not the only bug that the Web Wizards of Redmond chose to deliver to their unsuspecting consumers. There's another bug in IE (again, only in IE 6 and 7 - IE 8 appears to have fixed it per my testing), which also leaks DOM nodes that aren't cleaned up until you leave the page. Apparently, when the IE DOM receives a call from the removeChild or replaceChild functions, it doesn't actually, err, remove the nodes. It just leaves them there, hanging around the DOM like party guests that don't have the sense to leave after the host has started handing out coats. While these nodes will eventually be cleaned up when the user leaves the page, this still causes problems for page-as-app programs, as in the cyclic leak for IE 7, above. While the removeChild call is fairly notorious for this, I had to find out about replaceChild with my own testing (though I did find a few obscure references once I went looking for it).

That means that instead of saying node.parentNode.replaceChild(newNode, node), you instead should say something like: node.parentNode.insertBefore(newNode, node); deleteNode(node); (with an appropriate if statement for isIE(), and a deleteNode function that doesn't use removeChild). And instead of saying node.parentNode.removeChild(node); you instead are reduced to coding something like: node.outerHTML = ''; (again, with browser check). Except that when you combine that with IE's horrible problems with manipulating tables, it may fail. So instead, you're probably better off with something like this:

<pre> 
                var temp = document.createElement('div');
                try {
                    temp.appendChild(node.parentNode.removeChild(node));
                    temp.innerHTML = ""; // Prevent leak in IE
                } catch (e) {
                    // at least we tried
                }
                deleteNode(temp);
</pre>

Again, possibly with an isIE() check.

Hopefully you found this description of IE's Memory "Management" useful. Here's a few of the links that I used for research, that I found the most helpful.

sIEve - the tool you should already have.
Quirks blog link roundup of memory leak info.
Microsoft MSDN article on the topic. Useful, even if it insultingly implies that it's your fault the browser is leaking.

As always, I look forward to any comments. Especially about this topic - I'm far from expert in this area.

UPDATE: John Resig just posted about a very interesting looking tool. Haven't checked it out yet, but if it's got him excited...

Mojarra 2.0.1 has shipped

Fri, 23 Oct 2009 21:10:46 +0000

Just a short post to note that we've now shipped Mojarra 2.0.1. This version fixes a very serious bug when running on Tomcat. You can pick up the files from the usual places, see the release notes for more information.

If you're using GlassFish, and already running 2.0.0 (you leading edge adopter!), there's probably no reason to upgrade - though the new v3 (b69) has the updated jar, and it will be propagated via the usual Update Center distribution.

Context And Dependency Injection (JSR 299) And Servlets

Wed, 09 Sep 2009 14:34:21 +0000

I've had questions about how to inject Web Beans into servlets and whether that is supported. In this entry I'll outline a method of accomplishing just that.
This is a simple login application that communicates to a servlet using Ajax calls from a JSP view. I'm not going to focus on the view or the protocol (Ajax) that is used to communicate with the servlet. If you are interested in that, you can check out the source (instructions at the end of this post). I'm going to focus on the servlet code and the supporting classes for the application. The application just prompts for a user name / pasword, and pressing the submit button sends those values to a servlet. First, let's take a look at some of the supporting code for the application:

Listing 1: Login Credentials

package webbeansservlet;
import javax.enterprise.context.RequestScoped;
import javax.enterprise.inject.Default;
import javax.inject.Named;
/**
* This is just a simple container class Web Bean for the username
* and password entry values.
*/
@Named
@RequestScoped
@Default
public class Credentials {
private String username = null;
private String password = null;
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
}

Line 11: The name of this Web Bean will be credentials since we don't supply an argument to the Named annotation.
Line 12: For the purposes of this simple application this Web Bean scope will be for the current request.
Line 13: Specifies the default qualifier type for this Web Bean. Note that you should not have to specify this if it's the only qualifier type being used. In future implementations of Web Beans this should be fixed.

Listing 2: Login

package webbeansservlet;
import java.io.Serializable;
import javax.enterprise.context.SessionScoped;
import javax.enterprise.inject.Default;
import javax.inject.Inject;
import javax.inject.Named;
/**
* A simple Web Bean that performs a login operation with user's
* credentials.
*/
@Named
@SessionScoped
@Default
public class Login implements Serializable {
@Inject Credentials credentials;
private boolean loggedIn = false;
/**
* This is where you could potentially access a database.
*/
public void login() {
if ((credentials.getUsername() != null &&
credentials.getUsername().trim().length() > 0) &&
(credentials.getPassword() != null &&
credentials.getPassword().trim().length() > 0)) {
loggedIn = true;
}
}
public boolean isLoggedIn() {
return loggedIn;
}
}

Line 13: The name of this Web Bean will be login
Line 14: This Web Bean will exist for the session
Line 15: Specifies the default qualifier type for this Web Bean.
Line 18: We're injecting an instance of Credentials so we can check the validity of the user name and password entries

Listing 3: Login Servlet

package webbeansservlet;
import java.io.IOException;
import java.io.PrintWriter;
import javax.enterprise.inject.spi.BeanManager;
import javax.inject.Inject;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
/**
* This Servlet class demonstrates Web Beans injection.
*/
@WebServlet(name="LoginServlet", urlPatterns={"/LoginServlet"})
public class LoginServlet extends HttpServlet {
// Inject Web Beans Bean Manager.
@Inject BeanManager m;
// Inject The Credentials Web Bean.
@Inject Credentials credentials;
// Inject the Login Web Bean.
@Inject Login login;
/**
* Processes requests for both HTTP <code>GET</code> and <code>POST</code> methods.
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
credentials.setUsername(request.getParameter("username"));
credentials.setPassword(request.getParameter("password"));
login.login();
try {
if (login.isLoggedIn()) {
out.println("Successfully Logged In As: " + credentials.getUsername());
} else {
out.println("Login Failed: Check username and/or password.");
}
} finally {
out.close();
}
}
.......
}

Line 15: New for Servlet 3.0 - eliminates servlet entry in web.xml! Not relevant to this example, but worth mentioning.
Line 19: The Web Beans Bean Manager can also be injected. The Bean Manager api provides some useful methods for interrogating portions of a Web Beans application.
Line 22: The Credentials Web Bean is injected making it available to the servlet.
Line 38: Now we can access the Credentials Web Bean.
Line 40: We can also use the injected Login Web Bean instance.

This is just one example of Web Bean injection into a servlet. There are more areas in the JavaEE6 platform that can be used as Web Bean injection points - topics that will certainly be covered in future posts. The sample for this blog can be found under the glassfish-samples project. You can check out the code following these instructions. Once the workspace is checked out, you can find this sample under glassfish-samples/ws/javaee6/webbeans/webbeans-servlet. You can find documentation for the sample under glassfish-samples/ws/javaee6/webbeans/webbeans-servlet/docs. As with all the Web Beans samples now, you should run with GlassFish V3 - any build after September 2 2009.

Contexts and Dependency Injection (JSR 299) and GlassFish

Fri, 04 Sep 2009 19:34:20 +0000

Version 1.0.0.PREVIEW3 of Web Beans (the implementation for JSR 299 Contexts and Dependency Injection For Java EE) now uses the annotations from JSR 330 (Dependency Injection For Java) and it is available in GlassFish V3.
In this entry, we'll look at a simple JSF 2 application that uses Web Beans and the JSR 330 annotations. There are other features available in this release of Web Beans which will be discussed in subsequent blog entries. This application is a simple "guess number" application which I'm sure we are probably all familiar with by now. Let's start by taking a look at the application's UI markup.

Listing 1: User Interface Markup

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core">
<h:head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>JSF 2.0 Web Beans Example</title>
</h:head>
<h:body>
<h:form id="NumberGuessMain">
<h:panelGrid styleClass="title-panel">
<h:outputText value="Guess Number" styleClass="title-panel-text"/>
<h:outputText value="Powered By JavaServer Faces 2.0 and Web Beans" styleClass="title-panel-subtext"/>
</h:panelGrid>
<div style="color: black; font-size: 24px;">
I'm thinking of a number between <span style="color: blue">#{game.smallest}</span> and <span style="color: blue">#{game.biggest}</span>. You have <span style="color: blue">#{game.remainingGuesses}</span> guesses.
</div>
<h:panelGrid border="1" columns="5" style="font-size: 18px;">
Number:
<h:inputText id="inputGuess" value="#{game.guess}" required="true" size="3" disabled="#{game.number eq game.guess}" validator="#{game.validateNumberRange}"/>
<h:commandButton id="GuessButton" value="Guess" action="#{game.check}" disabled="#{game.number eq game.guess}"/>
<h:commandButton id="RestartButton" value="Reset" action="#{game.reset}" immediate="true" />
<h:outputText id="Higher" value="Higher!" rendered="#{game.number gt game.guess and game.guess ne 0}" style="color: red"/>
<h:outputText id="Lower" value="Lower!" rendered="#{game.number lt game.guess and game.guess ne 0}" style="color: red"/>
</h:panelGrid>
<div style="color: red; font-size: 14px;">
<h:messages id="messages" globalOnly="false"/>
</div>
<h:outputStylesheet name="stylesheet.css" />
</h:form>
</h:body>
</html>

Everything on this page is really just standard JSF 2.0 view markup. I've emphasized the Expression Language (EL) portions of the view, especially game because it refers to a contextual bean instance also known as a Web Bean.

Line 17: Binding to Web Bean properties
Line 21: Binding to Web Bean properties and validation method
Line 22, 23: Binding to Web Bean action method
Line 24, 25: Binding to Web Bean properties

As you can see, in JSF, binding to a Web Bean is no different than binding to a typical managed bean.

Supporting Classes And Annotations For The Applicaton

Let's take a look at some of the utility classes for the application, namely the classes that are used to generate a random number and some of the supporting annotations.

Listing 2: The "Random" Annotation

package webbeansguess;
import static java.lang.annotation.ElementType.FIELD;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.PARAMETER;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;
import java.lang.annotation.Documented;
import java.lang.annotation.Retention;
import javax.inject.Qualifier;
@Target( { TYPE, METHOD, PARAMETER, FIELD })
@Retention(RUNTIME)
@Documented
@Qualifier
public @interface Random {
}

The JSR 330 @Qualifier annotation is used to make Random a binding type. This will allow us to inject a random number into the application.

Listing 3: The "MaxNumber" Annotation

package webbeansguess;
import static java.lang.annotation.ElementType.FIELD;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.PARAMETER;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;
import java.lang.annotation.Documented;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;
import javax.inject.Qualifier;
@Target( { TYPE, METHOD, PARAMETER, FIELD })
@Retention(RUNTIME)
@Documented
@Qualifier
public @interface MaxNumber {
}

Likewise, the @Qualifier annotation is used to make MaxNumber a binding type that will allow us to inject the maximum number allowed (for a guess) in the application.

Listing 4: The "Generator" Class

package webbeansguess;
import java.io.Serializable;
import javax.enterprise.context.ApplicationScoped;
import javax.enterprise.inject.Produces;
@ApplicationScoped
public class Generator implements Serializable {
private static final long serialVersionUID = -7213673465118041882L;
private java.util.Random random = new java.util.Random( System.currentTimeMillis() );
private int maxNumber = 100;
java.util.Random getRandom() {
return random;
}
@Produces @Random int next() {
return getRandom().nextInt(maxNumber);
}
@Produces @MaxNumber int getMaxNumber() {
return maxNumber;
}
}

Line 7: An instance of this class exists for the lifecycle of the application
Line 15: next() is a Web Beans producer method. It will get called by the Web Beans Manager to obtain an instance of the next random number.
Line 18: getMaxNumber() is also a Web Beans producer method. It will get called by the Web Beans Manager to obtain an instance of maxNumber - essentially returning the maximum number to "guess" in the application (in this case "100").

The Anatomy of a Simple Contextual Bean

Now that we have are utility classes and annotations in place, we can use them in our Web Bean.

Listing 5: The "Game" Contextual Bean

package webbeansguess;
import java.io.Serializable;
import javax.annotation.PostConstruct;
import javax.enterprise.context.SessionScoped;
import javax.enterprise.inject.Instance;
import javax.inject.Inject;
import javax.inject.Named;
import javax.faces.application.FacesMessage;
import javax.faces.component.UIComponent;
import javax.faces.component.UIInput;
import javax.faces.context.FacesContext;
@Named
@SessionScoped
public class Game implements Serializable {
private static final long serialVersionUID = 1L;
private int number;
private int guess;
private int smallest;
@MaxNumber @Inject
private int maxNumber;
private int biggest;
private int remainingGuesses;
@Random @Inject Instance<Integer> randomNumber;
public Game() {
}
public int getNumber() {
return number;
}
public int getGuess() {
return guess;
}
public void setGuess(int guess) {
this.guess = guess;
}
public int getSmallest() {
return smallest;
}
public int getBiggest() {
return biggest;
}
public int getRemainingGuesses() {
return remainingGuesses;
}
public String check() throws InterruptedException {
if (guess>number) {
biggest = guess - 1;
}
if (guess<number) {
smallest = guess + 1;
}
if (guess == number) {
FacesContext.getCurrentInstance().addMessage(null, new FacesMessage("Correct!"));
}
remainingGuesses--;
return null;
}
@PostConstruct
public void reset() {
this.smallest = 0;
this.guess = 0;
this.remainingGuesses = 10;
this.biggest = maxNumber;
this.number = randomNumber.get();
}
public void validateNumberRange(FacesContext context, UIComponent toValidate, Object value) {
if (remainingGuesses <= 0) {
FacesMessage message = new FacesMessage("No guesses left!");
context.addMessage(toValidate.getClientId(context), message);
((UIInput)toValidate).setValid(false);
return;
}
int input = (Integer) value;
if (input < smallest || input > biggest) {
((UIInput)toValidate).setValid(false);
FacesMessage message = new FacesMessage("Invalid guess");
context.addMessage(toValidate.getClientId(context), message);
}
}
}

I've color coded the areas of interest in this class. The blue areas are JSR 299 (Web Beans) implementation details. The red areas are JSR 330 (Dependency Injection For Java) areas. The purple areas are the binding types.

Line 14: We are using the Named annotation to associate a name with this bean. Because there is no argument specified with the Named annotation, its name will be the name of the bean itself with the first letter lowercase (game). This allows us to reference the bean by that name using the Expression Language in the view.
Line 15: We declare this bean as a session scoped bean, meaning it's lifecycle is the lifecycle of the session.
Line 23: The producer method in the Generator class (line 18) will service this injection point causing maxNumber to have a value of "100".
Line 29: The producer method in the Generator class (line 15) will service this injection point making a randomNumber instance available for this Web Bean.
Line 72: We use a standard @PostConstruct annotation causing variable initialization (after this Web Bean is created).
Line 78: Our Web Bean has been created, so the randomNumber.get() call will cause the producer method in the Generator class (line 15) to get called.

Well, that's a quick overview of a simple JSF2 application that uses the Web Beans (JSR 299 implementation) and the Java Dependency Injection (JSR 330) annotations. You can find this version of Web Beans in any of the GlassFish V3 builds after September 2, 2009.

Latest functionality in GlassFish v3 logging.

Thu, 03 Sep 2009 00:33:50 +0000

This blog highlights some of the changes that are part of GlassFish v3 logging. Since Prelude I have added 3 asadmin commands related to logging. I have updated the set-log-level command and changed the syntax. See below for details. The new commands are:

    * asadmin rotate-log
    * asadmin list-logger-levels
    * asadmin set-log-level logger-name=level:logger-name=level

The first command rotates the log files immediately. Users can now use native scheduling software such as cron to rotate the logs. We still support rotating logs based on file size or elapsed time since the last log rotation and this new command allows more flexibility when rotating log files. The second command lists the loggers and their current level. This command reports on all the known loggers that are listed in logging.properties file. Note that in some cases the loggers may not have been created by the respective containers however they will still appear in the list. The third command, asadmin set-log-level, sets the level for aone or more loggers. For example, to set the log level of the web container logger level to WARNING simply type: asadmin set-log-level javax.enterprise.system.container.web=WARNING. This command updates the logging.properties file which means that the values are persisted across server restart. Use asadmin list-logger-levels to get the names of the loggers.

Finally, I've added a property to logging.properties file in the domain config directory that controls the number of message written to the server log file. GlassFish v3 logging code writes messages to a queue instead of directly to the server log file. Log messages are taken off the queue and written to the server log file as cycles become available. The property name is com.sun.enterprise.server.logging.GFFileHandler.flushFrequency. This propertys controls the number of messages that are taken off the queue and written to a file a time. The actual number written is the value of this property or less depending on the number of messages in the queue. The default value is 1.

Slides from our talk at JavaOne.

Wed, 03 Jun 2009 18:05:44 +0000

Jan Luehe, Greg Wilkins and I did a talk on Servlet 3.0 at JavaOne yesterday. Am attaching the slides from the talk for those that didn't make it or did make it and want a copy of the slides :).

ICEFaces 2.0 And JSF 2.0 Together

Mon, 25 May 2009 23:40:29 +0000

JSF Ajax frameworks have been around for some time. JSF is all about
server side components that render
their state as markup to the client. JSF has a well defined lifecycle
that defines how component state
is handled on the server and when component state is rendered to the
client. JSF Ajax frameworks can control which components are
processed on the server (known as partial processing), and which
components render themselves back to the client (known as partial
rendering) by sending Ajax requests with special parameters.

How ICEFaces Uses JSF 2.0 To
Send Ajax Requests

The JSF 2.0 Ajax JavaScript API
style="font-style: italic;">jsf.ajax.request
style="font-style: italic;"> can be used to trigger Ajax
requests from an HTML event such as onclick.
This function can be called from within a JavaScript function
too. ICEFaces uses the jsf.ajax.request
function within their JavaScript library:

cellpadding="2" cellspacing="2">

style="vertical-align: top; background-color: rgb(204, 255, 255);">

    submitEvent = function(event, element, form) {

    ...


style="color: rgb(51, 51, 255);">jsf.ajax.request(element, event,
{execute: '@all', render: '@all'});

    ...

    };

    submitForm = function(event, form) {

    ...


style="color: rgb(51, 51, 255);">jsf.ajax.request(form, event,
{execute: '@all', render: '@all'});

    ...

    };

ICEFaces uses submitEvent and
submitForm in their
style="font-style: italic;">iceSubmitPartial and
style="font-style: italic;">iceSubmit functions
respectively. The iceSubmitPartial
and iceSubmit functions
are part of the ICEFaces Ajax Bridge that communicate with the
server. ICEFaces is using the keyword
style="font-style: italic;">@all for both
style="font-style: italic;">execute and
style="font-style: italic;">render which means that all
components are processed on the server, and all components are targeted
for rendering markup back to the client. ICEFaces sends
everything because on the server the framework determines the "dirty"
regions in a view by comparing the current rendered view with the view
that was rendered as a result of the Ajax request.

How ICEFaces Uses JSF 2.0 To Process
Ajax Requests On The Server

JSF 2.0 provides extensibility points that allow JSF Ajax
frameworks to perform customized partial processing and partial
rendering on the server. The JSF 2.0 API provides the
style="font-style: italic;">javax.faces.context.PartialViewContext.processPartial
method for this purpose. This method performs partial
processing and partial rendering on the components identified by the
identifiers in the execute and
render lists from the
request. ICEFaces extends javax.faces.context.PartialViewContext
with their DOMPartialViewContext
impementation:

cellpadding="2" cellspacing="2">

style="vertical-align: top; background-color: rgb(204, 255, 255);">import
javax.faces.context.PartialViewContextWrapper;

...

public class DOMPartialViewContext extends PartialViewContextWrapper {

...


style="color: rgb(51, 51, 255);">public void processPartial(PhaseId
phaseId) {

    ...

        if (isRenderAll() &&
PhaseId.RENDER_RESPONSE) {

            //
Perform DOM Diffing ..

            //
Send updates as separate <update> elements using JSF 2.0
PartialResponseWriter

            ...

        } else {


super.processPartial(phaseId);

        }

    }

...

}

If the current processing phase is the
style="font-style: italic;">Render Response Phase, ICEFaces:

retrieves the current DOM (for the view before rendering)
generates the new DOM by rendering the new view (using a special
DOMResponseWriter)
determines if there are differences between the DOMs

If there are differences, then the JSF 2.0
style="font-style: italic;">javax.faces.context.PartialResponseWriter implementation
is used to write <update> elements back to the client following
the specification defined partial response format:

cellpadding="2" cellspacing="2">

style="vertical-align: top; background-color: rgb(204, 255, 255);"><partial-response>

   <changes>

      <update id="user">

         ...

      </update>

      <update id="password">

         ...

      </update>

      ...

   </changes>

</partial-response>

If there are no differences, then the JSF 2.0
style="font-style: italic;">javax.faces.context.PartialResponseWriter implementation
is used to write the single <update> element containing the
entire view markup.

Summary

ICEFaces 2.0 is still
under development, and it is one of the early component frameworks that
follow the JSF 2.0 Ajax standard. It uses the JSF 2.0 Ajax
JavaScript API to initiate Ajax requests to the server. It
leverages the JSF 2.0 Ajax extensibility points on the server to
process Ajax Requests and formulate the partial response to send back
to the client. This version of ICEFaces (2.0) currently uses the
href="https://javaserverfaces.dev.java.net/">mojarra implementation
of the JSF 2.0 specification. There will surely be more component
frameworks on board with JSF 2.0, which should go a long way towards
component interoperability.

References

href="http://www.jroller.com/tedgoddard/entry/on_the_road_to_icefaces">ICEFaces
2.0

JavaServer Faces 2.0
Specification

Project Mojarra

GlassFish

style="font-style: italic;">

Proposed Final Draft of Servlet 3.0 now available

Fri, 08 May 2009 20:58:15 +0000

The proposed final draft of the Servlet 3.0 specification is now available at the JCP site . In addition to the specification, also refer to Shing Wai's blog describing in detail the ordering solution for fragments and the use of security annotations.

Servlet 3.0 PFD draft coming soon.

Tue, 28 Apr 2009 20:20:13 +0000

It's been a while since my last update. However I am pleased to report that the Proposed Final Draft (PFD) of Servlet 3.0 is now been handed off to the JCP. Some highlights of what is in the PFD draft -

The issues around Async have been worked out and Greg will also be posting an update to his last set of comments. Basically there were some tweaks to the APIs and semantics of the proposal. However the proposal itself hasn't changed drastically. It has been implemented in GlassFish and I believe also in Jetty 7.0 pre release build.
We now have an ordering solution for Servlets, Filters and Listeners that also allows users to control what jar files are looked up based on the pluggability feature described previously.
In addition to the pluggability via fragments, annotations, we also introduced the concept of ServletContainerInitializer which allows you to plugin providers based on either annotations or classes that a particular class implements. For example when plugging in JAX-WS into a web container to support web services, today most implementations require you to use a proprietary descriptor (unless you are writing a JSR 109 style web service) for using the web service library in a web container. I will provide more details of how framework authors can use the ServletContainerInitializer in a separate blog soon to follow.
Ability to load static resources and JSPs from a jar file. This feature enables users to bundle shared resources in a jar file in a special directory - META-INF/resources. When included in the WEB-INF/lib directory of the webapp, if the container does not find a particular resource in the root directory of the webapp, it will look at the jar files in the WEB-INF/lib to see if the resource is bundled in META-INF/resources of any jar file and serve it up.
Security enhancements - programmatic authenticate, login and logout support. Support for @RolesAllowed, @PermitAll, @DenyAll annotations in the web container.
Updated existing APIs to use generics where possible in a backward compatible manner.
Default error pages for error codes.
Clarified welcome files.
File upload - We have a basic solution in place, which we will build upon in a future release of the Servlet specification.

Look out for the specification release (I will post an update when relased) and provide feedback.

If you are attending JavaOne this year, Jan Luehe (from Sun), Greg Wilkins(Jetty / Webtide) and I will be presenting the Servlet 3.0 features in a technical session - TS-3790 "Javaâ„¢ Servlet 3.0: Empowering Your Web Applications With Async, Extensibility and More"

JSR 245 MR: Part 2 - JSP

kchung — Tue, 03 Feb 2009 16:54:19 +0000

This is the second part of the update on JSP and EL specification. A previous blog covers the EL MR. This blog covers the JSP Specification MR. The details can be obtained from here. The close date for the MR is March 3, 2009. Please send comments to me.

The proposed JSP MR fixes some typos and errors, and adds some minor enhancements to JSP. This blog covers these enhancements.

Declare Default Content Type

Currently, the default content type is text/html for JSP pages in standard syntax and text/xml for pages in xml syntax. This can be overridden by the use the page directives in individual JSP pages. It would be sometimes desirable to set a content type, such as text/xhtml, for the whole application.

The MR adds a JSP configuration element default-content-type to the jsp-property-group element. It can be used to set the default content type for a group of JSP pages that matches the URL pattern defined in the jsp-property-group.
Set Default Buffer Size

Likewise, the MR adds a JSP configuration element buffer to the jsp-property-group. It can be used to set the buffering model for a a group of JSP pages that matches the URL pattern defined in the jsp-property-group.
Raise Errors for Undeclared Namespaces

Currently, using an unknown namespace in standard JSP syntax is silently ignored, but is an error in xml syntax. This is somewhat inconsistent, to say the least.

Moreover, it is a common mistaken to omit the declaration of a tag library using the taglib directive before it is used in a JSP page. The end result is that the tag library is not invoked, and nothing is displayed. This often a source for confusion to page authors.

As a remedy, we add a error-on-undeclared-namespace element to the jsp-property-group. It can be used to force an error at compile time when undeclared namespaces are used in a group of JSP pages that matches the URL pattern defined in the jsp-property-group.
Omit Generation of Attribute in <jsp:element>

<jsp:element> can be used to generate dynamic tag elements on the fly, and <jsp:attribute> can be used to generate an attribute for the element. However it is currently not possible to conditionally omit the attribute. The most we can do now is to generate an attribute with a null value, but is not the same as an omitted attribute, for some browsers.

We now introduce an optional attribute omit to <jsp:attribute>. When it evaluates to true, the attribute is not generated in the <jsp:element>. Consider the following:
```
    <jsp:element name="image">
        <jsp:attribute omit=${width eq null}>
            ${width}
        </jsp:attribute>
        <jsp:body>
            body
        </jsp:body>
    </jsp:element>
```
When width is "100", for instance, the following is generated:
```
    <image width="100">
        body
    </image>
```
When width is null, the following is generated:
```
    <image>
        body
    </image>
```

The sources for the API and implementation will be done at the jsp project and will be bundled with Glassfish V3 release.

JSR 245 MR: Part I - Expression Language (EL)

kchung — Tue, 03 Feb 2009 10:42:21 +0000

This is a quick update on JSP and EL (Expression Language) specification.

Although the EL specification has been separated from the JSP specification, for various reasons, we have not taken the last step to create a new JSR for EL. The proposed work on the JSP MR and EL MR has been filed under JSR-245. The details can be obtained from here.

The close date for the MR is March 3, 2009. Please send comments to me.

This blog covers the EL MR.

One of the most requested feature enhancement to EL is the ability to invoke methods in EL expressions. The MethodExpression in the current EL can be used to specify a method in the EL expression. For instance, in the following JSF code fragment,

    <h:commandButton action="#{trader.buy}" value="buy"/>

the method buy in the bean trader is specified in EL. This method is is not invoked here, but instead, it is passed to the tag handler, and can only be invoked from Java codes. Also, the parameter types of the method cannot be obtained from the EL expression, but must be specified in the TLD (Tag Library Descriptor). At the method invocation, the actual arguments (also not specified in the EL expression) are coerced to the corresponding parameter types and passed to the method. As you can see, there are a lot things that need to be done in Java code to make a method call.

The proposed EL MR allows for specifying the method arguments, as well as the invocation of the method in the EL expression itself. The required changes in EL syntax to do this is surprisingly little. All we need to do to is add (what else) a list of arguments in parenthesis to the method calls. For instance, we can added the argument "JAVA" to above JSF fragment:

    <h:commandButton action="#{trader.buy('JAVA')}" value="buy"/>

One thing nice about this new syntax is that you can tell immediately that this is a method call, and that the method takes one parameter of the type String. Furthermore, we also specify the actual argument to pass to the method when invoked. There is no need to specify the parameter types in the TLD, and there is no hidden arguments in the method call.

Note in the above code, the EL expression, being a deferred method expression, does not cause the method to be invoked. To actually invoke the method and retrieve the method return value, we can write in a JSP page:

    The stock price bought: ${trader.buy('JAVA')}

Very nice!

Included in the EL MR is another feature that is related to method invocation, namely that of customization of method invocations with the use of custom ELResolvers. The default behavior for method calls, such as #{trader.buy('JAVA')} is to look for the method buy, using reflection, in the bean trader. This default behavior can be altered with custom ELResovler. A new method invoke is thus added to ELResolver and this method is used to resolve the evaluation of method calls in expressions, much like the method getValue is used to resolve the evaluation of properties in expressions. By providing custom ELResolvers, one can make "calls" to methods that are not in the bean class. In a sense, this feature enables the definition and invocation of macros, and can lead to some interesting applications.

The default behavior for method calls is handled by the class javax.el.BeanELResolver. Using reflection, it looks up the method in the bean class. Currently overloaded methods are not supported, and the number of arguments specified in the EL expression must matched that in the method signature. This is so because we don't want to specify complicated overload resolution rules in the EL specification.

However, the method ELResolver.invoke has a paramTypes argument that can be used to specify the formal parameter types for the method. If this argument is non-null, then the method with the same name and parameter types will be selected for invocation. Although the EL syntax does not allow the specification of parameter types in the method call, it can be done quite easily with an extended syntax. Borrowing from Javascript (I think) one can write, for instance

    #{trader['buy(java.lang.String)']('JAVA')}

to indicate a call to the method buy with String argument. This is currently not included in the MR, but if there are enough interest, it can be considered for the next version of the specification.

The source for the changes to EL api and implementation can be found from Unified Expression Language project. The basic functionalities have been implemented. The area that needs further work is in the overloaded method resolution, and performance.

Rebuttal of Greg Wilkin's Blog about Servlet 3.0 PR

Tue, 16 Dec 2008 07:34:54 +0000

Someone just pointed me to Greg Wilkin's latest blog entry. I tried posting my response in his comments however it was tagged as spam and not displayed. So I am making the comments available her.

I am REALLY surprised at this blog. Let me try to answer some of these questions in the public forum.

"This public draft of the servlet-3.0 represents a thought experiment in API design unhindered by the complexities of implementation, trial usage or community feedback."

An implementation of this is available in GlassFish in the trunk.

"As a member of this Expert Group, I've been as guilty as the other members by looking at uncompiled/untested APIs and believing them to solve the issues at hand, only to later discover that these APIs prove to be unworkable when implemented and/or used."

The APIs are implementable. Take a look at the GlassFish trunk.

"Requests for test implementations have been denied"

I never saw a request from you. In fact YOU offered to implement some of the features in Jetty and showcase the technology.

"Any feedback received on the jsr-315-comments@jcp.org list have been kept private and not shared even with the EG, despite several requests. "

Please check your email carefully. All the mails that I have received I have forwarded to the EG. Also I never saw a request from you to share feedback that is received.

"EG members and community feedback raised concerns about the security and ordering aspects of the automatic deployment possible with the Annotations and Pluggability feature (see below). The response was not the "How can we address these concerns" discussion that I was expecting. Instead the response was more along the lines of Obe-wan Kenobi saying "these are not the concerns you are looking for. Move along!" "

Looking into the security concerns we introduced the enabled, flag that can enable and disable servlets. Also like some of the other EG members pointed out that if a user does not know how a framework works he shouldn't be using it in the first place. Or if a framework is authored badly then it shouldn't be used in the first place. The problem is that you never get PAST what YOU suggest as a solution and YOU always think of solutions keeping that in mind.

"Alternately, some unsubstantiated requirements (eg. wrapped asynchronous requests) have been included at a late stage without any use-cases or user demand, which have introduced whole new dimensions of complexity so that discussions have been ratholed for months chasing marginal edge cases."

I don't believe that you say this. Late in the game and we rat holed more on the use case that you had as opposed to the wrapped use case. In fact if you remember, members of the EG were opposed to the re-dispatch semantics that we had. So please don't provide an incorrect picture to the people reading your blogs.

"Accidental Deployment"

We have had no such experience with the use of annotations in JAX-WS, EJB, and other places in the Java EE platform. Also there are ways to turn off the accidental deployment - use the enable flag to enable / disable servlets. Are you even paying attention to the solutions that the EG is working on providing?

"Slow Deployment"

Please provide numbers of how deployment is slowed down. If you just "feel" that deployment will slow down significantly it isn't good enough. In the Java EE 5 days we did the analysis of scanning of annotations and the result was that we didn't see any significant slowing down. I can share the numbers in the EG if you are REALLY interested in the problem.

"Ordering"

Yes this is a problem for the fragments. However there is a solution to use the web.xml to do the ordering. Also your blog seems to be getting confusing. On one hand you criticize the feature of pluggability with accidental deployment, slowing down deployment with scanning, and on the other hand you want to use the feature and not define everything in the web.xml? Make up your mind what you want? Use the feature or just keep using the web.xml as before.

As for the async rebuttal and everything else about the Async proposal just a few quotes from emails to the EG.

Quoting you -

"Excellent! This proposal is definitely better than suspend/resume!"

Quoting another EG member -

"Greg, I think you're being too aggressive. I do realize you care about the subject.

I think Rajiv's design is now quite fine, so using the "flood until he
agrees to my stuff" tactic is unfair. From what I've seen many have
stated a preference for his design (I have a coworker who's also not
very comfortable with your design). And the adapted code example looks
good to me too."

You have just taken this tactic outside the EG now because the EG members were starting to point this out to you.

I am really starting to agree with Bill Burke about the statement he made in his blog.

Update:

Maxim MoldenHauer, the IBM representative on the EG has also blogged on the issue.

Servlet 3.0 webinar

Thu, 11 Dec 2008 01:58:25 +0000

I will be presenting 3.0 in a webinar on December 18th. For details and logistics about the webinar go to http://wikis.sun.com/display/TheAquarium/Servlet3.0. If you would like to learn about the new features in servlet 3.0 I would definitely encourage you to attend the webinar.

Asynchronous support in Servlet 3.0

Thu, 11 Dec 2008 01:50:22 +0000

After the last couple of entries I have gotten requests for more details on how the async works. So I decided to write this up in a blog to share what the async support looks like in the Servlet 3.0 public review draft.

There are a couple of use cases that we are trying to handle with the async support in Servlet 3.0 -

Wait for a resource to become available (JDBC, call to webservice)
Generate response asynchronously
Use the existing frameworks to generate responses after waiting for the async operation to complete

Keeping this in mind the API that the expert group has agreed upon for async is as follows.

Annotation attributes in the @WebServlet and @ServletFilter annotations that indicates if a Servlet or a Filter supports async. The attribute is asyncSupported.
To initiate an async operation there are methods on ServletRequest - startAsync(req, res) and startAsync() (difference described below).
Call to startAsync returns an AsyncContext initialized with the request and response objects passed to the startAsync call.
AsyncContext.forward(path) and AsyncContext.forward() that forwards the request back to the container so you can use frameworks like JSP to generate the response.
AsyncContext.complete() indicates that the developer is done processing the request and generating the appropriate response.
There are a few more methods in ServletRequest like isAsyncSupported and isAsyncStarted that can be used by applications to determine if async operations are supported or started.
There is also a new listener - AsyncListener that applications can use to get notified of when async processing is completed or if a timeout occurs.

To initiate async processing there are two methods available - one that takes a request and response (startAsync(req, res) ) and one that does not take any parameters (startAsync()). The difference between the two method signatures is that the startAsync() with no parameters implicitly uses the original request and response while the startAsync(req, res) uses the request and response objects passed in. The request and response passed in can be wrapped by filters or other servlets earlier in the request processing chain. The AsyncContext is initialized appropriately with the request and response depending on the method used. Caution must be taken when wrapping the response and calling the no arguments startAsync(). If any data has been written to the wrapped response and not flushed to the underlying response stream you could lose the data.

Similarly after the async processing is over if you choose to forward the request back to run in the context of the web container there are three methods that are available in the AsyncContext that enable this. forward(path), forward(ServletContext, path) and forward().

forward() no args forwards back to the "original url" or if a forward (AsyncContext or RequestDispatcher forward) has occured after an async context has been initialized then the no args forward will forward to the path that was used by the AsyncContext / RequestDispatcher to forward to.
forward(path) forwards to the path relative to the context of the request

forward(ServletContext, path) forwards to the path relative to the context specified.

Below is an example that shows a simple web application that is waiting for a webservice call to return and then rendering the response. Note the actual code for calling the web service itself is not included.

@WebServlet("/foo" asyncSupported=true)
public class MyServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) {
        ...
        AsyncContext aCtx = request.startAsync(req, res);
        ScheduledThreadPoolExecutor executor = new ThreadPoolExecutor(10);
        executor.execute(new AsyncWebService(aCtx));
    }
}

public class AsyncWebService implements Runnable {
    AsyncContext ctx;
    public AsyncWebService(AsyncContext ctx) {
         this.ctx = ctx;
    }
    public void run() {
        // Invoke web service and save result in request attribute
        // Forward the request to render the result to a JSP. 
        ctx.forward("/render.jsp"); 
    }
}

If you would like to try it out use the nightly build of the GlassFish trunk and post any issues that you run into at webtier@glassfish.dev.java.net which the GlassFish webtier team monitors closely.

Adding custom handlers to GlassFish v3 loggers

Tue, 09 Dec 2008 22:08:19 +0000

I recently blogged about the changes to logging GlassFish Prelude. Building on that I wanted to show how to add custom handlers to your installation of v3. You may find that you want to log messages to a database, send them to a remote server or log messages from specific loggers to your own file. This can be done by writing a custom log handler. It is pretty straight forward and actually there are two approaches you can take to add the handler. Either you can write an HK2 service for the handler or a Java class as specified by the JDK. Either approach will work in GlassFish v3 Prelude so I have examples for both approaches in this blog. In the examples below I simple print some messages to a specific file but you can replace that code with something that interests you.

Option 1

First I'll implement the handler as a simple Java class. This requires for me to write a class that implements the Handler APIs, package it in a jar file and add the jar to the GlassFish classpath. The last step is to update the logging.properties file to include the name of the class of the handler. At server startup the handler is added to the root logger automatically. Since the handler is added to root logger it is available to all loggers.

My NewHandler class implements the publish, close and flush Handler APIs. In the publish method, my handler simply writes to a file all messages that come from the web and deployment loggers as those are the ones that I'm interested in seeing. All messages are still logged to server.log so nothing is lost.

package logging;

/**
 *
 * @author cmott
 */

import java.util.logging.*;
import java.io.BufferedWriter;
import java.io.FileWriter;
import java.io.IOException;

/**
 * New Handler
 *
 */
public class NewHandler extends Handler {

    static BufferedWriter f = null;
    String webLogger = "javax.enterprise.system.container.web";
    String deployLogger = "javax.enterprise.system.tools.deployment";

    public NewHandler(){
        try {
              String userDir = System.getProperty("user.dir");
              f = new BufferedWriter(new FileWriter(userDir + "/mylogging.log"));       
            } catch (IOException e) {
                System.out.println("not able to create log file."+e);
       }
    }

 /**
  * Overridden method used to capture log entries   *
  * @param record The log record to be written out.
  */
 public void publish(LogRecord record)
 {
  // first see if this entry should be filtered out
  // the filter should keep anything
  if ( getFilter()!=null ) {
   if ( !getFilter().isLoggable(record) )
    return;
  }
  
  try { 
     if (webLogger.equals(record.getLoggerName()) || deployLogger.equals(record.getLoggerName()) ) {
         f.write ("NewHandler output - ");
         f.write("logger name: "+record.getLoggerName());
         f.write(" source classname: "+record.getSourceClassName());
         f.write(" message: "+record.getMessage());
         f.newLine();
         f.flush();
     }
  } catch (IOException ex){
        System.out.println("not able to write to log file."+ex);
  }
 
 }
 
 /**
  * Called to close this log handler.
  */
 public void close()
 {
        try {
	     f.close();
        } catch (IOException ex){
  }
}
 
 /**
  * Called to flush any cached data 
  */
 public void flush()
 {
// not used
 }
}

Next I need to do is to package it in a jar file and copy that jar to glassfish/lib directory. By default the handler is associated with the root logger so all loggers will have messages send to the handler.

Update the property handler in the logging.properties file to include the name of the new handler as below.

handlers= java.util.logging.ConsoleHandler, logging.NewHandler

Restarting the server with the new jar file on the classpath will include the new handler. To test this out I deployed a simple web app and looked at the log file. There you will see the messages from the new handler we just wrote.

Option 2

The other option is to create service using HK2. See Chapter 2 Writing HK2 Components of the GlassFish documentation for more information on writing an HK2 component. Again you need to implement the handler code much like the example above. I started with that example and added code to make it an HK2 service. I had to implement PostConstruct and specify that the service contract is provided by the Handler.class which is part of the JDK. I built the module and then add the jar file to the GlassFish modules directory. At server startup the module is found and the handler is added to the root logger. The handler code now looks like:

package logging;

/**
 *
 * @author cmott
 */
import org.jvnet.hk2.annotations.Inject;
import org.jvnet.hk2.annotations.Scoped;
import org.jvnet.hk2.annotations.Service;
import org.jvnet.hk2.annotations.*;
import org.jvnet.hk2.component.*;


import java.util.logging.*;
import java.io.BufferedWriter;
import java.io.FileWriter;
import java.io.IOException;

/**
 * New Handler
 *
 */
//specify that the contract is provided by handler.class in the JDK
@Service
@ContractProvided(Handler.class) 
@Scoped(Singleton.class)
public class NewHandler extends Handler implements PostConstruct {
    @Inject

    Habitat habitat;
    static BufferedWriter f = null;
    String webLogger = "javax.enterprise.system.container.web";
    String deployLogger = "javax.enterprise.system.tools.deployment";
    
    public void postConstruct(){
    	try {
             String userDir = System.getProperty("user.dir");
             f = new BufferedWriter(new FileWriter(userDir + "/mylogging.log"));       
    	} catch (IOException e) {
    		System.out.println("not able to create log file."+e);
    	}
    }
    
 /**
  * Overridden method used to capture log entries   *
  * @param record The log record to be written out.
  */
 public void publish(LogRecord record)
 {
  // first see if this entry should be filtered out
  // the filter should keep anything
  if ( getFilter()!=null ) {
   if ( !getFilter().isLoggable(record) )
    return;
  }

  try {
     if (webLogger.equals(record.getLoggerName()) || deployLogger.equals(record.getLoggerName()) ) {
         f.write ("NewHandler output - ");
         f.write("logger name: "+record.getLoggerName());
         f.write(" source classname: "+record.getSourceClassName());
         f.write(" message: "+record.getMessage()); 
         f.newLine();
         f.flush();
     }
  } catch (IOException ex){
  	System.out.println("not able to write to log file."+ex);
  }

 }

 /**
  * Called to close this log handler.
  */
 public void close()
 {
 	try {
	    f.close();
 	} catch (IOException ex){
  }
}

 /**
  * Called to flush any cached data that
  * this log handler may contain.
  */
 public void flush()
 {
// not used
 }
}

I created this as its own module and included the pom files I used to build the module below. In the example I have a very simple directory structure with handler-module as the parent containing one directory, handler. I've zipped up the standalone module, handler-module.zip rather than include the pom.xml files needed to create it.

There is no need to update the logging.properties file when creating a service. All that is needed is to drop the newly created jar file in the modules directory of the v3 installation. GlassFish detects the service in the modules directory automatically. Again I deployed a simple web app to test and look at mylogging.log file to see the expected messages.

That's it.

Servlet 3.0 - from the source

Wed, 03 Dec 2008 02:13:17 +0000

Since the Early draft of the specification for Servlet 3.0 (JSR 315) the expert group has been working on refining and improving the specificaiton in a couple of areas - Ease of Development (EoD), pluggability and asynchronous support. Below is a description of things that are in the soon to be available public review to enable each of these features.

Ease of Development (Eod)

In the early draft we added the annotations that allowed you to essentially write a Servlet as a POJO. However after some discussions in the expert group and feedback from some folks in the community, we decided to actually remove the method level annotations like @GET, @POST etc and keep the doGet, doPost method contracts and require extending an HttpServlet. However the top level annotations which are renamed for better usage in applications still exist. The @WebServlet annotation is used to declare a servlet, @ServletFilter to declare a filter and @WebServletContextListener to define ServletContextListeners. In addition to these annotations, other annotations like @Resource, which have been supported in web applications since Servlet 2.5 will continue to work as before. As an example a servlet declaration using Servlet 3.0 will now look like -
```
@WebServlet("/foo")
public class MyServlet extends HttpServlet {
    public void doGet(...) {
        ....
    }
}
```
Pluggability

Web frameworks built on top of servlets are very popular for developers and there are a lot of them that address various different problems. In order to better support frameworks for developers writing webapps we are adding ways in the servlet 3.0 specification to make it easier to use and configure frameworks of their choice. There are a couple of ways that enable pluggability -
- Methods to add Servlets and Filters - If a ServletContextListener is registered and wants to add a Servlet or Filter, then at the time of context initialization the event that is fired to the Listener can add Servlets and Filters to the context. The methods are addServlet and addFilter. For more details look for the javadocs when the specification is published.
- Web.xml fragments - Instead of having just one monolithic web.xml that is used by the developer to declare servlets, filters and other configuration for using the framework, the framework can now include a web-fragment.xml with all it's configuration. A web-fragment is almost identical to the web.xml and can contain all the configuration needed by the framework in the META-INF directory of the framework's jar file. The container will use the information to assembe the descriptor for the application and the application needn't have to use any of the boilerplate configuration in their app for the framework. There are rules that are defined int the specification for conflict resolution, overriding and disabling fragment scanning. Along with the annotations which also can be in libraries the feature is very compelling not only for the developers that use frameworks but also for framework authors to be self sufficient in defining the configuration needed.
Asynchronous processing
- This is the biggest change that we have made in the servlet 3.0 specification. In the early draft we had suspend and resume and certain semantics that were defined. However after the early draft the expert group had a lot of discussions on solving various use cases for asynchronous processing and the changes that are made to the specification in this area now also address the various use cases.
- Instead of suspend and resume we now have a startAsync method on request and there are two variations of these. One that takes a request and response in which case the AsyncContext that is created when you call startAsync will be initialized with the request and response passed in. The other is a startAsync() that takes no parameters, in which case the AsyncContext is initialized with the original request and response. Also the Servlets and Filters that support asynchronous processing must be annotated appropriately with asyncSupport attribute set. It is illegal to call startAsync if anywhere in the request processing chain you have have a servlet or a filter that does not support async.
- In addition to the AsyncContext there is also an AsyncListener that can be registered to get notifications on timeout and completion of async processing of a request. The event listener can be used to clean up resources if wrapped request and responses were used to initialize the AsyncContext.

Please take a look at the specification when it is published on the jcp.org website and send us your feedback at jsr-315-comments@jcp.org.

An early access implementation of some of the features are available in the GlassFish nightly build. For further discussion please post your questions about the implementation to webtier@glassfish.dev.java.net

Jetty 7 pre-release also has some of the features implemented for those interested.

Look for more blogs about these features from my colleagues Shing Wai and Jan Luehe on specifics of some of the implementation.

Servlet 3.0 (JSR 315) update

Tue, 02 Dec 2008 19:24:22 +0000

It's been a while since I gave an update about servlet 3.0. However while I haven't been blogging we at the expert group are working through refining and making the specification better for the web community. We are in the process of making the Public Review available and was waiting to push out a blog after that. However I have seen a few people write about the 3.0 work based on the Early Draft Review (EDR) (like http://www.theserverside.com/tt/tss)and thought it was best to clarify this so that there isn't any confusion arising from this.

The specification has evolved since the EDR and things have changed. the EDR is an early review to get feedback from the community. It is not the final version of the specification. Some of the changes that have happened since the EDR are :

The annotations to define the http methods (GET, POST, etc) are no longer there. One would still have the extend HttpServlet and use the contract specified there. The top level annotations for declaring a Servlet and Filter are still there and that the expert group still feels is needed and useful to the community. However they are no longer POJOs.
The fragments have evolved since the EDR and the rules for merging the fragments have been specified in the upcoming Public Review.
The asynchronous (or what people are referring to as continuations) has also evolved. First off the notion of continuations is different than async. We now have what the expert group considers a cleaner proposal that will be able to handle a lot more use cases.

As an example of some of the things that you will have to do as a developer -

@WebServlet("/foo")
public class MyServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) {
        //....
    }
}

The suspend and resume APIs are no longer there. Instead we have a startAsync on request that returns an AsyncContext that the users then can use to do async operations and not have to block a thread to complete the processing.

These are just a sneak peak at what is coming and would encourage users to look at the public review when it becomes avaialble at the jcp.org site and send feedback. In the mean time I also encourage people writing articles / blogs about servlet 3.0 to contact us at jsr-315-comments@jcp.org to get an update from the expert group so they can reflect the status of the specification correctly. I will be writing a more detailed blog with more samples show casing the features in the servlet 3.0 specification in the coming days so stay tuned.

jMaki 1.8.1 and GlassFish V3 released

Fri, 07 Nov 2008 17:50:54 +0000

You may be seen the announcement yesterday about the GlassFish V3 Prelude release. At the same time, we released jMaki 1.8.1. jMaki provides a framework for building Ajax applications and was fully tested on GlassFish V3 Prelude.

Highlights of the new features in jMaki include:

Drag and Drop widget support into HTML, PHP, Ruby pages
Performance enhancer
Widget Customizer
jMaki CSS Page Templates
Yahoo UI 2.6 Widgets
Dojo Dijit 1.2 Widgets
Scriptaculous 1.8.1 Widgets
jQuery UI 1.5b Widgets
Google 1.8.1 Widgets
jMaki 1.8.1 Widgets
jMaki Extras 1.8.1 Widgets

You can get jMaki from the download page or from the GlassFish update center. Enjoy!

GlassFish V3 logging changes

Tue, 28 Oct 2008 21:30:51 +0000

Logging in GlassFish V3 has undergone some changes to leverage the logging utility in JDK. This blogs reviews where we are with the logging mechanism in GlassFish Prelude and since not all of the features are implemented in the Prelude release yet, I'll go over how to make use of the functionality that is there.

The most significant change is that for now we don't have support in the Admin GUI or the command line tool asadmin. That support will be provided in the final release of GlassFish V3. For now, developers using Prelude will have to edit the logging.properties file found in the domain config directory where you find the domain.xml file. Let's take a look at what can be done.

Developers can update the logger level, change the log filename and set rotation of log files based on file size or a time limit. Some of these changes require a restart of the server and some don't.

First let's talk about setting log levels on loggers. Changes to logger levels are dynamic and don't require a server restart. At the end of the logging.properties file you will find a list of loggers in GlassFish. I have included the most common loggers so developers can easily find what they want. Below is an excerpt from that file.

#Tools Logger
#javax.enterprise.system.tools.level=FINE
# EJB Logger
#javax.enterprise.system.container.ejb.level=FINE
#JAVAMAIL_LOGGER
#javax.enterprise.resource.javamail.level=FINE
#JMS_LOGGER
#javax.enterprise.resource.jms.level=FINE
#WEB LOGGER
#javax.enterprise.system.container.web.level=FINE
#CMP_LOGGER
#javax.enterprise.system.container.cmp.level=FINE

By default all the logger levels are set to INFO because the root level is set to INFO. If the log level is not set on a logger then it inherits the level of its parent going up the chain until it finds a logger with the level set or it reaches the root logger. To set the level on a specific logger you simply uncomment the line in logging.properties corresponding to the logger and set the level appropriately. Upon saving the file the logging mechanism is notified of a change to the file and resets the log levels for all known loggers based on the information in the file. Note that you can create your own logger, specify the level in the logging.properties file and it will be updated too.

The log level values are SEVERE, WARNING, INFO, CONFIG, FINE, FINER, and FINEST. Each level includes messages of the level above it so if you set a logger to level INFO you will also get the SEVERE and WARNING messages in addition to the INFO.

One last note about log levels, it is valid to set the level of the loggers at any point in the logger name. For example, say you want all the loggers under javax.enterprise.system.container to print at the FINE level. You simply create a line as follows and save the file.

javax.enterprise.system.container.level=FINE

Once set, the logger level must be explicitly reset to change the level.

Setting file rotation is also done by changing properties in logging.properties. Changing these properties does require a server restart to take affect. There are two ways to set file rotation in Prelude. You can request files be rotated based on a file size or based on a time limit. The properties associated with file rotation are below.

# 0 for no rotation based on time
com.sun.enterprise.server.logging.FileandSyslogHandler.rotationTimelimitInMinutes=0
# rotation limit in bytes, 0 means no rotation, 500000 is the minimum
com.sun.enterprise.server.logging.FileandSyslogHandler.rotationLimitInBytes=0

By default both are set to 0 or no file rotation. If both are set then rotation will be based on time. You can specify the max size of the log file reached to rotate or create the next log file or the max elapsed time reached to rotate the log file.

For now developers will need to edit the logging.properties file and it should be pretty straight forward. But remember that the team is working on providing tool support for GlassFish V3 final so it will be easier soon.

Ajax Waiter

Mon, 27 Oct 2008 00:28:42 +0000

I came across a situation where I needed an Ajax style spinner but could not download any images. I extended concepts from the jMaki Revolver to make an image free spinner all in JavaScript.

  window.waiter.show({ speed: 1,
                       delay : 40,
                       targetId : 'body',
                       textColor : '#FFF',
                       background: 'green',
                       opacity : 85,
                       message : 'Please wait 2'});

Test on this page

For detailed documentation on all the properties and more examples see the Ajax Waiter.

If there are features or enhancements you would like to see let me know.

Enabling performance feature in jMaki

Thu, 23 Oct 2008 03:48:29 +0000

Last spring we added performance enhancements to jMaki based on well known guidelines for improving page load times. The guidelines are from Yahoo and we have automated several of them. Now developers can combine JavaScript code and place it at the end of the page, place combine CSS code and place it at the beginning of the page, use minified resources and set the max age header by simply setting some properties in their web app. For more information about the performance enhancements and what is happening under the hood, see the jMaki performance page. This blog details how to take advantage of those performance enhancements in your application.

I used Netbeans to create the web application but you can use Eclispe or a plain editor. In this example, I have the jMaki menu, tag cloud and blocklist widgets. You can use any jMaki wrapped widgets or custom jMaki widgets that you have created to take advantage of this feature. The page looks like:

&lt;%@ taglib prefix="a" uri="http://jmaki/v1.0/jsp" %&gt;
&lt;!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"&gt;

&lt;html&gt;
    &lt;head&gt;
        &lt;link rel="stylesheet" href="jmaki-2column-footer.css" type="text/css"&gt;&lt;/link&gt;
        &lt;title&gt;Page Title&lt;/title&gt;
        &lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /&gt;
        &lt;a:page&gt;
    &lt;/head&gt;
    &lt;body&gt;
        &lt;div id="border"&gt;
            
            &lt;div id="header"&gt;
                &lt;div id="banner"&gt;Application Name&lt;/div&gt;
                
                &lt;div id="subheader"&gt;
                    
                    &lt;div&gt;                      
&lt;a:widget name="jmaki.menu"
      value="{menu : [
       {label: 'Links',
            menu: [
                { label : 'Sun.com',
                  href : 'http://www.sun.com'},
                { label : 'jMaki.com',
                  href : 'http://www.jmaki.com'}
                ]
       },
       {label: 'Actions',
            menu: [
                { label : 'Select',
                  action :{topic: '/foo/select',
                         message: { targetId : 'bar'}}
                },
                { label :'Set Content',
                  action :{topic: '/foo/setContent',
                         message: { value : 'test.jsp'}}
                }
                ]}
                ]
       }" /&gt;


                    &lt;/div&gt;
                    
                &lt;/div&gt; &lt;!-- sub-header --&gt;
            &lt;/div&gt; &lt;!-- header --&gt;

            &lt;div id="main"&gt;
                &lt;div id="rightColumn" style="height:400px"&gt;

&lt;a:widget name="jmaki.blockList" value="[
        {title : 'jMaki Project Home', link : 'https://ajax.dev.java.net', description : 'Where to go for the latest jMaki.' },
        {title : 'jMaki Widgets Home', link : 'https://widgets.dev.java.net', description : 'The source for the latest jMaki widgets.' },
        {title : 'jMaki-Charting Home', link : 'https://jmaki-charting.dev.java.net', description : 'Enables complex charts rendered on the client in any modern browser.' }
    ]"  /&gt;


                &lt;/div&gt; &lt;!-- end leftColumn --&gt;

                &lt;div id="leftColumn" style="height:400px"&gt;
&lt;a:widget name="jmaki.tagcloud" value="{
  items : [
      { label : 'jMaki', weight : 70},
      { label : 'Web2.0', weight : 150},
      { label : 'JSON', weight : 80},
      { label : 'JavaScript', weight : 145},
      { label : 'Java', weight : 100},
      { label : 'RSS', weight : 85},
      { label : 'Autocomplete', weight : 75},
      { label : 'Sun', weight : 65, href : 'http://www.sun.com'},
      { label : 'jMaki', weight : 150},
      { label : 'Web3.0', weight : 70},
      { label : 'Phobos', weight : 105},
      { label : 'Glassfish', weight : 120},
      { label : 'RSS2.0', weight : 75},
      { label : 'Web1.0', weight : 50},
      { label : 'JavaEE', weight : 75},
      { label : 'Jersey', weight : 115},
      { label : 'Roller', weight : 150},
      { label : 'CSS', weight : 105},
      { label : 'DHTML', weight : 65},
      { label : 'Netbeans', weight : 115, href : 'http://www.netbeans.com'}
  ]
}" /&gt;

                &lt;/div&gt; &lt;!-- leftColumn --&gt;

            &lt;/div&gt; &lt;!-- main --&gt;
            &lt;div id="footer"&gt;Footer&lt;/div&gt;
        &lt;/div&gt; &lt;!-- border --&gt;
        &lt;/a:page&gt;
    &lt;/body&gt;
&lt;/html&gt;

This is a typical jMaki page expect I added 2 new tags. The <a:page> tag at the beginning tells the jMaki performance code to drop the CSS code and should be in the header. The closing </a:page> tag tells jMaki where to drop the combined JavaScript code and should be the last line in the body typically.

One other change required is to the web.xml file. You will need to set some properties to true and to configure the servlet that does the work. The following needs to be added to the web.xml file.

   &lt;context-param&gt;
        &lt;param-name&gt;jmaki-combinescripts&lt;/param-name&gt;
        &lt;param-value&gt;true&lt;/param-value&gt;
    &lt;/context-param&gt;
    &lt;context-param&gt;
        &lt;param-name&gt;jmaki-combinestyles&lt;/param-name&gt;
        &lt;param-value&gt;true&lt;/param-value&gt;
    &lt;/context-param&gt;

    &lt;servlet&gt;
        &lt;servlet-name&gt;Combined Resource Servlet&lt;/servlet-name&gt;
        &lt;servlet-class&gt;jmaki.runtime.CombinedResourceServlet&lt;/servlet-class&gt;
        &lt;load-on-startup&gt;2&lt;/load-on-startup&gt;
        &lt;/servlet&gt;
        
    &lt;servlet-mapping&gt;
        &lt;servlet-name&gt;Combined Resource Servlet&lt;/servlet-name&gt;
        &lt;url-pattern&gt;/cr&lt;/url-pattern&gt;
    &lt;/servlet-mapping&gt;

That's it. Look at the page source of the deployed application and you will see that things have been moved around. One application reported a 30% improvement in page load time by simply setting these properties.

Try it out and let us know what improvements you see.

Happy Birthday NetBeans from jMaki

Wed, 22 Oct 2008 00:00:41 +0000

I was happy to see that the NetBeans birthday celebration page uses the jMaki revolver widget. Go to netbeans.org/birthday and you will find the revolver used to easily access an interview with James Gosling, pages pointing to community members, a contest and more. It's a great use of the widget.

Happy Birthday NetBeans!

"JSF and Ajax Past, Present and Future" @ AjaxWorld

Fri, 17 Oct 2008 14:13:34 +0000

Andy Schwartz (Oracle Corp/JSF 2.0 EG member) and I will be speaking at Ajax World next week on JSF and Ajax Past, Present and Future.

The session will explore the variety of JSF Ajax frameworks available today. Then you will get a preview of the Ajax work that is being standardized in the JSF 2.0 specification.

JavaServer Faces 2.0 Early Draft Review 2 And JavaScript?

Mon, 15 Sep 2008 13:41:20 +0000

The JavaScript public API is the beginnings of the client side portion of
the JavaServer Faces / Ajax standard. The JavaServer Faces 2.0 Expert Group includes members representing other JavaServer Faces / Ajax frameworks such as RichFaces, ADF Faces (Trinidad) and ICEfaces.

We're definitely exploring new territory here, as this is the first time
that a public JavaScript API has been introduced with JavaServer Faces to the JCP. It may be the first time a public JavaScript API has been
introduced to the JCP, period.

Getting server side data into a jMaki widget

Mon, 25 Aug 2008 16:53:15 +0000

I got to help out with the EJB 3.1 keynote demo for JavaOne. Although the demo shows how simple it is to perform CRUD operations using EJB 3.1, this blog focuses on the communication between the client side jMaki components and server side servlet.

For more information on the new EJB features in GlassFish v3 see Mahesh's blog. The demo uses some of the latest features in EJB 3.1 and MySQL for a backend data store. I will discuss the client side code for passing data to the server and getting data from the server and displaying it in a widget. The demo shows how simple it is to perform CRUD operations using EJB 3.1.

One requirement was to use the Dojo's Fisheye widget since it looks cool and so I created a set of pages, one each for the operations create, update and delete. The appropriate page is selected using the fisheye widget so the user could provide the necessary data. Once the user submitted the data I could then send the request to the server to update the database.

In this demo, I used the Dojo fisheye widget for navigation, html forms for collecting data from the user, Yahoo dialog for displaying errors and a Dojo table to display the data. The server side code is specific to EJB 3.1 and so must run on GlassFish V3 with the EJB module installed. MySQL data base is used for storing data.

A screen shot of the demo:

Let's look at some of the details. The code for the index.jsp page follows. Notice that the table is getting data from the servlet "/AuthorServlet" which is returning data in JSON format. The data base is prepopulated with data so the table is rendered with some rows of data. I dropped the Yahoo dialogs in the page and made them not visible. The fisheye widget is used for navigation and there are three other pages in the application which are loaded by the dcontainer based on the selection by the fisheye. More details on that below.

&lt;%@ taglib prefix="a" uri="http://jmaki/v1.0/jsp" %&gt;
&lt;!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"&gt;

&lt;html&gt;
    &lt;head&gt;
        &lt;link rel="stylesheet" href="jmaki-2column-footer.css" type="text/css"&gt;&lt;/link&gt;
        &lt;title&gt;Page Title&lt;/title&gt;
        &lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /&gt;
    &lt;/head&gt;
    &lt;body&gt;
        &lt;div id="border"&gt;
            
            &lt;div id="header"&gt;
                &lt;div id="banner"&gt;CRUD operations using EJB 3.1 &lt;/div&gt;
                               
            &lt;/div&gt; &lt;!-- header --&gt;

            &lt;div id="main"&gt;
                &lt;div id="rightColumn" style="height:600px"&gt;
                    &lt;div id="rightColumnTop" style="height:180px"&gt;
                        &lt;div id="rightColunmTopTable" style="height:180px"&gt;

             &lt;a:widget
                      name="jmaki.dcontainer"
                      subscribe="/jmaki/forms"
                      value="{
                            items : [
                              { id : 'create',include : 'create.jsp', overflow : 'hidden'}, 
                              { id : 'update', include : 'update.jsp', overflow : 'hidden', lazyLoad : true},
                              { id : 'delete', include : 'delete.jsp', overflow : 'hidden', lazyLoad : true}
                             ]
                          }"/&gt;  
                  &lt;/div&gt;
                  &lt;div id="rightColumnTopImages" style="height:180px"&gt;
                      Powered by:
                      &lt;div&gt;
                      &lt;img src="images/glassfish-logo.jpg"&gt;
                  &lt;/div&gt;
                  &lt;div&gt;
                      &lt;img src="images/jmaki-seal.png"&gt;
                  &lt;/div&gt;
                  &lt;/div&gt;
                &lt;/div&gt; &lt;!-- end leftColumn --&gt;
                &lt;div id="rightColumnBottom" style="height:415px"&gt;
             
             &lt;!--&lt;center&gt;Author Table &lt;/center&gt;--&gt;
             
             &lt;a:widget name="dojo.table"
            service="/AuthorServlet" /&gt;
                    
                &lt;/div&gt; &lt;!-- end leftColumn --&gt;
                                 
                &lt;/div&gt; &lt;!-- end leftColumn --&gt;

                &lt;div id="leftColumn" style="height:600px"&gt;
                    &lt;a:widget name="dojo.fisheye" args="{orientation:'vertical'}" value="[ 
     {iconSrc:'images/document-new.png',
      label : 'Create',
      action : { topic : '/jmaki/forms/select', message : {targetId : 'create'}}
     },
     {iconSrc:'images/edit-find-replace.png',
      label : 'Update',
      action : { topic : '/jmaki/forms/select', message : {targetId : 'update'}}
      },
      {iconSrc:'images/edit-delete.png',
      label : 'Delete',
      action : { topic : '/jmaki/forms/select', message : {targetId : 'delete'}}
      }
     ]"/&gt;

        &lt;a:widget id="dialog1" name="yahoo.simpledlg"args="{header : 'Error Found', visible: false, text: 'Duplicate Author Id entry found.  Provide a unique Author Id'}"
                    value="{buttons: [ 
        { label:'ok', isDefault:true }
        ] }"/&gt;

        &lt;a:widget id="dialog2" name="yahoo.simpledlg"args="{header : 'Error Found', visible: false, text:  'Author Id entry not found.  Provide a Author Id'}"
                    value="{buttons: [ 
        { label:'ok', isDefault:true }
        ] }"/&gt;
          
                &lt;/div&gt; &lt;!-- leftColumn --&gt;

            &lt;/div&gt; &lt;!-- main --&gt;

        &lt;/div&gt; &lt;!-- border --&gt;
    &lt;/body&gt;
&lt;/html&gt;

Now lets look at how to create an entry in the data which will be reflected in the table. First let's look at the page create.jsp.

 Enter Data to Create Author Entry: &lt;br&gt;&lt;br&gt;
  
  
                  &lt;form name="create"  &gt;
  Author Id: &lt;input type="text" id="authorId" name=authorId/&gt; &lt;br&gt;
  Author: &lt;input type="text" id="authorName" name=authorName/&gt;&lt;br&gt;
  Organization: &lt;input type="text" id="organization" name=organization/&gt;&lt;br&gt;
  &lt;br&gt;&lt;br&gt; 
   &lt;input type="hidden"  id="hidden" name="create" value="create"&gt;
   &lt;input type="button" onclick="doCreate()" name="submit" value="create"&gt;
  &lt;/form&gt;

As you can see this is a simple form which calls the doCreate function to extract the data. The doCreate function is in glue.js.

var Service="/crud/AuthorServlet";
var rowId;

function doCreate(){
    var opName = "create";
    
    var authorName = document.getElementById("authorName").value;
    var authorId = document.getElementById("authorId").value;
    var orgName = document.getElementById("organization").value;
       
      jmaki.doAjax({method: "POST",
        url: "/crud/AuthorServlet",
        content :  { authorName: authorName, authorId : authorId, orgName : orgName, opName: opName }, 
        callback: function(_req) {
            var tmp = _req.responseText;
	    if(!tmp)  {
                 var a = jmaki.getWidget("dialog1");
                 a.setVisible(true);
            }  else {
	       var obj = eval("(" + tmp + ")");
                if ( opName == "create")
                     jmaki.publish('/table/addRow', obj);
		else {
		    jmaki.publish('/table/updateRow', obj);
	       }
	   }
        },
        onerror: function() {
                 var a = jmaki.getWidget("dialog1");
                 a.setVisible(true);            
                    }
     });
     document.forms.create.reset();

}

After extracting the data from the form I use jmaki.doAjax to send the data to the server. I use the property "content" with the values I extracted because this property will pass the data to the server correctly regardless of the platform. In other words the right thing happens if the server is Java or PHP. The callback function is called if there were no errors on the server and if so the data received is passed to the table using the standard jMaki publish and subscribe mechanism. If there was an error on the server the onerror function is called and in this case I set the error dialog to visible.

Here is a screen shot of the application with the error dialog:

Finally I wanted to describe how the fisheye is used to display the correct form. Looking at the fisheye widget tag you see that each icon will publish to the "/jmaki/forms/select" and the payload contains a string used to identify the operation selected. The dcontainer subscribes the the "/jmaki/forms" topic. The dcontainer contains a select handler which looks up the id that it was passed, in this case 'create' and the includes the page create.jsp.

I have posted the war file on the documents and files demo area. I also have the processRequest method from the AuthorServlet code below so it is easier to see what the server is doing. There are several helper classes that update the data base or convert Java objects into JSON that are not shown.

@PersistenceUnit(name="myAuthorEMF", unitName = "WebEjbJpaPU")
public class AuthorServlet extends HttpServlet {
   
    @EJB private AuthorBean authorRef;
    
    //private AuthorHelper authorRef = new AuthorHelper();
    
    /**         
    * Processes requests for both HTTP [prettify]GET

and POST methods. * @param request servlet request * @param response servlet response */ protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { PrintWriter out = response.getWriter(); try { String opName = request.getParameter("opName"); int matchID = -1; Author author = null; if (opName == null) { opName = "list"; } else { author = new Author(); author.setAuthorId( Integer.valueOf(request.getParameter("authorId"))); author.setName(request.getParameter("authorName")); author.setOrganisation(request.getParameter("orgName")); } if ("update".equals(opName)) { authorRef.updateAuthor(author); } else if ("create".equals(opName)) { authorRef.createAuthor(author); } else if ("delete".equals(opName)) { authorRef.deleteAuthor(author); } sendOutData(author, opName, out); } finally { out.close(); } } [/prettify]

That's it.

Writing jMaki widgets in the real world

Wed, 20 Aug 2008 21:00:34 +0000

I found that TravelMuse is a great site to help plan vacations and I was excited to learn that they use jMaki to build the site.

Daniel Ziaoure is the lead Web developer for TravelMuse and uses jMaki extensively. We were lucky enough to have him join us during our Community One day presentation on jMaki. He recently started a series of articles explaining how he uses the jMaki widget model and communication mechanism to build the useful and impressive site. His first article Building an Ajax Login with jMaki shows how he used jMaki to build an Ajax enable login widget.

irc channel for GlassFish webtier

Tue, 05 Aug 2008 17:51:58 +0000

We now have a dedicated irc channel for the GlassFish webtier where you can chat with the engineering team members. It is on irc.freenode.net. For help on how to use irc, the clients for the various OS click here.
There is also a FAQ for freenode that you should refer to for any questions regarding usage of freenode. It is located here.

Update: Someone pointed out that I forgot to put the channel name - it is glassfish-webtier.

Job Opportunity in GlassFish Web Container Team

arungupta — Thu, 24 Jul 2008 05:00:00 +0000

What's common between

Close to 5 million downloads per year
> 1000 emails/month by users
Continuously growing adoption and
Hiring

You are right - GlassFish is the answer!

If you are a fresh graduate, then apply for GlassFish Scripting team. However if you have

Experience in Developing Web container and related web-tier technologies such as JSP, Servlets, Java Server Faces and Java Standard Tag Libraries
Like to define the direction of Web container in Java EE platform and GlassFish Application Server
Worked in the Open Source & distributed teams
Like to play "follow the leader" where you are the leader :)

Then GlassFish team needs you. Apply now!

Technorati: glassfish webtier jsp servlets jstl javaserverfaces job

Substruct on GlassFish v3 - Ruby-on-Rails E-Commerce Application

arungupta — Mon, 30 Jun 2008 05:00:00 +0000

Substruct is an open-source E-Commerce project written using Ruby-on-Rails framework. It provides a simple e-commerce platform, content management system and customer response system - all in one.

I found out about this application from Sang "Passion" Shin's Lab 5542 (part of FREE 20-week course on Ruby-on-Rails starting on Jul 15, 2008). But instead of using standard WEBrick/Mongrel deployment, I describe the steps to deploy this application using GlassFish v3 Gem. The GlassFish Gem installation is described here.

Download and install Substruct

~/samples/jruby >gunzip -c substruct_rel_1-0-a3.tar.gz | tar xvf -
substruct_rel_1-0-a3/
substruct_rel_1-0-a3/app/
substruct_rel_1-0-a3/app/controllers/
substruct_rel_1-0-a3/app/controllers/application.rb
. . .
substruct_rel_1-0-a3/vendor/rails/railties/test/rails_info_test.rb
substruct_rel_1-0-a3/vendor/rails/railties/test/secret_key_generation_test.rb
substruct_rel_1-0-a3/vendor/rails/Rakefile
substruct_rel_1-0-a3/vendor/rails/release.rb

Install the required gems for Substruct

~/samples/jruby >~/testbed/jruby-1.1.2/bin/jruby -S gem install RedCloth fastercsv mime-types mini_magick ezcrypto jruby-openssl --no-ri --no-rdoc
JRuby limited openssl loaded. gem install jruby-openssl for full support.
http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
Bulk updating Gem source index for: http://gems.rubyforge.org/
Successfully installed RedCloth-3.0.4
Successfully installed fastercsv-1.2.3
Successfully installed mime-types-1.15
Successfully installed rubyforge-1.0.0
Successfully installed hoe-1.5.3
Successfully installed mini_magick-1.2.3
Successfully installed ezcrypto-0.7
Successfully installed jruby-openssl-0.2.3
8 gems installed

Create the database

~/samples/jruby/substruct_rel_1-0-a3 >~/testbed/jruby-1.1.2/bin/jruby -S rake db:create
(in /Users/arungupta/samples/jruby/substruct_rel_1-0-a3)
[SUBSTRUCT WARNING]
Mail server settings have not been initialized.
Check to make sure they've been set in the admin panel.

And bootstrap it as

~/samples/jruby/substruct_rel_1-0-a3 >~/tesbted/jruby-1.1.2/bin/jruby -S rake substruct:db:bootstrap
(in /Users/arungupta/samples/jruby/substruct_rel_1-0-a3)
Checking requirements...
Initializing database...
[SUBSTRUCT WARNING]
Mail server settings have not been initialized.
Check to make sure they've been set in the admin panel.
-- create_table("content_nodes", {:force=>true})
   -> 0.3020s
-- add_index("content_nodes", ["name"], {:name=>"name"})
   -> 0.0140s
-- add_index("content_nodes", ["type", "id"], {:name=>"type"})
. . .
-- initialize_schema_information()
   -> 0.0200s
-- columns("schema_info")
   -> 0.0650s
Clearing previous data...
Removing all sessions...
Loading default data...
...done.
================================================================================

Thanks for trying Substruct 1.0.a3

Now you can start the application with 'script/server'
visit: http://localhost:3000/admin, and log in with admin / admin.

For help, visit the following:
Official Substruct Sites
    - http://substruct.subimage.com
    - http://code.google.com/p/substruct/
Substruct Google Group - http://groups.google.com/group/substruct

- Subimage LLC - http://www.subimage.com

And finally run it on the GlassFish as:

~/samples/jruby >~/testbed/jruby-1.1.2/bin/jruby -S glassfish_rails substruct_rel_1-0-a3
May 28, 2008 1:47:46 PM com.sun.enterprise.glassfish.bootstrap.ASMain main
INFO: Launching GlassFish on HK2 platform
May 28, 2008 1:47:46 PM com.sun.enterprise.glassfish.bootstrap.ASMainHK2 findDerbyClient
INFO: Cannot find javadb client jar file, jdbc driver not available
May 28, 2008 1:47:47 PM com.sun.enterprise.v3.services.impl.GrizzlyProxy start
INFO: Listening on port 3000
May 28, 2008 1:47:47 PM com.sun.enterprise.v3.services.impl.GrizzlyEmbeddedHttpConfigurator configureSSL
WARNING: pewebcontainer.all_ssl_protocols_disabled
May 28, 2008 1:47:47 PM com.sun.enterprise.v3.services.impl.GrizzlyEmbeddedHttpConfigurator configureSSL
WARNING: pewebcontainer.all_ssl_ciphers_disabled
May 28, 2008 1:47:47 PM com.sun.enterprise.v3.services.impl.GrizzlyProxy start
INFO: Listening on port 3131
May 28, 2008 1:47:47 PM com.sun.enterprise.v3.services.impl.GrizzlyProxy start
INFO: Listening on port 3838
May 28, 2008 1:47:48 PM com.sun.enterprise.v3.admin.adapter.AdminConsoleAdapter setContextRoot
INFO: Admin Console Adapter: context root: /admin
May 28, 2008 1:47:48 PM com.sun.enterprise.rails.RailsDeployer registerAdapter
INFO: Loading application substruct_rel_1-0-a3 at /
May 28, 2008 1:47:48 PM
INFO: Starting Rails instances
May 28, 2008 1:47:56 PM com.sun.grizzly.jruby.RubyObjectPool$1 run
INFO: Rails instance instantiation took : 8800ms
May 28, 2008 1:47:56 PM com.sun.enterprise.v3.server.AppServerStartup run
INFO: Glassfish v3 started in 10403 ms

The welcome screenshot looks like

Now copy GlassFish logo image file to "public/images" directory of your application and add the following line to "app/views/layouts/main.rhtml" file (on line 36):

<a href="http://glassfish.org"><%= image_tag('/images/glassfish-logo.gif', :alt => 'GlassFish') %></a>

The modified view looks like as shown below:

The updated output looks like:

I tried only the basic deployment and that seem to work. If you try slightly more advanced usecases then the functionality provided by RedCloth, fastercsv, mime-types, mini_magick and ezcrypto gems can be exercised as well. If you are running Substruct, try it and let us know.

If your Rails application does not work on the gem, file bugs here with "jruby" as "subcomponent" (default version is "v3").

Also check out Redmine on GlassFish v3.

Technorati: rubyonrails glassfish netbeans substruct webtier

GlassFish and jMaki @ RailsConf Today

arungupta — Fri, 30 May 2008 06:42:24 +0000

I was originally planning to give my first talk at Rails Conf on "Rails powered by GlassFish and jMaki". But I cannot travel for personal reasons and instead Craig McClanahan, who is an excellent speaker, has graciously agreed to speak. Craig has been involved with Rails, GlassFish and jMaki for a long time so feel free to poke hime at the talk, in the exhibit hall and afterwards.

Thanks Craig for the wishes! I had a great time @ RailsConf 2007 (here and here) but life is about priorities :)

More information about support for Dynamic Languages and their Frameworks on GlassFish can be found on glassfish-scripting.dev.java.net.

Technorati: conf railsconf railsconf08 jruby ruby rubyonrails glassfish jmaki webtier

JRuby 1.1.2 released - Getting Started with v3 Gem

arungupta — Wed, 28 May 2008 23:45:00 +0000

JRuby 1.1.2 was released yesterday - download here!

The highlights are:

Startup time drastically reduced
YAML symbol parsing >100x faster
Performance, threading, and stack depth improvements for method calls
Fixed several nested backref problems
Fixed bad data race (JRUBY-2483)
Gazillions of bigdecimal issues fixed
95 issues resolved since JRuby 1.1.1

Getting started is really simple, just follow the steps listed below.

Unzip JRuby 1.1.2 zip bundle ...

~/testbed/ >unzip ~/Downloads/jruby-bin-1.1.2.zip
Archive: /Users/arungupta/Downloads/jruby-bin-1.1.2.zip
creating: jruby-1.1.2/
creating: jruby-1.1.2/bin/
inflating: jruby-1.1.2/bin/_jrubycleanup.bat
inflating: jruby-1.1.2/bin/_jrubyvars.bat
. . .
inflating: jruby-1.1.2/share/ri/1.8/system/Zlib/crc_table-c.yaml
inflating: jruby-1.1.2/share/ri/1.8/system/Zlib/zlib_version-c.yaml
inflating: jruby-1.1.2/share/ri/1.8/system/created.rid
inflating: jruby-1.1.2/share/ri/1.8/system/fatal/cdesc-fatal.yaml
~/testbed >

... and then install Rails and GlassFish v3 gem ...

~/testbed/jruby-1.1.2 >bin/jruby -S gem install rails glassfish --no-ri --no-rdoc
JRuby limited openssl loaded. gem install jruby-openssl for full support.
http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
Bulk updating Gem source index for: http://gems.rubyforge.org/
Bulk updating Gem source index for: http://gems.rubyforge.org/
Successfully installed activesupport-2.0.2
Successfully installed activerecord-2.0.2
Successfully installed actionpack-2.0.2
Successfully installed actionmailer-2.0.2
Successfully installed activeresource-2.0.2
Successfully installed rails-2.0.2
Successfully installed glassfish-0.2.0-universal-java
6 gems installed

... and verify ...

~/testbed/jruby-1.1.2 >bin/jruby -S gem list g

\*\*\* LOCAL GEMS \*\*\*

glassfish (0.2.0)

... and now host any of your Rails application on v3 Gem (such as Redmine) ...

~/testbed/redmine >../jruby-1.1.2/bin/jruby -S glassfish_rails redmine-0.7
May 28, 2008 12:07:19 PM com.sun.enterprise.glassfish.bootstrap.ASMain main
INFO: Launching GlassFish on HK2 platform
May 28, 2008 12:07:19 PM com.sun.enterprise.glassfish.bootstrap.ASMainHK2 findDerbyClient
INFO: Cannot find javadb client jar file, jdbc driver not available
May 28, 2008 12:07:20 PM com.sun.enterprise.v3.services.impl.GrizzlyProxy start
INFO: Listening on port 3000
May 28, 2008 12:07:20 PM com.sun.enterprise.v3.services.impl.GrizzlyEmbeddedHttpConfigurator configureSSL
WARNING: pewebcontainer.all_ssl_protocols_disabled
May 28, 2008 12:07:20 PM com.sun.enterprise.v3.services.impl.GrizzlyEmbeddedHttpConfigurator configureSSL
WARNING: pewebcontainer.all_ssl_ciphers_disabled
May 28, 2008 12:07:20 PM com.sun.enterprise.v3.services.impl.GrizzlyProxy start
INFO: Listening on port 3131
May 28, 2008 12:07:20 PM com.sun.enterprise.v3.services.impl.GrizzlyProxy start
INFO: Listening on port 3838
May 28, 2008 12:07:21 PM com.sun.enterprise.v3.admin.adapter.AdminConsoleAdapter setContextRoot
INFO: Admin Console Adapter: context root: /admin
May 28, 2008 12:07:21 PM com.sun.enterprise.rails.RailsDeployer registerAdapter
INFO: Loading application redmine-0.7 at /
May 28, 2008 12:07:21 PM
INFO: Starting Rails instances
May 28, 2008 12:07:26 PM
SEVERE: JRuby limited openssl loaded. gem install jruby-openssl for full support.
http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
May 28, 2008 12:07:32 PM com.sun.grizzly.jruby.RubyObjectPool$1 run
INFO: Rails instance instantiation took : 11481ms
May 28, 2008 12:07:32 PM com.sun.enterprise.v3.server.AppServerStartup run
INFO: Glassfish v3 started in 12787 ms

Below is the screenshot from a previously deployed Redmine application, now on the GlassFish gem:

Simple isn't it ?

If your Rails application does not work on the gem, file bugs here with "jruby" as "subcomponent" (default version is "v3").

Alternatively, you can download GlassFish v3 TP2 and deploy your applications to leverage complete Java EE functionality.

You can also configure JRuby 1.1.2 as a Ruby platform in NetBeans 6.1 as described in TOTD #27.

Technorati: jruby ruby rubyonrails glassfish v3 gem redmine netbeans webtier

Redmine on GlassFish - Ruby-on-Rails Project Management Application

arungupta — Fri, 23 May 2008 06:00:00 +0000

Redmine is a flexible project management web application written using Ruby on Rails framework. The feature list is pretty comprehensive from the usual suspects like multiple projects, role-based control, forums/wikis/SCM for each project to enterprise level features such as LDAP-authentication and multiple languages. It is cross-platform and cross-database and deploys very nicely on GlassFish v3.

GlassFish v3 modularity and extensibility allows Rails applications to be deployed without any modification (no WARing). This blog explains the steps on how to deploy Redmine on GlassFish and shows some screenshots later. More documentation is available in Redmine Guide.

Check out the most stable release of Redmine by giving the command:

~/testbed/redmine >svn co http://redmine.rubyforge.org/svn/branches/0.7-stable redmine-0.7
Configure the database

Start your MySQL server

~/testbed/redmine >sudo mysqld_safe --user root
Starting mysqld daemon with databases from /usr/local/mysql/data
Create the database as:

~/testbed/redmine/redmine-0.7 >../jruby-1.1.1/bin/jruby -S rake db:create
(in /Users/arungupta/testbed/redmine/redmine-0.7)

Migrate the database as:

~/testbed/redmine/redmine-0.7 >../jruby-1.1.1/bin/jruby -S rake db:migrate
(in /Users/arungupta/testbed/redmine/redmine-0.7)
== 1 Setup: migrating =========================================================
-- create_table("attachments", {:force=>true})
   -> 0.2840s
-- create_table("auth_sources", {:force=>true})
   -> 0.0540s
-- create_table("custom_fields", {:force=>true})
   -> 0.0430s
-- create_table("custom_fields_projects", {:id=>false, :force=>true})
   -> 0.0080s
-- create_table("custom_fields_trackers", {:id=>false, :force=>true})
   -> 0.0500s

. . .

== 90 ChangeVersionsNameLimit: migrating ======================================
-- change_column(:versions, :name, :string, {:limit=>nil})
   -> 0.0220s
== 90 ChangeVersionsNameLimit: migrated (0.0220s) =============================

== 91 ChangeChangesetsRevisionToString: migrating =============================
-- change_column(:changesets, :revision, :string, {:null=>false})
   -> 0.0210s
== 91 ChangeChangesetsRevisionToString: migrated (0.0230s) ====================

== 92 ChangeChangesFromRevisionToString: migrating ============================
-- change_column(:changes, :from_revision, :string)
   -> 0.0130s
== 92 ChangeChangesFromRevisionToString: migrated (0.0150s) ===================

Download, Install and Configure GlassFish v3

Download GlassFish v3 from here.
Unzip the downloaded bundle.
Add the following fragment as the last line in "glassfishv3-tp2/glassfish/config/asenv.conf" file:

JRUBY_HOME="/Users/arungupta/testbed/redmine/jruby-1.1.1"

Deploy Redmine as:

~/testbed/redmine >./glassfishv3-tp2/glassfish/bin/asadmin deploy redmine-0.7
Command deploy executed successfully.

... and the GlassFish console shows:

May 21, 2008 4:58:30 PM com.sun.enterprise.rails.RailsDeployer registerAdapter
INFO: Loading application redmine-0.7 at /redmine-0.7
May 21, 2008 4:58:30 PM
INFO: Starting Rails instances
May 21, 2008 4:58:37 PM
SEVERE: JRuby limited openssl loaded. gem install jruby-openssl for full support.
http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
May 21, 2008 4:58:42 PM com.sun.grizzly.jruby.RubyObjectPool$1 run
INFO: Rails instance instantiation took : 11979ms
May 21, 2008 4:58:42 PM com.sun.enterprise.v3.deployment.DeployCommand execute
INFO: Deployment of redmine-0.7 done is 12091 ms

That's it, your application is ready to be used! Here are some screen snapshots from my trial run:

Rails powered by the GlassFish Application Server provides all the good reasons on why you should consider using GlassFish instead of the traditional deployment models for Ruby-on-Rails applications.

This application is also covered in LAB 5539 as part of FREE 20-week Ruby-on-Rails course by Sang "with Passion" Shin.

Technorati: web2.0 rubyonrails jruby ruby glassfish redmine

Socialsite @ Enterprise 2.0 Conference - Add social networking to your community

arungupta — Thu, 22 May 2008 06:00:00 +0000

Sun Microsytems is a sponsor of Enterprise 2.0 Conference (Jul 9-12, 2008, Boston).

The conference has regular tutorials, keynotes and general sessions, multiple tracks and pavilion (even a free pavilion pass). They also have Launch Pad that allow companies developing new social networking products to compete for the chance to present them in front of the largest audience in the Enterprise 2.0 community.

There are 8 companies in Round 2 and each one of them has submitted a video highlighting their offering. One of the semi-finalists is Project Socialsite - an offering from Sun Microsystems.

Project SocialSite makes it easy to add social networking features to your existing web applications or community sites (running on Java, PHP or Ruby) and turn it into an OpenSocial container. It comes with a comprehensive and highly scalable implementation of social graph, integrates seamlessly with existing identity and authentication mechanism, make it easy to plug into existing directory server or other user management systems.

The submitted video shows how easy it is add social networking features (such as Profile, Friends and Activity) to MediaWiki by adding simple tags. We hope you like the functionality shown and give us a higher rating to help us qualify for finals :)

Follow the conference blog, Facebook group or participate using conference wiki.

Technorati: conf enterprise2.0 socialsite web2.0

Embeddable GlassFish in Action - Servlet in a Maven project

arungupta — Wed, 21 May 2008 23:45:00 +0000

Kohsuke announced the embedability of GlassFish v3 - this is really cool! Now you can run GlassFish inside an existing JVM, without the need to start it externally. The API javadocs are available here. This blog explains how to host a Servlet using these APIs and write a simple Maven test to invoke the Servlet - all within the same VM.

The blog creates a Maven project using NetBeans but Maven CLI can be used as well.

In the NetBeans IDE, if Maven plugin is not already installed, then install it using "Tools", "Plugins","Available Plugins".

Create a new Maven project

Create a new project in NetBeans IDE and select "Maven" types as shown below

Click on "Next >".
Take the default "Archetype" as shown:

Click on "Next >".
Enter the "Project Name" and "Artifact Id" as shown below:

and click on "Finish". The following output is shown in NetBeans Output window:

This confirms the successful creation of the project.

The command-line equivalent for all the above steps is:

mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=org.glassfish.embedded.samples -DartifactId=webtier

Update pom.xml with repositories & dependencies

Expand "Project Files" and open "pom.xml". Add the following repositories (right after <url>...</url> tags)

<repositories>
    <repository>
      <id>glassfish-repository</id>
      <name>Java.net Repository for Glassfish</name>
      <url>http://download.java.net/maven/glassfish</url>
    </repository>
    <repository>
      <id>download.java.net</id>
      <name>Java.net Maven Repository</name>
      <url>http://download.java.net/maven/2</url>
    </repository>
</repositories>

Add the following fragment after "<repositories>" to set the target JDK as 1.5:

<build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.0.2</version>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
       </configuration>
     </plugin>
   </plugins>
</build>

Add the following dependencies (inside "<dependencies>" and after "</dependency>")

<dependency>
      <groupId>org.glassfish.distributions</groupId>
      <artifactId>web-all</artifactId>
      <version>10.0-build-20080430</version>
    </dependency>
    <dependency>
      <groupId>org.glassfish.embedded</groupId>
      <artifactId>gf-embedded-api</artifactId>
      <version>1.0-alpha-4</version>
    </dependency>

Add Servlet class

Right-click on "Source packages", select "New", "Java Class..." and enter the value as shown below

and click on "Finish".

Replace the template class with the following Servlet

package org.glassfish.embedded.samples.webtier;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/\*\*
\* @author Arun Gupta
\*/
public class SimpleServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest request,
            HttpServletResponse response)
            throws ServletException, IOException {
        PrintWriter out = response.getWriter();
        out.println("Wow, I'm embedded!");
    }
}

This is a simple Servlet class.

Add deployment descriptor (this step could be made optional with possibly a default mapping)

In the "Files" window, expand "src", "main", right-click and select "New", "Folder..." as shown below ...

and give the folder name as "resources" as shown ...

... click on "Finish".
Using the same mechanism, create a new folder "WEB-INF" in "resources". Right-click on "WEB-INF" and select "New", "XML Document..." as shown:
Enter the name as "web" as shown

Click on "Next >", take defaults and click on "Finish". Replace the content of generated "web.xml" with the following ...

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
    <servlet>
        <servlet-name>SimpleServlet</servlet-name>
        <servlet-class>org.glassfish.embedded.samples.webtier.SimpleServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>SimpleServlet</servlet-name>
        <url-pattern>/SimpleServlet</url-pattern>
    </servlet-mapping>
</web-app>

Add a new test to invoke the Servlet

In "Projects", expand "Test Packages" and open "org.glassfish.embedded.samples.webtier.AppTest" as shown:

Add the following fragment at end of the class:

private final String NAME = "AppTest";

    public void testServlet() throws Exception {
        int port = 9999;
        GlassFish glassfish = newGlassFish(port);
        URL url = new URL("http://localhost:" + port + "/" + NAME + "/SimpleServlet");
        BufferedReader br = new BufferedReader(
                new InputStreamReader(
                url.openConnection().getInputStream()));
        assertEquals("Wow, I'm embedded!", br.readLine());
        glassfish.stop();
    }

    private GlassFish newGlassFish(int port) throws Exception {
        GlassFish glassfish = new GlassFish(port);
        ScatteredWar war = new ScatteredWar(NAME,
                new File("src/main/resources"),
                new File("src/main/resources/WEB-INF/web.xml"),
                Collections.singleton(new File("target/classes").toURI().toURL()));
        glassfish.deploy(war);
        System.out.println("Ready ...");
        return glassfish;
    }

Right-click in the editor window and select "Fix Imports" as shown
Take all the defaults as shown

and click on "OK".
The complete project structure looks like:

Run the Test (mvn test)

In Projects window, right-click the project and select "Test" as shown:
The Output window shows the result as:

Notice how GlassFish v3 started in 598 milliseconds (around 0.5 sec) and all the tests passed.

This is a work in progress and we would like to hear your feedback at users@glassfish and GlassFish Forum.

How are you using GlassFish embeddability ?

Technorati: glassfish v3 embedded servlet netbeans

glassfish-webtier

Executing Groovy Programs in-memory

A quick introduction to the Groovy language (part 2)

A quick introduction to the Groovy language (part 1)

DSLs with Groovy JavaOne talk

JSF 2 And HTML5 Server Sent Events

Call for nominations for expert group members for Servlet 3.1 - JSR 340

GlassFish 3.1: using the master password and managing instances

JSF Hudson View Support

Testing JSF

Which should you use?

JSR 330 Style Injection Support For JSF Managed Beans

GlassFish 3.1 m2 supports creating and starting instances on remote hosts.

JSF 2 / HTML 5 Jazoon 2010 Slides Posted

Testing HTML5 Feature Availability In Browsers

JavaOne CFP Opens

HTML5 Semantic Tags

Progressive Enhancement with JSF

IE, Memory Management, and You

Tools

Cyclic Leak

But wait! There's more

Mojarra 2.0.1 has shipped

Context And Dependency Injection (JSR 299) And Servlets

Listing 1: Login Credentials

Listing 2: Login

Listing 3: Login Servlet

Contexts and Dependency Injection (JSR 299) and GlassFish

Listing 1: User Interface Markup

Supporting Classes And Annotations For The Applicaton

Listing 2: The "Random" Annotation

Listing 3: The "MaxNumber" Annotation

Listing 4: The "Generator" Class

The Anatomy of a Simple Contextual Bean

Listing 5: The "Game" Contextual Bean

Latest functionality in GlassFish v3 logging.

Slides from our talk at JavaOne.

ICEFaces 2.0 And JSF 2.0 Together

Proposed Final Draft of Servlet 3.0 now available

Servlet 3.0 PFD draft coming soon.

JSR 245 MR: Part 2 - JSP

Declare Default Content Type

Set Default Buffer Size

Raise Errors for Undeclared Namespaces

Omit Generation of Attribute in <jsp:element>

JSR 245 MR: Part I - Expression Language (EL)

Rebuttal of Greg Wilkin's Blog about Servlet 3.0 PR

Update:

Servlet 3.0 webinar

Asynchronous support in Servlet 3.0

Adding custom handlers to GlassFish v3 loggers

Servlet 3.0 - from the source

Ease of Development (Eod)

Pluggability

Asynchronous processing

Servlet 3.0 (JSR 315) update

jMaki 1.8.1 and GlassFish V3 released

GlassFish V3 logging changes

Ajax Waiter

Enabling performance feature in jMaki

Happy Birthday NetBeans from jMaki

"JSF and Ajax Past, Present and Future" @ AjaxWorld

JavaServer Faces 2.0 Early Draft Review 2 And JavaScript?

Getting server side data into a jMaki widget

Writing jMaki widgets in the real world

irc channel for GlassFish webtier

Job Opportunity in GlassFish Web Container Team

Substruct on GlassFish v3 - Ruby-on-Rails E-Commerce Application

GlassFish and jMaki @ RailsConf Today

JRuby 1.1.2 released - Getting Started with v3 Gem

Redmine on GlassFish - Ruby-on-Rails Project Management Application

Socialsite @ Enterprise 2.0 Conference - Add social networking to your community

Embeddable GlassFish in Action - Servlet in a Maven project