glassfish-webtier

Some of the new Features in Java 8

Mon, 20 Jan 2014 16:58:18 +0000

In my other blogging site, I've been using JDK 8 features to answer some sample interview questions. Here's a quick recap:

To learn the Java 8 API’s, I relied on Cay Horstman‘s just released book, Java SE 8 for the Really Impatient, and I can’t recommend it enough. It’s quite good.

The topics I covered were:

Finding all the Palindromes in English using Streams
Combining Sorted Lists, again using Streams
Getting the largest sum of a sublist, this time using Streams, Futures, Completable Futures, parallel processing, etc.
Getting Bacon Numbers Parts 1, 2, 3, 4 – using Streams, parallel processing, method expressions, Map.merge

See the individual posts for more.

DSLs in Groovy

Sat, 20 Oct 2012 23:51:35 +0000

In my other blogging site, I've covered many of the basics of creating DSLs in Groovy:

What DSLs are, and why you'd use them
A quick introduction to Groovy, part 1 and part 2
Dynamically executing Groovy Programs
Creating binding variables (the nouns of your language)
Creating new methods (the verbs of your language)
Delegating behavior via Method Dispatch and Property Dispatch

Check them out if this looks interesting - I'm about to tackle my first real example - implementing a Turtle Graphics control language.

A Turtle Graphics DSL

Sat, 06 Oct 2012 20:05:53 +0000

In my previous post, I discussed the example program that I wrote to exercise the things I've described so far.

Napili - a Turtle Graphics program with JavaFX and Groovy

Wed, 03 Oct 2012 19:22:34 +0000

My very first programming language was BASIC.

JavaOne on the Cheap

Sat, 29 Sep 2012 19:22:47 +0000

I won't be speaking at JavaOne this year, and didn't get a pass through work.

Regular tickets to JavaOne are

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.

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)

Now, let's add a little change to use an array.

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.

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.

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:

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.

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

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:

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

<html>
    <head>
        <link rel="stylesheet" href="jmaki-2column-footer.css" type="text/css"></link>
        <title>Page Title</title>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <a:page>
    </head>
    <body>
        <div id="border">
            
            <div id="header">
                <div id="banner">Application Name</div>
                
                <div id="subheader">
                    
                    <div>                      
<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'}}
                }
                ]}
                ]
       }" />


                    </div>
                    
                </div> <!-- sub-header -->
            </div> <!-- header -->

            <div id="main">
                <div id="rightColumn" style="height:400px">

<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.' }
    ]"  />


                </div> <!-- end leftColumn -->

                <div id="leftColumn" style="height:400px">
<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'}
  ]
}" />

                </div> <!-- leftColumn -->

            </div> <!-- main -->
            <div id="footer">Footer</div>
        </div> <!-- border -->
        </a:page>
    </body>
</html>

This is a typical jMaki page expect I added 2 new tags. The tag at the beginning tells the jMaki performance code to drop the CSS code and should be in the header. The closing 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.

   <context-param>
        <param-name>jmaki-combinescripts</param-name>
        <param-value>true</param-value>
    </context-param>
    <context-param>
        <param-name>jmaki-combinestyles</param-name>
        <param-value>true</param-value>
    </context-param>

    <servlet>
        <servlet-name>Combined Resource Servlet</servlet-name>
        <servlet-class>jmaki.runtime.CombinedResourceServlet</servlet-class>
        <load-on-startup>2</load-on-startup>
        </servlet>
        
    <servlet-mapping>
        <servlet-name>Combined Resource Servlet</servlet-name>
        <url-pattern>/cr</url-pattern>
    </servlet-mapping>

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.

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

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

            <div id="main">
                <div id="rightColumn" style="height:600px">
                    <div id="rightColumnTop" style="height:180px">
                        <div id="rightColunmTopTable" style="height:180px">

             <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}
                             ]
                          }"/>  
                  </div>
                  <div id="rightColumnTopImages" style="height:180px">
                      Powered by:
                      <div>
                      <img src="images/glassfish-logo.jpg">
                  </div>
                  <div>
                      <img src="images/jmaki-seal.png">
                  </div>
                  </div>
                </div> <!-- end leftColumn -->
                <div id="rightColumnBottom" style="height:415px">
             
             <!--<center>Author Table </center>-->
             
             <a:widget name="dojo.table"
            service="/AuthorServlet" />
                    
                </div> <!-- end leftColumn -->
                                 
                </div> <!-- end leftColumn -->

                <div id="leftColumn" style="height:600px">
                    <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'}}
      }
     ]"/>

        <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 }
        ] }"/>

        <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 }
        ] }"/>
          
                </div> <!-- leftColumn -->

            </div> <!-- main -->

        </div> <!-- border -->
    </body>
</html>

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: <br><br>
  
  
                  <form name="create"  >
  Author Id: <input type="text" id="authorId" name=authorId/> <br>
  Author: <input type="text" id="authorName" name=authorName/><br>
  Organization: <input type="text" id="organization" name=organization/><br>
  <br><br> 
   <input type="hidden"  id="hidden" name="create" value="create">
   <input type="button" onclick="doCreate()" name="submit" value="create">
  </form>

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.

jMaki and GWT : Kissing Cousins

Sat, 22 Dec 2007 03:41:21 +0000

Sun has been providing GWT support with the GWT For Netbeans plugin for some time now. The plugin allows you to very easily create GWT applications that can run on Tomcat and Glassfish. The plugin allows you to easily integrate servlets and other Java EE components in an IDE environment.

With my Ajax dealings over the past few years I have been asked about jMaki and GWT integration. For some time I had thought that GWT was a competing technology but I have come to realize that while jMaki and GWT are truly cousins whose marriage is in this case a good thing.

When integrating jMaki with GWT jMaki provides a well defined model for interacting with JavaScript and GWT provides a model for interacting with Java. jMaki can open up the JavaScript universe to GWT in a well controlled manner.

As a start the jMaki team would like to introduce the GWT community to jMaki Charting. jMaki charting provides dynamic charting capabilities where charts can be manipulated on the client without round trips to the server.

Integrating jMaki charting with GWT has helped us develop a really good integration strategy for GWT and JavaScript for which we created an architecture document. The integration can be summarized by the graphic below.

With the GWT jMaki integration we are exposing the charting functionality including Axes creation and updates, DataSets, and Markers through a set of Java APIs. See the JavaDoc APIs here.
All the resources needed for the component are provided in a single jar file that you simply place in your classpath and include the jmaki.charting.Widgets inherits statement in your gwt.xml file. jMaki charting may be downloaded from the jMaki Charting homepage. It supports both Hosted or Web mode.

We have also created a sample application to show how to use and modify a chart. You can see the application live here.

Charting is just the beginning. We are now working on providing access to the jMaki widgets and would love to have the community get involved. Would you like to join us?

jMaki and the Open Ajax 1.0 Hub

Mon, 01 Oct 2007 22:14:16 +0000

Now that jMaki 1.0 is out we have time to look at integration with our JavaScript functionality like the Open Ajax 1.0 Hub. The integration was done using a simple jMaki extension which takes the events from jMaki and republishes them on the hub. jMaki is also capable of registering libraries as they are being loaded.

To show the integration we have published a version of the application running with Dojo, Yahoo, and jMaki integrated along with the Open Ajax Hubs components on http://jmaki.com/oaa. You can find out more about the details on what we did in the description tab of the example.

How will you use the hub?

jMaki 1.0 is Live

Wed, 26 Sep 2007 00:45:03 +0000

Having experienced continuous development for over 2 years it is time to put a stake in the ground and call jMaki 1.0 ready for general use.

Included in the bundles:

The core jMaki framework.
Sample applications.
Ant task for creating applications and adding widgets and necessary dependencies to those applications.
All the scripts and widget libraries.

We provide bundles for both PHP and Java. The ant task for application creation allows you to create applications rapidly from the command line.

We also provide plugins for both Netbeans 5.x and 6.0 that will create jMaki applications with all the necessary resources in the correct places. Included support is:

The core jMaki Framework.
Templates to start out with.
Drag and drop widgets with templates.
Theming support.

How you experience jMaki is up to you. Find the bundles on the downloads page.

We have also started work on consolidating all the blogs, documents, and form posts on using jMaki into an online book. This is a work in progress and you can find the starting table of contents on our developer site.

I would like to thank everyone on the team and others not listed on the team page for their hard work in putting this release together. I like to encourage would encourage you to join the effort. jMaki is going places and we would love to have you along for the ride.

jMaki 1.0 is fast approaching

Fri, 14 Sep 2007 21:41:17 +0000

After over a year in community development we are preparing to release jMaki 1.0 on September 25.

jMaki has stabilized over the past few months especially with the data models which allow you to create some very sophisticated user interfaces. As proof we have created jmaki.com where we are hosting many of our samples and recent blog postings using jMaki.

How are you using jMaki and if not what are we missing?

Re-Namespacing Dojo

Fri, 10 Aug 2007 23:36:07 +0000

The motivation behind re-namespacing Dojo for jMaki was simple. We want to have both Dojo 0.4.3 and Dojo .9 running in the same web application and we also want to give our users the ability to use jMaki many years in the future. So I undertook the task of re-namespacing Dojo by hand and quickly found out that it was a involved task. Reason being there are 27350 instances of the word Dojo spread across 1013 files in the standard Dojo 0.4.3 Ajax release.To make things easier I have created a configurable ant task that will do the work.

Why ant? We figure it's the easiest to integrate with a build process and it's pretty easy to do string replacements that can be configured.
You can see the RenamespaceTask.java here. You can find a compiled version of the jar file here.

We have provided a simple ant file that will compile the task and run it which you can get here.

Before using this task I strongly recommend you backup your files as this task will overwrite your existing files.

Here are the arguments I give to the task to re-namespace dojo and all of the occurrences in all js, css, and html files. This is the the most thorough and best option as it will re-namespace all dojo files and the dojo styles.

<target name="ns" description="Namespace Dojo Task" depends="jar">
  <taskdef name="renamespace" classname="org.jmaki.ant.ReNamespaceTask"
                 classpath="dist/ns-dojo.jar"/>
  <renamespace 
       ns="gojo"
       tokens="dojo" renameFile="dojo.js" >
    <fileset dir="/Users/gmurray/Desktop/dojo-0.4.3-ajax" />
  </renamespace>
</target>

You simple need to provide a one or more filesets to files containing references to dojo. This simply replaces all the strings. Containing dojo.

You can do more advanced token sets that will not replace the styles and target only the dojo instances like the following.

<target name="ns" description="Namespace Dojo Task" depends="jar">
  <taskdef name="renamespace" classname="org.jmaki.ant.ReNamespaceTask"
                 classpath="dist/ns-dojo.jar"/>
  <renamespace
             ns="gojo"
             tokens="dojo.,{dojo},dojo=,dojo =,dojo:,(dojo,dojo[,/dojo,|dojo,&quot;dojo&quot;"
             renameFile="dojo.js"
             extensions="js,json,html">
    <fileset dir="/Users/gmurray/Desktop/dojo-0.4.3-ajax" />
  </renamespace>
</target>

You may notice the renameFile attribute. This option will rename the dojo.js file to the same name as the namepace.

You need to rename the dojo.js to the same name as the namespace. If you leave the task defaults this will be automatically done. If you do not rename the dojo.js the dojo package loader will not look in the correct place for the dojo resources (I'm not clear why this was done but if the file names are not the same dojo will look up two directories for dojo resources). The re-namespace won't work if you don't rename.

You will also need to re-namespace your code that uses Dojo. You can add multiple filesets so this can be done in one sweep.

When choosing a name to re-namespace to you need a valid JavaScript identifier so you can not include "." or "-" in the name. For jMaki we chose "dj4d3" which is a bit cryptic but it is short and will not conflict with a future version of dojo or another library.

The beauty of re-namespacing is that you can now use two versions of Dojo in the same application and in the same page without conflicts. Both versions will share the same djConfig object which you may chose to also rename.

The ant task was tested with the Dojo .0.4.3 Ajax release. You can test it by simply downloading Dojo from the Dojo downloads page and run it against the release. Then check out the samples and tests.

Once again make sure to backup your work before running task. Let me know what what you think.

jMaki Actions

Sun, 29 Jul 2007 19:01:27 +0000

In Widgets talking to Widgets Carla describes how widgets from different toolkits can easily communicate. There is a more basic level of communication which you can do declaratively which we call jMaki Actions

jMaki Actions are a declarative way of associating widget behavior.

Consider a case where you have a Dojo Fisheye and you simply want it to select a tab or URL when an item is clicked. The Dojo Fisheye is in essence provides the same behavior as a menu. You may notice that the models for the Fisheye Model and the jMaki Menu Model are very similar. A Fisheye widget as a JSP tag would look as follows:

<a:widget name="dojo.fisheye"
             args="{labelEdge:'bottom', orientation:'vertical'}"
             value="[
             { iconSrc:'https://ajax.dev.java.net/images/blog_murray.jpg',
               label : 'Greg Tab',
               action : { topic : '/yahoo/tabbedview/select',
                          message : {targetId : 'tab1'}} },
             { iconSrc:'https://ajax.dev.java.net/images/chinnici.jpg',
               label : 'Roberto Tab',
               action : { topic : '/yahoo/tabbedview/select',
                          message : {targetId : 'tab2'}}
             },
             { iconSrc:'https://ajax.dev.java.net/images/JayashriVisvanathan.jpg',
               href : 'http://jmaki.com',
               label : 'test4'
             }
             ]"/>

With jMaki Actions you can associate an action to be published on a given Fisheye icon. The action property will publish a message that can be picked up by another widget in the page. Let's use a Yahoo Tabbed View which is by default mapped to the topic "/yahoo/tabbedview". The different action you can perform on a tabbedview are described in the Tabbed View Data Model. Here is the portion of the relevant code that is the action that occurs when item labeled 'Greg Tab' is clicked.

action : { topic : '/yahoo/tabbedview/select', message : {targetId : 'tab1'}}

The targetId refers to a tab with the id property used by a given tab. The message property is included as part of the payload of a message published to the topic used. Clicking on the item 'Greg Tab' will end up in the 'Greg Tab' being selected and the same for the 'Roberto Tab'.

<a:widget name="yahoo.tabbedview"
          value="{tabs:[
          {id : 'tab1', label : 'My Tab', content : 'Some Content'},
          {id : 'tab2', label : 'My Tab 2', content : 'Tab 2 Content'}
          ]
          }" />

The end result is using the default template looks as follows:

jMaki models uses general conventions for behaviors and properties you can easily swap widgets. For example you could easily use a Dojo Tabbed View or even swap the FishEye for a menu or tree widget.

jMaki actions are great for general interactions like this and makes it really easy to do basic things like this. More advanced interactions should still be done in glue code as described in Widgets talking to Widgets.

How will you use actions?

jMaki Revolver Widget

Mon, 25 Jun 2007 05:44:07 +0000

A few months ago I created the revolver as a weekend project to provide an alternative way of providing top level navigation on your web size. I thought I would share this with everyone as a jMaki widget.

How to use it with jMaki

In Netbeans

Install the jMaki Netbeans plugin.
Download the jMaki Revolver widget library.
In Netbeans select Tools->Palette->Add jMaki Library from the menu and choose the jmaki-revolver-x.x.zip file you downloaded. A new palette named "jMaki Extras" will appear.
From the jMaki Extras palette drag the widget into the page.
Deploy the application.

In the page you will see the following:

<a:widget name="jmaki.revolver"
            value="[
                   {title : 'Amsterdam',
                              imgSrc : 'http://farm1.static.flickr.com/67/227194339_551e710acb_m.jpg',
                              href : 'http://www.flickr.com/photos/44399047@N00/sets/72157594254916360/'
                              },
                   {title : 'Paris',
                              imgSrc : 'http://farm1.static.flickr.com/129/319228860_23770c66d3_m.jpg',
                              href : 'http://www.flickr.com/photos/44399047@N00/sets/72157594414671044/'
                              },
                   {title : 'Seoul',
                              imgSrc : 'http://farm1.static.flickr.com/106/294268722_662da2ef5a_m.jpg',
                              href : 'http://www.flickr.com/photos/44399047@N00/sets/72157594370026444/'
                              }
                   ]"/>

Use the jMaki customizer (context click->jMaki) to customize the revolver or modify the /resources/jmaki/revolver/component.css.

For Eclipse or Stand Alone Applications

Install the jMaki Eclipse plugin.
Download the jMaki Revolver widget library.
Unzip th jmaki-revolver-x.x.zip file you downloaded and copy the contents of the resources of zip file into the resources directory of your web application..
Add the widget to your page.

<a:widget name="jmaki.revolver"
            value="[
                   {title : 'Amsterdam',
                              imgSrc : 'http://farm1.static.flickr.com/67/227194339_551e710acb_m.jpg',
                              href : 'http://www.flickr.com/photos/44399047@N00/sets/72157594254916360/'
                              },
                   {title : 'Paris',
                              imgSrc : 'http://farm1.static.flickr.com/129/319228860_23770c66d3_m.jpg',
                              href : 'http://www.flickr.com/photos/44399047@N00/sets/72157594414671044/'
                              },
                   {title : 'Seoul',
                              imgSrc : 'http://farm1.static.flickr.com/106/294268722_662da2ef5a_m.jpg',
                              href : 'http://www.flickr.com/photos/44399047@N00/sets/72157594370026444/'
                              }
                   ]"/>

Find out more about the customizable properties that may be passed in as the args attribute from the docs/index.html file inside the jMaki Revolver widget library.

Non jMaki Usage

You will need to provide the template text, CSS, and JavaScript.

Download the jMaki Revolver widget library.
Unzip th jmaki-revolver-x.x.zip file you downloaded and copy the contents of the jmaki/revolver directory to your web application.

Add links to the script and css.

<script type="text/javascript" src="component.js"></script>
<link rel="stylesheet" type="text/css" href="component.css"></link>

Add the template where you want the revolver to appear.

<!-- Revolver Template --!>
<div id="jmaki-revolver" class="revolver" >
 <div id="jmaki-revolver-content-pane" class="revolverContent"></div>
</div>
<div id="jmaki-revolver-title-pane" class="revolverTitle"></div>>

Add the JavaScript initialization code.
<script> window.onload = function() { var wargs = {uuid : 'jmaki-revolver'}; wargs.value = [ {title : 'Amsterdam', imgSrc : 'http://farm1.static.flickr.com/67/227194339_551e710acb_m.jpg', href : 'http://www.flickr.com/photos/44399047@N00/sets/72157594254916360/' }, {title : 'Paris', imgSrc : 'http://farm1.static.flickr.com/129/319228860_23770c66d3_m.jpg', href : 'http://www.flickr.com/photos/44399047@N00/sets/72157594414671044/' }, {title : 'Seoul', imgSrc : 'http://farm1.static.flickr.com/106/294268722_662da2ef5a_m.jpg', href : 'http://www.flickr.com/photos/44399047@N00/sets/72157594370026444/' } ]; var revolver = new jmaki.widgets.jmaki.revolver.Widget(wargs); } </script>

Find out more about the customizable properties from the docs/index.html file inside the jMaki Revolver widget library.

This example shows the benefits of using a framework like jMaki to reduce the need of the steps you see with the non-jMaki usage.

Enjoy the widget. If you have any requests, comments or issues, please feel free to ask them here.

jMaki Extension for Google Gears

Mon, 11 Jun 2007 23:33:20 +0000

With little effort I was able to get up and running with Google Gears very easily and integrate it with other jMaki components as an extension. Here is what I did to use the local Google database.

Using the latest jMaki .9.3 I added the following to my config.json file:

{
  'config': {
    'version': '.9',
    'glue' : {
         'includes': ['/glue.js', '/resources/system-glue.js']
       },
    'extensions': [{url : '/*', 'name' : 'google.gears'}]
    }
}

The extension is loaded for all urls and is named google.gears.
Now for the extension that will interact with Google Gears. No other JavaScript code is needed.

jmaki.namespace("jmaki.extensions.google.gears");

jmaki.extensions.google.gears.Extension = function(args) {

  var self = this;
  var topic = "/google/gears";
  var db = null;
  var factory = null;
  
  this.postLoad = function() {
     self.init();
     jmaki.subscribe(topic + "/execute", self.execute);
  }

  this.init = function() {
      jmaki.log("Google Gears jMaki Extension intialized");

      // Firefox
      if (typeof GearsFactory != 'undefined') {
          factory = new GearsFactory();
      } else {
          // IE
          try {
              factory = new ActiveXObject('Gears.Factory');
          } catch (e) {
              // Safari
              if (navigator.mimeTypes["application/x-googlegears"]) {
                  factory = document.createElement("object");
                  factory.style.display = "none";
                  factory.width = 0;
                  factory.height = 0;
                  factory.type = "application/x-googlegears";
                  document.documentElement.appendChild(factory);
              }
          }
      }
      // Now set up the objects, being careful not to overwrite anything.
      if (!window.google) {
          window.google = {};
      }
      
      if (!google.gears) {
          google.gears = {factory: factory};
      }      
  }
  
  // Open this page's local database.
  function initDB() {
      if (!window.google || !google.gears) {
          jmaki.log("Google Gears not found.");
          return;
      }
      
      try {
          db = google.gears.factory.create('beta.database', '1.0');
      } catch (ex) {
          jmaki.log('Could not create database: ' + ex.message);
      }
      
      if (db) {
          db.open('beta-database');
          db.execute('create table if not exists jmaki' +
          ' (obj varchar(2048), Timestamp int)');  
      }
  }
  
  this.execute = function(args) {
    this.query = args.query;
    var _callback = args.callback;
    this.qargs = args.args;
    if (!db) initDB();
    if (!db) {
      jmaki.log("Google Gears Extension: Unable to find database");
      return;
    }
   var rs =  db.execute(query, qargs);
    // execture callback if it's there
    if (typeof _callback != 'undefined') _callback.call(this,rs);
  }

}

This file will need to be in a file named extension.js in the /resources/google/gears directory of your web application. Now that the extension has been enabled all you need is to publish to the topic /google/gears/execute with the data base calls you want to make from your glue code. Here is an example of mapping the save button for the Dojo Editor and Dojo Inline Edit components which publish to the topic "*onSave".

jmaki.subscribe("*onSave", function(args) {
    // empty the table then save it
    jmaki.publish("/google/gears/execute",
    { query : 'delete from jmaki',
     callback : function() {
       jmaki.log("Removing Previous Values");
       jmaki.publish("/google/gears/execute",
          { query : 'insert into jmaki values (?, ?)',
             args : [args.value, new Date()],
         callback : function() {
             jmaki.log("Saved " + args.value);
         }
        });
       }
    });
});

I used callbacks much like the XMLHttpRequest object to keep the design simple and make it easy to associate post processing code with a given event.

To display the data you need to load data from Google Gears as well. Here is the glue listener to load some text from the Google Gears data base and assign it to a JavaScript variable.

jmaki.subscribe("/jmaki/runtime/extensionsLoaded", function() {

  jmaki.publish("/google/gears/execute", 
    { query : 'select * from jmaki order by Timestamp desc',
     callback : function(_rs) {
         if (typeof _rs != "undefined" &&
             typeof _rs.isValidRow != "undefined" &&
             _rs.isValidRow()) {
             // set data on the global window object for later access
             if (typeof _rs.field != "undefined") window.editorData = _rs.field(0);
             else window.editorData = "";
             jmaki.log("Loaded Editor Data: " + editorData);
         } else {
             window.editorData = "";
             jmaki.log("No data available");
         }
         jmaki.log('done');
     }
    });
});

This code is executed after the extensions has loaded and will do a database using a sql statement. The returned value is assigned to the global variable window.editorData which you can then assign to your widget. For a Editor you can assign a JavaScript variable as the value using a client side value binding which starts with an '@{' and contains the package and variable name and ends with an '}'. For this window.editorData the client side value binding is @{window.editorData}. With a JSP / JSF widget the tag in a JSP page would look like the following:

As we can see it's pretty easy to integrate Google Gears in your jMaki application. There are many other areas to explore including easier JSON serialization using gears. This is starting to like JDO all over again but in this case "J" is for JavaScript. Rest assured we will try to make this easier in jMaki.

What would you like to do with Google Gears?

jMaki Extensions

Thu, 07 Jun 2007 22:37:53 +0000

Just when we thought it was safe to call jMaki feature complete we got a lot of feedback for various features that could all be handled by a single extension feature.

What are extensions in jMaki?

Extensions are behavior / functionality that are shared across widgets. Extensions are loaded after the jmaki.js and before glue (your application logic). Examples may include enhanced debugging support, sound, or controllers that are specific to an individual application.

What does an extension look like?

jmaki.namespace("jmaki.extensions.jmaki.ext.bar");

jmaki.extensions.jmaki.ext.bar.Extension = function(args) {
  jmaki.debug = true;
  jmaki.log("jMaki bar Extension intialized");
  jmaki.log("jMaki bar : extensionDir=" + args.extensionDir);
 }

Extensions are namespaced JavaScript objects that are mapped in the config.json file like the following:

{
  'config': {
    'version': '.9.3',
    'extensions' : [
          'jmaki.ext.foo' 
         ]
    }    
}

Extensions are like widgets in that the application will look under /resources/jmaki/ext/bar for a file called extension.js. The contents are like the file above. The extensions will be located in the resources directory and located using the extension name. The extension 'jmaki.ext.foo' would be located in the following directory:

resources
    |
    +jmaki
       |
       +ext
          |
          +foo
             |
             +extension.js

Extensions can also be loaded on a per URL basis or based on a wildcard like you may see in the code below:

{
  'config': {
    'version': '.9.3',
    'extensions' : [
          { url : '/basicArgs.jsp',  name : 'jmaki.ext.foo' },
          { url : '*.jsp', name : 'jmaki.ext.bar'},
          { url : '/relativedir/*', name : 'jmaki.ext.foo', args : { 'topic' : 'footopic'}}
         ]
    }    
}

Notice the url property can be a URL or contain a '*'. The mappings can also provide an args property containing default data that is accessible in the extension (extension.js).

We also plan on adding a page level tag and or function for adding functions in the next release. It is our hope to keep the core of jMaki small and nimble. At the same time we want to future proof jMaki.Extensions are available in the PHP, Phobos, and Java versions of jMaki and may be found at the jMaki Downloads page.

Here are some extensions we are thinking about:

Back/Forward button tracking
Sound
Bookmarking
Google Gears Integration
Cross Widget Drag and Drop
JavaScript controllers

What kind of extensions would you like to see for jMaki?