Jeff's Blog

Apache Wicket Interfaces & Methods To Master – An Introduction

2011-08-14T10:58:00.000-04:00

The Apache Wicket Web framework is the best thing that’s ever happened to Java based Web development. That’s a bold statement and obviously my opinion but there appears to be a growing consensus in that area as more Java developers are exposed to this fabulous framework (I’ll address my concern of what I perceive as a very poor attempt to promote Wicket in a later blurb or two or future article).

One of the joys of working with Wicket is, of course, that developing with Wicket means developing with Java, HTML, CSS and Javascript. By some, though, this is seen as one of Wicket’s greatest weaknesses and those who shun this pure or clean approach the loudest tend to be those who prefer to work with visual, development-time components that are common to various other frameworks such as JSF. Their argument, however, tends to fall upon deaf ears by those of us who have ever worked on either a corporate or commercial Web project of even medium size and complexity.

Perhaps the biggest single hurdle that budding Wicket developers face is mastering the various Java interfaces, classes and methods that are required to pull everything together in a Wicket application. Most Web applications have to deal with memory, sessions, security (restricting access to resources to authenticated and authorized users), file (resource) contribution, AJAX behaviors and request handlers, code reuse, etc. These are very common concerns every Web developer addresses yet the implementation of some of these concerns aren't well documented or have little if no example code to demonstrate how to address them using Wicket.

As a result, a Wicket ‘newbie’ is typically left dumbfounded when first contemplating addressing these concerns for the first time in their own Wicket applications. This is unfortunate and unnecessary because all these issues are addressed by Wicket’s numerous interfaces and mentods that it exposes. The problem is that numerous important interfaces and methods are either not well documented or they lack valuable example code which would serve to provide a context for their use.

In the articles to come I will attempt to unravel, explore and promote the use of some of these interfaces and methods and provide numerous examples of their use. To begin I’ll start with the various ways that a Wicket developer can employ Javascript and Ajax on their pages. I'll discuss the basics such as how a component can contribute Javascript to a page, how to handle callbacks to the component listeners and how to render Javascript that is called by Wicket's Ajax library before and after it calls the Ajax request's component listener.

I’ll be using NetbBeans 7 throughout the articles to develop the code because in my opinion no other IDE provides the level of support for Wicket development that NetBeans and its Wicket plugin does. If you haven’t already, download and install NetBeans 7 and then install the latest release of the Wicket plugin; both can be found by visiting http://netbeans.org/. If you would like to learn about the numerous productivity enhancing features provided by the latest release of the Wicket plugin and how to install it please read my article at http://jeff-schwartz.blogspot.com/2011/04/netbeans-7-wicket-plugin.html.

UPDATED 8/14/2011
This and all future related articles on Wicket will now appear at my new blog site The Wicket Evangelist.

Bugs In NetBeans 7.0 GlassFish 3.1 Integration

2011-05-07T08:23:00.001-04:00

I’m running the EE version of NetBeans 7 on Windows Vista (32 bit) and frequently I get the following notification error when deploying to GlassFish 3.1:

Seems there is some conflict with the native file system but not having researched the error I could be totally wrong. The worst thing about this is that it causes deployments to GlassFish 3.1 to fail and I often have to restart the server to continue testing. Sort of puts a crimp in the edit & refresh cycle that I’ve come to expect.

I’ve also experienced another bug which occurs upon opening NetBeans 7 with a project using GlassFish 3.1. NetBeans will prompt me, alerting me that the application’s server configuration is wrong. When I then go to Tools | Servers GlassFish 3.1 isn’t listed and I have to add it again to the list of registered servers, though because it is already installed on my development machine I don’t have to reinstall it. This seems to temporarily correct the problem until the next time I open NetBeans 7 with a GlassFish 3.1 project.

Hopefully, these bugs will be quickly addressed in a point release.

The NetBeans 7 Wicket Plugin

2011-04-28T22:22:00.001-04:00

Geertjan Wielenga has released an updated version of the Wicket Plugin for NetBeans 7. For us Wicket fanatics this is indeed great news. The plugin adds some really nice enhancements and productivity features to the NetBeans platform and, when taken in total, in my opinion makes NetBeans the undisputed best platform for Wicket development.

If you haven’t done so already I urge you to download this plugin from the NetBeans plugin portal and install it into NetBeans 7. For those of you not familiar with installing plugins from the NetBeans portal, here are the steps you should follow:

Installing The Wicket Plugin

1. Go to http://plugins.netbeans.org/plugin/3586/wicket-1-4-support and click the Download button to download the zip file to your computer. Once it is downloaded extract all the files. On Windows you can extract the files by right clicking the file with your mouse and selecting Extract All.

2. Start up NetBeans if it isn’t already and select Tools | Plugins from the main menu. This will open the Plugin window.

3. Select the Downloaded tab and then select the Add Plugins button.

4. Navigate to the folder where you the extracted files reside, select all 3 files and then select the Open button.

5. Select the Install button and NetBeans will install the plugin modules after which you will be prompted to restart NetBeans. Please, restart NetBeans.

Create A Wicket Project

Lets explore some of the productivity enhancing features that the Wicket plugin provides. We’ll start first by creating a new Wicket project.

1. From the main menu select File | New Project. Then, select Java Web from the Categories panel and select Web Application from the Projects panel and then select Next.

2. Enter any name you like for the Project Name and select Next.

3. Select Apache Tomcat 7.0.11 for the Server (if you prefer, you can also select GlassFish 3.1) and Java EE 6 Web for the Java EE Version and select Next.

4. In the Frameworks step you can see that there is an option to select Wicket as the framework you want to use in your application. This is the 1st and most obvious contribution that the Wicket plugin provides, easy integration of Wicket into a NetBeans Java Web project. When you select Wicket the Plugin provides you with numerous configuration options such as the name of the Wicket filter and the URL pattern, for instance. For our run through we are going to accept all the defaults.

5. Select Wicket and then select Finish. NetBeans will now generate a starter Wicket application.

Fully expand the newly created project in the Projects panel.

As you can see from the above, the Wicket plugin created a complete Wicket starter project, libraries and all. It also created numerous Wicket components: BasePage, FooterPanel, HeaderPanel and HomePage as well as the required Application.java class. The plugin also configured web.xml according to the configuration parameters that we chose in the Frameworks step.

Run The New Wicket Application

Now, from the main menu select Run | Run Main Project to run the newly created application. As you can see from the rendered page in the browser, the starter project, though trivial, is rather nice - it has a header section, a middle section for content and a footer section, too.

You will, of course, want to modify the starter project to match your own application’s requirement but because the starter project uses Wicket Markup Inheritance you will be able to do this rather easily.

The Starter Project

Lets explore the components that the plugin generated for us.

Open the BasePage component by double clicking on either BasePage.html or BasePage.java. When you click on either, both files will open. This behavior is contributed by the Wicket plugin and I find it extremely convenient.

Now, lets look at BasePage’s markup and java implementation.

<!DOCTYPE html> 
<html xmlns:wicket="http://wicket.apache.org"> 
    <head> 
        <meta charset="UTF-8"> 
        <meta name="description" content="Put your description here!" /> 
    <wicket:head> 
        <wicket:link> 
            <link rel="stylesheet" type="text/css" href="style.css"/> 
        </wicket:link> 
    </wicket:head> 
</head> 
<body> 
    <header wicket:id="headerpanel" />
    <section class="content_container"> 
        <wicket:child/> 
    </section> 
    <footer wicket:id="footerpanel" /> 
</body> 
</html>

package com.myapp.wicket;           

import org.apache.wicket.markup.html.WebPage;

/** 
 *
 * @author Jeff
 * @version 
 */

public abstract class BasePage extends WebPage {

    public BasePage() { 
        super(); 
        add(new HeaderPanel("headerpanel", "Welcome To Wicket")); 
        add(new FooterPanel("footerpanel", "Powered by Wicket and the NetBeans Wicket Plugin"));
    } 

}

BasePage.html’s header contributes style.css, which is a packaged resource that resides in the same package as the BasePage component. By using wicket:head and wicket:link tags, Wicket will be able to resolve the reference to style.css and include it in the rendered page.

In the body of the page there are place holders for the header and footer panels. There’s also a wicket:child tag declared which will allow any page that inherits from BasePage to contribute its content to the page. This is what Wicket calls ‘Markup Inheritance’. I’ll show you how this is used when we look at the HomePage component later in the article.

BasePage.java’s implementation is what you would expect to find considering the markup we just explored. BasePage derives from WebPage and after calling into its super class BasePage’s contrcutor adds the HeaderPanel and FooterPanel components to the page. The constructors for both of these components allows you to add the text that will be displayed for each as their second parameters.

Now, lets look at HomePage’s markup and java implementation.

<!DOCTYPE html> 
<html xmlns:wicket="http://wicket.apache.org"> 
    <head> 
        <meta charset="UTF-8"> 
    <wicket:head> 
        <title>Wicket Example</title> 
    </wicket:head> 
</head> 
<body> 
    <wicket:extend> 
       <h1 wicket:id="message">This gets replaced</h1>
    </wicket:extend> 
</body> 
</html>

package com.myapp.wicket;           

import org.apache.wicket.markup.html.basic.Label;

public class HomePage extends BasePage {

    public HomePage() {
        add(new Label("message", "Hello, World!"));
    }

}

Again, there are no surprises here but one item needs to be elaborated on. HomePage derives from BasePage and as I had mentioned, HomePage uses Markup Inheritance to contribute its markup to the page. It will attach its markup to the h1 tag which is sandwiched between the opening and closing wicket:extend tags. This is how Wicket Markup Inheritance works and it is a very powerful technique to use when you want to compose pages that have the same layout and appearance.

I’ll let you explore HeaderPanel and FooterPanel on your own though these also will be what you would expect as both implementations are derived from Panel.

Now lets explore some of the other productivity enhancements that the Wicket plugin provides.

Creating A New Page And A New Panel

To create a new Page, right click the package which currently contains our project’s components and select New | Wicket Page. Enter any name for the Page and select Finish. Two files, one html and one Java, will open in the browser.

Creating a new Panel is much like creating a new Page. Right click the package which currently contains our project’s components and select New | Wicket Panel. Enter any name for the Panel and select Finish. Two files, one html and one Java, will open in the browser.

Exploring Components With Navigator

The plugin adds what I call ‘Wicket Sense’ (my term for a lack of a better one) to the NetBeans Navigator. To see this in action, in the editor select the BasePage.html file and if it isn’t already, open the Navigator and select Wicket Tags from its list of views.

As you can see, the Navigator displays all the elements that include wicket:id attributes in their tags. Now switch editor views to BasePage.java and again, notice how the Navigator has identified all the Wicket components in the Java code.

Your will really appreciate Navigator’s Wicket Sense when you are dealing with large Java and markup files.

Jump To Implementation

Another nice feature that the plugin adds is the ability to jump to the Java implementation from within the markup file. In HomePage.html, hold down the control key and hover the mouse over the ‘message’ wicket:id value. An underline will appear and if you now click on ‘message’ the editor will switch views to the Java implementation, opening the file if it isn’t currently open in the editor.

The plugin doesn’t currently support jumping to the markup page from the implementation file but maybe a future release of the plugin will provide this feature.

Much Thanks And Appreciation

Geertjan deserves our thanks and he earns our appreciation for all the effort he has put into this plugin. In my opinion, the plugin empowers NetBeans to provide a level of support for Wicket development that no other IDE can currently match.

Geertjan, great job and thank you!

Well, that’s it for now but remember, busy hands are happy hands, so get going and explore this fabulous plugin and all its great features. Happy coding!

Wicket, Web Services, NetBeans And GlassFish

2011-04-28T12:02:00.001-04:00

A reader recently emailed me and wanted to know about implementing a Wicket application within a Web Service environment.

“I have not come across any reference where Wicket has been implemented
within a web service environment. None of the books I have read on
Wicket have addressed this area to my knowledge. I am wondering if you
have any insight as to how this would work.”

The reader is expressing a very common misconception that a lot of developers have and that misconception is that you somehow have to integrate your Web Services into your Web application. Part of my response to the reader was:

“How you expose your web services has nothing to do with Wicket meaning you don't integrate your web services with wicket.”

Additionally, I went on to say:

“All you need is to create web services on glassfish (it has built in support for web services and Netbeans tooling makes this just so simple). If a client, whether your Wicket application or a paid subscriber for instance, needs to consume your web services it will consume the wsdl files produced when you created the web services.”

What I was trying to express to the reader is that Wicket is just a Web framework and not a Web Services provider. Wicket writes HTML to the browser and that’s about it. Wicket Web applications, however, can consume Web services, either those on the same server the Web application is running on or located on different servers. But Wicket itself doesn’t provide any means to consuming Web services - for that you use Java API for XML Web Services (JAX-WS).

I promised the reader that if I had the time I would write an article demonstrating how this is done which is the purpose of this article. So lets get started.

The remainder of this article assumes you have installed NetBeans 7 as well as the NetBeans Wicket plugin. If you haven’t, please do so now.

NetBeans, GlassFish v3.1 and JAX-WS

NetBeans 7 comes bundled with GlassFish v3.1 and GlassFish comes with Metro 2.1 as its SOAP Web Services provider. Metro 2.1 implements the JAX-WS specification. The synergy between Web Services, NetBeans and GlassFish is provided by the tooling built into NetBeans, which makes authoring and deploying your Web Services on GlassFish very easy, as we shall see later in this article.

When you create a Web Service you first have to decide how you want to package it (what type of application you will use to host your Web Service). You have 2 options:

1. JavaEE EJB Module project – this option should be used if your Web Services require access to EE containers. Web Services in this context are generated as Stateless SessionBeans. If your Web Service needs access to your database, for instance, you can achieve this using the @PersistenceContext annotation within your Web Service which will allow you to access your database via JPA.

2. Package in Web container – this option should be used if your Web Service doesn’t require access to other EE containers.

In this article I won’t actually cover accessing a database because I want to keep it simple but I will use a JavaEE EJB Module project and you can, if you chose, explore this later on your own by creating a Web Service method to access your own database.

Create A Web Service Project

1. If you haven’t already, fire up NetBeans and select File | New Project which will open the New Project window.

2. Select Java EE from the Categories panel and select EJB Module from the Projects panel and select Next.

3. Enter any valid project name you like in the Project Name text box. I am naming mine ‘EJBWebServicesAndWicketTutorial’. Select Next.

4. Select GlassFish Server 3.1 from the Server drop down list and make sure that Java EE 6 is selected in the Java EE Version drop down list. Select Finish to generate the project.

Create A Web Service

1. Right click the project node for the EJB project in the Projects window and select New | Web Service. This will open the New Web Service window.

2. Enter CalculatorWebService for the Web Service Name. Make sure that the Create Web Service from Scratch option is selected. Note that because our project is an EJB the Implement Web Service as Stateless Session Bean option is automatically selected for us and cannot be changed. Enter WebServices as the Package name and select Finish. NetBeans will generate your Web Service Java class in the WebServices package.

3. I will use a simple method for our Web Service that returns the sum of two integers. Replace the content of CalculatorWebService.java with the following:

package WebServices;

import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.ejb.Stateless;

/**
 *
 * @author Jeff
 */
@WebService(serviceName = "CalculatorWebService")
@Stateless()
public class CalculatorWebService {

    /**
     * Web service operation
     * @param i int
     * @param j int
     * @return  the sum of i + j as int
     */
    @WebMethod(operationName = "add")
    public int add(@WebParam(name = "i") final int i, 
    @WebParam(name = "j") final int j) {
        return i + j;
    }
}

From the above code you can see that the CalculatorWebService class is decorated with both @WebService and @Stateless attributes which is what you would expect. Also note that the add method is decorated with the @WebMethod attribute and that each of its parameters, i and j, are decorated with the @WebParam attribute.

I didn’t hand-code this though I could have. NetBeans can generate a Web method with all the correct attributes for you. If you select Design View and click the Add Operation button, NetBeans will present you with its Add Operation window that allows you to add a new Web Service method with all the proper attributes. I’ll leave this as an exercise that you can explore later on your own.

Testing The CalculatorWebService add Method

NetBeans tooling makes testing Web Services a snap so lets do that now to insure that our add service works as expected:

1. In the Project panel right click the Web Services node (not the WebServices package) and select Test Web Service which will open your browser and display the following

2. Click the WSDL File link and save the URL somewhere (like Windows NotePad, for instance) and then page back to the above. We will use the URL in our Web Services client application, which we will build later on in the article.

3. Enter 4 in the first input field and enter 5 in the second input field and then click add. Your browser will then display the following

As you can see from the above, the method correctly calculated and returned the sum of our two numbers. If you scroll down the browser page you can see the packaging for both the SOAP request and the SOAP response. Repeat this a few time with different sets of numbers.

We now have a working Web Service that can be consumed by any client that can consume a Web Service. Note how the Web Service we just built has no connection at all with Wicket – our project doesn’t even include the Wicket framework. Remember, Web Services provide a service whereas Wicket applications render HTML to the browser.

Now we know that our method works so lets create a Wicket application that will consume the Web Service. I’ll keep this simple and I assume that you have already installed the latest release of the Wicket plugin for NetBeans 7.

Create a Wicket Application

1. In NetBeans select File | New Project and select Java Web from the Categories panel and Web Application from the Projects panel. Enter any name you like for the Project Name, select Set As Main Project and select Next.

2. For Server select GlassFish Server 3.1 and for Java EE Version select Java EE 6 Web and select Next.

3. For Frameworks select Wicket and select Finish. NetBeans along with the Wicket plugin will generate a Wicket starter application project that includes the Wicket libraries. Also generated by the Wicket plugin are Wicket components for HomePage, BasePage, HeaderPanel, FooterPanel as well as the required Application.java and configuration files.

Now that we have a Wicket application we will use NetBeans to easily configure it to consume the Web Service we created previously.

Consuming Our Web Service

1. In the Projects panel right click the Web applications project node and select New | Web Service Client. This will open the New Web Service Client window.

2. Select WSDL URL and enter the URL that you saved previously when you tested the Web Service.

3. Enter a package name and make sure that JAX-WS Style is the selected option for Client Style. Select Finish. NetBeans will generate a Web Service Reference for us in the Web Service References folder.

Our Web application is now configured to consume the Web Service we previously created. Notice that in the above we configured our Web application using the URL that points to the Web Service’s WSDL. We could have used a project reference instead but I used the URL to emphasize that you can consume any Web Service running on any server, yours or some other, as long as you have access to its WSDL URL.

Now lets actually use the Web Service in our Wicket application.

1. In the Projects panel double click on the HomePage.html file. Notice how NetBeans opens it as well as the HomePage.java file. This behavior, among others such as generating a starter project, is a contribution of the NetBeans Wicket plugin.

2. Replace all the content in HomePage.html with the following:

<!DOCTYPE html> 
<html xmlns:wicket="http://wicket.apache.org"> 
    <head> 
        <meta charset="UTF-8"> 
    <wicket:head> 
        <title>Wicket Example</title> 
    </wicket:head> 
</head> 
<body> 
    <wicket:extend> 
       <h1 wicket:id="message">This gets replaced</h1>
       <form wicket:id="form" >
           <div wicket:id="feedbackpanel" />
           <input type="text" wicket:id="input1" /> + <input type="text" wicket:id="input2" /> = <span wicket:id="result" /><br/>
           <input type="submit" />
       </form>
    </wicket:extend> 
</body> 
</html>

From the above you can see that our markup is quite simple - we create a simple form with two text fields and a submit button.

Now, lets consume the add Web Service method.

1. Select the HomePage.java file and from the Projects panel and fully expand the Web Service References folder. Drag and drop the add method anywhere into the HomePage.java file and NetBeans will generate the call to our Web Service method for us. Rather than implement the rest of the code yourself you can replace the code in HomePage.java with the following

/*
 * HomePage.java
 *
 * Created on April 28, 2011, 6:30 AM
 */

package com.myapp.wicket;           

import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
import org.apache.wicket.model.CompoundPropertyModel;

public class HomePage extends BasePage {
    
    private int input1 = 0;
    private int input2 = 0;
    private int result = 0;

    public int getInput1() {
        return input1;
    }

    public void setInput1(int input1) {
        this.input1 = input1;
    }

    public int getInput2() {
        return input2;
    }

    public void setInput2(int input2) {
        this.input2 = input2;
    }

    public int getResult() {
        return result;
    }

    public void setResult(int result) {
        this.result = result;
    }
    
    public HomePage() {
        add(new Label("message", "Enter 2 ints!"));

        Form<HomePage> form = new Form<HomePage>("form", new CompoundPropertyModel<HomePage>(HomePage.this)){

            @Override
            protected void onSubmit() {
                super.onSubmit();
                // Call the add web service method to calculate the result
                result = add(input1, input2);
            }
            
        };
        
        form.add(new FeedbackPanel("feedbackpanel"));
        form.add(new TextField<String>("input1"));
        form.add(new TextField<String>("input2"));
        form.add(new Label("result"));
        add(form);
    }

    private static int add(int i, int j) {
        webservices.CalculatorWebService_Service service = new webservices.CalculatorWebService_Service();
        webservices.CalculatorWebService port = service.getCalculatorWebServicePort();
        return port.add(i, j);
    }

}

In our java implementation we add the two text fields to the form and the the form to the page. We override the form’s onSubmit method in which we call our Web Service method and assign its return value to result. When Wicket renders the page the page will display the result. Lets try it. Run the Web application and you should see the following

Enter a valid numeric/integer value for both input fields and select Submit. The page will render with the result.

Here is the result I get when I enter 10 and 14. The result, 24, is rendered back to the page. If you enter a non numeric value you will get an error message.

What We’ve Learned

As the examples here have demonstrated, an application that publishes Web Services is totally disconnected from any application that consumes its services. In our case, the consumer is a Wicket application. Wicket renders HTML and in our case it renders the result of calling our Web Service.

Our Web Service implementation knows nothing about any client application that may use its services. The client application consumes the Web Service via the WSDL.

In addition, NetBeans and its GlassFish tooling really makes both publishing and consuming Web Services ridiculously easy and the NetBeans Wicket plugin, with its ability to create a starter project as well as Wicket Pages and Panels is a great productivity booster.

I hope you have enjoyed this little walk-through of publishing and consuming Web Services with NetBeans, GlassFish, Wicket and the NetBeans Wicket plugin. Please feel free to leave a comment or a question.

Proposed Changes To The Netbeans Wicket Plugin’s Generated Starter Project

2011-04-22T16:49:00.001-04:00

Currently, BasePage adds its markup to HomePage’s markup which is a subclass & that isn't a good practice. Just 1 file needs to be added, BasePage.html & it should include markup for the header panel. Then BasePage.java should be modified to add the header panel component to that.

I recommend that BasePage.html be implemented as follows:

<!DOCTYPE html>
<html xmlns:wicket="http://wicket.apache.org">
    <head>
        <meta charset="UTF-8">
        <meta name="description" content="Put your description here!" />
    <wicket:head>
        <wicket:link>
            <link rel="stylesheet" type="text/css" href="style.css"/>
        </wicket:link>
    </wicket:head>
</head>
<body>
<section class="container" wicket:id="headerpanel">
</section>
<section class="content_container">
    <wicket:child/>
</section>
<footer>
    <span>Put your footer here</span>
</footer>
</body>
</html>

and that BasePage.java be implemented as:

import org.apache.wicket.markup.html.WebPage;

public abstract class BasePage extends WebPage {

    public BasePage() {
        super();
        add(new HeaderPanel("headerpanel"));
    }

}

and that HomePage.html be implemented as:

<!DOCTYPE html>
<html xmlns:wicket="http://wicket.apache.org">
    <head>
        <meta charset="UTF-8">
    <wicket:head>
        <title>Title goes here!</title>
    </wicket:head>
</head>
<body>
<wicket:extend>
    
</wicket:extend>
</body>
</html>

and that HomePage.java be implemented as:

package com.buzzwords.wicket;

import org.apache.wicket.markup.html.link.Link;

public class HomePage extends BasePage {

public HomePage() {

}
}

Now BasePage remains blissfully ignorant of HomePage and its markup hierarchy.

My example is using the new html5 doctype and character encoding specifications as well as some html5 tag candy.

Java EE6 & Wicket - Article #6 – A Wrap Up

2011-03-31T12:10:00.001-04:00

Welcome to the 6th in a series of detailed articles on Java EE6 & Wicket. If you haven’t already, please read the following previous articles before continuing.

In this, the 6th and final article in this series, we will examine the code, focusing on the integration we provided for consuming the EJB in our HomePage. I will also discuss some best practices that I’ve used here, especially pertaining to Wicket components and project structure.

Consuming EJB In Wicket

In article #3 we added the JavaEE Inject jars to the GuestBook project. JavaEE Inject is a Wicket module that provides integration through Java EE 6 resource injection and supports three annotations:

@EJB
@PersistenceUnit
@Resource

With JavaEE Inject any Wicket application running in a Java EE6 container can consume the above 3 types of JavaEE resources. Before an application can use them, however, its WebApplication class method init must be overridden to add the JavaEEComponentInjector into Wicket’s request cycle. The code is simple as shown below:

@Override
    protected void init() {
        super.init();
        addComponentInstantiationListener(new JavaEEComponentInjector(this));
    }

What we are doing in the above code is calling Wicket’s Application class method addComponentInstantiationListener with a reference to a JavaEEComponentInjecter object which the JavaEE Inject module provides. addComponentInstantiationListener adds the JavaEEComponentInjector object to its lists of component instantiation listeners that it maintains.

With the JavaEEComponentInjector now maintained whenever a Wicket component is instantiated, JavaEEComponentInjector will scan the component for one of the above three annotations and injects their associated resources into the component.

There is one limitation, though, imposed by JavaEE Inject and that is it can only inject resources into a component that is a subclass of WicketPage. This has implications on the modularity of our code in that we can’t directly reference EJB methods, for instance, directly in classes that aren’t derived from WebPage. Or can we? Well, we can and I will show you how we did it in GuestBook.

Techniques For Using JavaEE Inject Resources Outside Of WebPages

GuestBook uses an instance of a DataView to display the list of names of its visitors. A DataView requires a pseudo model of type IDataProvider<T> dataProvider to provide the data that it displays and GuestDataProvider serves that purpose. GuestDataProvider uses methods from our session bean to access the data in the guest table but it, like HomePage, is declared in its own file so how can it access the session bean and call into its methods?

The solution was to create the following interface that GuestDataProvider implements:

public interface IEjbDataProvider<T> extends IDataProvider<T> {
AbstractFacade<T> getFacade();
}

GuestDataProvider is declared as abstract because it doesn’t actually implement getFacade which is defined as returning an instance to AbstractFacade. Instead, GuestFacade relies on its subclasses to provide the method’s implementation.

In the HomePage constructor we create an instance of a GuestDataProvider and override its getFacade method by returning the reference to our session bean.

public class HomePage extends BasePage {

    @EJB(name = "GuestFacade")
    private GuestFacade guestFacade;

    public HomePage() {
        super();

        add(new FeedbackPanel("feedback"));

        /*
         * A loadable and detachable model whose sole purpose is to always
         * return a new Guest object when its load method is called.
         */
        LoadableDetachableModel<Guest> newGuestLoadableDetachableModel = new LoadableDetachableModel<Guest>() {

            @Override
            protected Guest load() {
                return new Guest();
            }
        };

        /*
         * The guestForm uses a nested model. The outer model is a compound property
         * model and the inner model is a light weight loadable and detachable model.
         */
        Form<Guest> guestForm = new Form<Guest>("guestform", new CompoundPropertyModel<Guest>(newGuestLoadableDetachableModel)) {

            @Override
            protected void onSubmit() {
                Guest guest = getModelObject();
                guestFacade.create(guest);
                setModelObject(new Guest());
                guest = new Guest();
            }
        };

        /*
         * Add the custom NameTextField compent for
         * first and last name to the form, nesting each
         * in a FormComponentFeedbackBorder for displaying
         * data entry errors.
         */
        guestForm
                .add(new FormComponentFeedbackBorder("firstNameBorder")
                .add(new NameTextField("firstName")));
        guestForm
                .add(new FormComponentFeedbackBorder("lastNameBorder")
                .add(new NameTextField("lastName")));
        add(guestForm);

        GuestDataProvider gdp = new GuestDataProvider() {

            @Override
            public AbstractFacade<Guest> getFacade() {
                return guestFacade;
            }
        };

        /*
         * When dealing with potentially large lists of data it is
         * better to use a DataView whose constructor takes a data
         * provider as its second parameter.
         */
        DataView<Guest> guestListView = new DataView<Guest>("namelist", gdp) {

            @Override
            protected void populateItem(Item<Guest> item) {
                Guest guest = item.getModelObject();
                item.add(new Label("name", guest.toString()));
            }

        };

        add(guestListView);

    }
}

This demonstrates that though JavaEE Inject places restrictions on where we can inject resources there are simple patterns that we can employ to overcome them.

Wicket Models Put To Best Use

HomePage also uses loadable/detachable models for both the form and the list of visitor names it displays. When Wicket completes its request cycle the components containing them will not contribute any model data to the serialization of the page.

Though I won’t go into detail here, understanding and mastering Wicket models is a critical component of your Wicket education. If you don’t know the difference between static and dynamic models or you aren’t familiar with loadable/detachable models you can read my article here to get up to speed on this subject.

Components

Now, lets talk a bit about Wicket components and some ideas that I’d like to share with you.

Whenever I develop a Web application I like to encapsulate business rules so that they can be reused. Presentation components are a prime target for encapsulating business rules, especially if they are used more than once on a page or on more than one page. Business rules encompass issues like requiring the user to enter a value for an input field, min and max values, etc.

Some frameworks make extending their presentation components more difficult than one would imagine. On the other hand, this is one area where Wicket shines – Wicket’s components are strikingly easy to extend and to imbed business rules in.

In article #1 we expressed the business rules for GuestBook as follows:

Limit the number of characters our visitors can key in for their first and last names to a maximum of 45 characters each.
Both first and last name are required.

GuestBook uses NameTextField, a subclass of TextField, to encapsulate and enforce its business rules.

public class NameTextField extends TextField<String>{

    /**
     *
     * @param id
     * @param model
     */
    public NameTextField(String id, IModel<String> model) {
        super(id,model);
        setRequired(true);
    }

    /**
     *
     * @param id
     */
    public NameTextField(String id) {
        this(id,null);
    }

    @Override
    protected void onComponentTag(ComponentTag tag) {
        tag.put("maxlength", "45");
        tag.put("size", "55");
        super.onComponentTag(tag);
    }


}

Since both first name and last name must enforce the same requirements on the user it makes sense to encapsulate the logic in one place. In the above code we set the component’s required flag to true and we override the onComponentTag method to output the ‘maxlength’ and ‘size’ attributes for the input tag.

This is a prime example of applying the ‘Don’t Repeat Yourself’ (DRY) principle in action and Wicket, to its credit, makes this an incredibly easy process.

Now a word or two on structuring your code.

Project Structure

One of the things I really hate is dealing with a project which just dumps everything into a single package whose name provides absolutely no insight as to the purpose of the code contained in it. Bad! Bad! Bad!

In GuestBook, package names provide useful insight as to the purpose of the code they contain. The packages also serve to layer the project’s structure by areas of concern, namely entities, session beans and Wicket which it further sub groups into components and data providers.

Some Final Thoughts

Well that just about wraps things up for this series but before we say goodbye I’d like to extend my thanks to all the developers and contributors who have made Java, Wicket and its infrastructure of contributed libraries and NetBeans the productive resources they are for us.

I hope you have enjoyed reading this series and following along with me as much as I have enjoyed sharing my time with you.

Please feel free to leave your comments for any of the articles in this series and I will try to find the time to respond to them all.

May all your days coding be happy and productive ones.

Java EE6 & Wicket - Article #5–Building Out The Guest Book Web Application Using NetBeans

2011-03-30T13:37:00.000-04:00

Welcome to the 5th in a series of detailed articles on Java EE6 & Wicket. If you haven’t already, please read the following previous articles before continuing.

In this, the 5th article in this series, we will complete the implementation of the GuestBook Web application. So lets get started.

Modifying The Generated Markup And Code

If you haven’t already, fire up NetBeans because we are going to make a few changes to the generated code so that our GuestBook’s home page will look like the image in article #1. In order to do that we will compose the HomePage using Wicket Markup Inheritance.

Our HomePage displays a Wicket logo which you can download here. Place the logo in the com.myapp.wicket package.

Next, we need to make a few changes to the generated code. Create a new HTML file in the com.myapp.wicket package and name it BasePage.

Right click on the com.myapp.wicket package, select New | Other to open the New File window
Select Web in the Categories panel and then select HTML in the File Types panel and click the Next button.
Enter BasePage for the HTML File Name and click the Finish button. NetBeans will generate the BasePage.html file and open it in the editor.

Replace the generated markup with the following markup and save the file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>

<html xmlns:wicket="http://wicket.apache.org">

    <head>

        <meta name="description" content="A guest list of the rich and famous written in Java and Wicket">

    </head>

    <body>

        <div wicket:id="headerpanel"></div>

        <wicket:child/>

    </body>

</html>

Replace all the code in com.myapp.wicket.BasePage.java with the following code and save the file:

package com.myapp.wicket;           

import org.apache.wicket.markup.html.WebPage;

/** 
*
* @author Jeff
* @version 
*/

public class BasePage extends WebPage {

/**
* Construct.
* @param model
*/
public BasePage() {
super();
add(new HeaderPanel("headerpanel"));
}
}

Replace the HTML markup in com.myapp.wicket.HeaderPanel.htm with the following markup and save the file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns:wicket="http://wicket.apache.org">
<head><title></title></head>
<body>
<wicket:panel>
<wicket:link>
<img src="Apache_Wicket_logo.png" style="float:left;"/>
</wicket:link>
<h1 style="margin-left: 180px; color: #E9601A; font-style: italic; font-size: 1.5em; font-family: sans-serif; font-weight: bold; line-height: 59px; white-space: nowrap">
<span wicket:id="headerpanneltext">Java EE6 And Wicket EJB Tutorial</span>
</h1>
<hr style="color: #E9601A; background-color: #E9601A; height: 1px;"/>
</wicket:panel>
</body>
</html>

Replace the Java code in com.myapp.wicket.HeaderPanel.java with the following code and save the file:

package com.myapp.wicket;           

import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.panel.Panel;

/** 
*
* @author Jeff
* @version 
*/

public class HeaderPanel extends Panel {

public HeaderPanel(String id)
{
super(id);
add(new Label("headerpanneltext", "Java EE6 And Wicket EJB Tutorial"));
}

}

Replace all the HTML markup in com.myapp.wicket.HomePage.html with the following markup and save the file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns:wicket="http://wicket.apache.org">
<head>
<wicket:head>
<title>Guests</title>
<wicket:link>
<link rel="stylesheet" type="text/css" href="style.css"/>
</wicket:link>
</wicket:head>
</head>
<body>
<wicket:extend>
<div>
<div style="margin-top: 20px; padding-left: 15px;">
<h2 style="color:#333333; white-space: nowrap;">Please Sign Our Guest List</h2>
<div wicket:id="feedback"></div>
<form wicket:id="guestform">
<label>First Name:
<span wicket:id="firstNameBorder">
<input wicket:id="firstName" type="text"/>
</span>
</label>
<br/>
<label>Last Name:
<span wicket:id="lastNameBorder">
<input wicket:id="lastName" type="text"/>
</span>
</label>
<br/>
<input type="submit"/><input type="reset"/>
</form>
</div>
<hr style="background-color: #E9601A; color: #E9601A; height: 1px; margin-top: 20px;"/>
<div style="margin-top: 20px; padding-left: 15px;">
<h2 style="color:#333333; white-space: nowrap;">Visitors Who Have Signed Our Guest List</h2>
<div wicket:id="namelist" style="white-space: nowrap;">
<span wicket:id="name" style="font-size: 1.2em; color: #333333;">name</span>
</div>
</div>
</div>
</wicket:extend>
</body>
</html>

Replace all the Java code in com.myapp.wicket.HomePage.java with the following code and save the file:

package com.myapp.wicket;

import com.myapp.wicket.components.NameTextField;
import com.myapp.wicket.dataproviders.GuestDataProvider;
import com.myapp.entities.Guest;
import com.myapp.sessionbeans.AbstractFacade;
import com.myapp.sessionbeans.GuestFacade;
import javax.ejb.EJB;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.validation.FormComponentFeedbackBorder;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
import org.apache.wicket.markup.repeater.Item;
import org.apache.wicket.markup.repeater.data.DataView;
import org.apache.wicket.model.CompoundPropertyModel;
import org.apache.wicket.model.LoadableDetachableModel;

public class HomePage extends BasePage {

@EJB(name = "GuestFacade")
private GuestFacade guestFacade;

public HomePage() {
super();

add(new FeedbackPanel("feedback"));

/*
* A loadable and detachable model whose sole purpose is to always
* return a new Guest object when its load method is called.
*/
LoadableDetachableModel<Guest> newGuestLoadableDetachableModel = new LoadableDetachableModel<Guest>() {

@Override
protected Guest load() {
return new Guest();
}
};

/*
* The guestForm uses a nested model. The outer model is a compound property
* model and the inner model is a light weight loadable and detachable model.
*/
Form<Guest> guestForm = new Form<Guest>("guestform", new CompoundPropertyModel<Guest>(newGuestLoadableDetachableModel)) {

@Override
protected void onSubmit() {
Guest guest = getModelObject();
guestFacade.create(guest);
setModelObject(new Guest());
guest = new Guest();
}
};

/*
* Add the custom NameTextField compent for 
* first and last name to the form, nesting each
* in a FormComponentFeedbackBorder for displaying
* data entry errors.
*/
guestForm
.add(new FormComponentFeedbackBorder("firstNameBorder")
.add(new NameTextField("firstName")));
guestForm
.add(new FormComponentFeedbackBorder("lastNameBorder")
.add(new NameTextField("lastName")));
add(guestForm);

GuestDataProvider gdp = new GuestDataProvider() {

@Override
public AbstractFacade<Guest> getFacade() {
return guestFacade;
}
};

/*
* When dealing with potentially large lists of data it is
* better to use a DataView whose constructor takes a data
* provider as its second parameter.
*/
DataView<Guest> guestListView = new DataView<Guest>("namelist", gdp) {

@Override
protected void populateItem(Item<Guest> item) {
Guest guest = item.getModelObject();
item.add(new Label("name", guest.toString()));
}

};

add(guestListView);

}
}

Replace the content of com.myapp.wicket.style.css with the following content and save the file:

body {
white-space: nowrap;
}

.feedbackPanelERROR {
color: red !important;
list-style: circle;
font-weight: bold;
}

.feedbackPanelINFO {
color: green;
list-style: circle;
font-weight: bold;
}

We need to create a properties file in which we will declare the warning messages that Wicket will use when validating the input form on the HomePage.

Right click on the com.myapp.wicket package in the Projects panel and select New | Other to open the New File Window.
Select Other from Categories and select Properties File from File Types and click the Next button.
Enter HomePage for the File Name and click the Finish button. NetBeans will open the properties file in the eiditor.

Add the following content to the the com.myapp.wicket.HomePage.properties file and save the file:

firstName.Required=First Name Is Required. 
    
lastName.Required=Last Name Is Required.

Next, we will add a custom TextField component to the project.

Right click on Source Packages in the Projects panel and select New | Other to open the New File window.
Select Java from Categories and Java Class from File Types and click the Next button.
Enter NameTextField for the Class Name and enter com.myapp.wicket.components for the Package name and click the Finish button. NetBeans will open the NameTextField.java file in the editor.

Replace all the Java code in the NameTextField.java file with the following and save the file:

package com.myapp.wicket.components;

import org.apache.wicket.markup.ComponentTag;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.model.IModel;

/**
* A domain specific extension of a Wicket TextField
* that sets the required flag and adds the maxlength=45
* and size=55 attributes to be rendered.
*
* Demonstrates how you can easily extend Wicket
* components to provide domain specific requirement.
*
* @author Jeff
*/
public class NameTextField extends TextField<String>{

/**
*
* @param id
* @param model
*/
public NameTextField(String id, IModel<String> model) {
super(id,model);
setRequired(true);
}

/**
*
* @param id
*/
public NameTextField(String id) {
this(id,null);
}

@Override
protected void onComponentTag(ComponentTag tag) {
tag.put("maxlength", "45");
tag.put("size", "55");
super.onComponentTag(tag);
}


}

Next, we will add an interface to the project.

Right click on Source Packages in the Projects panel and select New | Other to open the New File window.
Select Java from Categories and select Java Interface from File Types and click the Next button.
Enter IEjbDataProvider.java for the Class Name and enter com.myapp.wicket.dataproviders for the Package name and click the Finish button. NetBeans will open the IEjbDataProvider.java file in the editor.

Replace all the Java code in the IEjbDataProvider.java file with the following and save the file:

package com.myapp.wicket.dataproviders;

import com.myapp.sessionbeans.AbstractFacade;
import org.apache.wicket.markup.repeater.data.IDataProvider;

/**
* Extended interface definition of IDataProvider<T> that provides type safe access to session beans.
* Provides the ability to access a session bean in any object.
*
* Use Case: Need to access session in objects other than a Wicket WebPage.
*
* Background - The JavaEEComponentInjector enables Java EE 5 resource injection in Wicket Pages but
* often we need to access to session beans from other objects such as DataProviders and Models. This
* interface supports such a use cases.
*
* Usage
* public class HomePage extends BasePage {
*   @EJB(name = "GuestFacade")
*   private GuestFacade guestFacade;
*   private Guest guest;
*
*   public HomePage() {
*      super();
*      guest = new Guest();
*      GuestDataProvider gdp = new GuestDataProvider() {
*
*          @Override
*          public AbstractFacade<Guest> getFacade() {
*              return guestFacade;
*          }
*      };
*
*
* @param <T>
* @author Jeff
*/
public interface IEjbDataProvider<T> extends IDataProvider<T> {
AbstractFacade<T>  getFacade();
}

Next, we will add a Java class to the project.

Right click on com.myapp.wicket.dataproviders in the Projects panel and select New | Other to open the New File window.
Select Java from Categories and select Java Class from File Types and the click the Next button.
Enter GuestDataProvider for Class Name and click the Finish button.

Replace all the Java code in the GuestDataProvider.java file with the following and save the file:

package com.myapp.wicket.dataproviders;

import com.myapp.entities.Guest;
import java.util.Iterator;
import java.util.List;
import org.apache.wicket.model.IModel;
import org.apache.wicket.model.LoadableDetachableModel;

abstract public class GuestDataProvider implements IEjbDataProvider<Guest>{

@Override
public Iterator<? extends Guest> iterator(int first, int count) {
int[] range = {first, count};
List<Guest> guests = getFacade().findRange(range);
return getFacade().findRange(range).iterator();
}

@Override
public IModel<Guest> model(final Guest object) {

final Integer id = object.getId();

LoadableDetachableModel<Guest> ldm = new LoadableDetachableModel<Guest>(object) {
@Override
protected Guest load() {
return getFacade().find(id);
}
};

return ldm;
}

@Override
public int size() {
return getFacade().count();
}

@Override
public void detach() {}

}

The last change we must make is to com.myapp.wicket.Application.java file. Replace all the code in Application.java with the following code and save the file:

package com.myapp.wicket;           

import org.apache.wicket.protocol.http.WebApplication;
import org.wicketstuff.javaee.injection.JavaEEComponentInjector;
/** 
*
* @author Jeff
* @version 
*/

public class Application extends WebApplication {

public Application() {
}

@Override
protected void init() {
super.init();
addComponentInstantiationListener(new JavaEEComponentInjector(this));
}

@Override
public Class getHomePage() {
return HomePage.class;
}
}

With all these changes in place you should now be able to run the project in your browser.

In the next and last article we will examine the code, focusing on the integration we provided for consuming the EJB in our HomePage. I will also discuss some best practices that I’ve used here, especially pertaining to Wicket components and models. If you don’t know the difference between static and dynamic models or you aren’t familiar with loadable/detachable models you can read my article here to get up to speed on this subject. Stay tuned!

Put Your Wicket Applications On A Diet

2011-03-29T22:43:00.001-04:00

Wicket, at the end of each request cycle, serializes the active page into a byte array and stores it for the next request. The entire object graph of the page including all components and their associated models are included in the generated byte stream. This could possibly, depending on the size of the graph, place stress on server resources.

So how can we reduce our page footprint and put our applications on a diet? By mastering Wicket models, that’s how. As it turns out, understanding static, dynamic and loadable/detachable models is key if you want to reduce the memory footprint of your Wicket applications.

To begin out discussion of Wicket’s models let’s first look at the IModel interface.

IModel

All Wicket models implement the IModel interface which is defined as follows:

public interface IModel<T> extends IDetachable
{
	/**
	 * Gets the model object.
	 * 
	 * @return The model object
	 */
	T getObject();

	/**
	 * Sets the model object.
	 * 
	 * @param object
	 *            The model object
	 */
	void setObject(final T object);
}

The IModel interface defines 2 methods:

getObject is called by Wicket when rendering the component.
setObject is called by Wicket when it has to update the component such as after all form components have validated (see Wicket request life cycle and form validation).

IDetachable

In addition to defining the getObject and setObject methods, IModel also extends the IDetachable interface which is defined as follows:

public interface IDetachable extends IClusterable
{
	/**
	 * Detaches model after use. This is generally used to null out transient references that can be
	 * re-attached later.
	 */
	void detach();
}

The IDetachable interface defines only 1 method:

detach is called by Wicket at the end of a request’s lifecycle.

IModel and IDetachable form the foundation of Wicket’s model API which allows for both static and dynamic model implementations. The 4 primary model implementations that Wicket provides are:

Model – the simplest of all Wicket models. It can be used as both a static and as a dynamic model.
PropertyModel – a dynamic model.
CompoundPropertyModel – a dynamic model that also provides field binding.
LoadableDetachableModel – a dynamic model that detaches the value it wraps at the end of a request’s lifecycle.

Static And Dynamic Models

Here’s an example of using Model as a static model:

Person person = Person.getPerson();
add(new Label("firstName", new Model<String>(person.getFirstName())));
add(new Label("lastName", new Model<String>(person.getLastName())));

And here’s an example of using Model as a dynamic model:

Person person = Person.getPerson();

add(new Label("firstName", new Model<String>(){

@Override 
public String getObject() { 
return Person.getPerson().getFirstName(); 
} 

}));

add(new Label("lastName", new Model<String>(){

@Override 
public String getObject() { 
return Person.getPerson().getLastName(); 
}

}));

In the above code for both static and dynamic models we are adding 2 Label components to the page. The Label component constructor takes as a second parameter a reference to a Model object.

In our static example above notice how each of the models directly wraps its value. Each of the models holds a reference to a String and in Java strings are immutable; even if the Person object’s firstName and lastName field values change and if the page were refreshed the values displayed in the two label components will always show the values they were created with. This is the reason these types of models are called static.

In our dynamic example above notice how instead of using Wicket’s basic Model class we subclass Model and override its getObject method (see IModel) to return the appropriate value. Whenever Wicket needs to render the above components it will call its model’s getObject methods to obtain the values to be rendered; now, if the Person object’s firstName and lastName field values change and if the page were refreshed the values displayed in the two label components will reflect those changes. This is the reason these types of models are called dynamic.

So let me reiterate here by giving you a concise definition of static and dynamic models:

A static model is any model that directly wraps a value.
A dynamic model is any model that does not directly wrap a value but instead overrides the getObject method to retrieve the value when Wicket renders the component.

In the above and for the remainder of this article I use the word ‘value’ to denote either a primitive or a reference value.

Some Models Are Heavier Than Others

What makes Wicket a stateful framework is the serialization of its components at the end of each request’s life cycle. However, this doesn’t come without a price which is the amount of memory that can be consumed by serializing the values that component models wrap. While a page with 2 Labels might seem trivial, scale that out to thousands or tens of thousands of users concurrently hitting this page and it isn’t so trivial anymore.

So how can we manage the memory footprint of our pages to significantly reduce the load that our models have on memory? The answer is by using LoadableDetachableModels. At the beginning of this article I introduced the IDetachable interface and this little nugget is the key to Wicket’s LoadableDetachableModel.

Lets consider a slightly more involved use case that involves a form that uses a CompoundPropertyModel:

Form<Person> form = new Form<Person>("form", new CompoundPropertyModel<Person>(Person.getPerson()));
form.add(new TextField<String>("firstName"));
form.add(new TextField<String>("lastName")); 
add(form);

In this example we are creating a form with a CompoundPropertyModel of type Person. When this page is serialized the Person instance that the CompoundPropertyModel wraps will be serialized. That is, unless we take steps to prevent it from serializing Person.

This use case thus presents us with a unique challenge; how can we use a CompoundPropertyModel without incurring the load on memory caused by serializing the Person instance? The answer lies in Wicket’s LoadableDetachableModel and Wicket’s ability to use nested models.

LoadableDetachableModel Take The Weight Off

LoadableDetachableModel is a model that loads and detaches the value it wraps by storing the reference to the value in a temporary, transient reference which it sets when its getObject method is called by calling the abstract method ‘load’ and which it sets to null when the method ‘detach’ is called.

LoadableDetachableModel ldm = new LoadableDetachableModel<Person>() {

    @Override 
    protected Person load() { 
        return Person.getPerson(); 
    }

};

As you can see from the above example we override the load method to return an instance of Person. In a real application we could query a database.

Using LoadableDetachableModel allows us to attach a reference to Person on each request and detach it at the end of the request cycle thereby eliminating the need to serialize the Person object.

[*** In addition, another added benefit you get from using a detachable model is when you are dealing with objects that for one reason or another can’t be serialized. In those cases you can just wrap them in a detachable model thereby eliminating the need to serialize them. ***]

Now we know we can use LoadableDetachableModel when we want to dynamically load and discard the values wrapped by our models. But how can we use them and still take advantage of the binding features that the CompoundPropertyModel provides? Nesting models is the answer.

Nesting Models

Form<Person> form = new Form<Person>("form", new CompoundPropertyModel<Person>(ldm));
form.add(new TextField<String>("firstName"));
form.add(new TextField<String>("lastName"));
add(form);

Notice in the above example that we are passing our LoadableDetachableModel instance, ldm, as a parameter to the CompoundPropertyModel’s constructor. By nesting a LoadableDetachableModel in a CompoundPropertyModel we get the benefit of both models. That’s like having your cake and eating it, too!

In my opinion nested models are one of the coolest features that Wicket provides - they reduce the load on memory that Wicket’s stateful nature would have had we not been able to eliminate serializing the values wrapped by its models.

So, the next time someone tells you that scaling out a Wicket application is difficult because it serializes its pages just don’t believe it; Wicket makes it incredibly easy by using nested models.

Well that concludes my little discussion of Wicket models and I hope you have enjoyed it. Remember, having a solid understanding of models is a must if you seriously want to be a master Wicket programmer.

Java EE6 & Wicket - Article #4 - Adding JPA Persistence And EJB Support

2011-03-29T10:17:00.001-04:00

Welcome to the 4th in a series of detailed articles on Java EE6 & Wicket. If you haven’t already, please read the following previous articles before continuing.

Data Access

The GuestBook Web application we are building must access the data from the guest table in the guestbook database which we created together in the 2nd article. The goal of this article is to provide access to the database using JPA and Enterprise Java Bean (EJB).

NetBeans built in tooling supports creating Entity beans from an existing database table. We will use this feature to generate an Entity bean from the guest table.

NetBenas built in tooling also supports creating an EJB. We will use this feature to create a stateless session bean with JPA access functionality which is commonly referred to as a facade and in the next article we will inject an instance of this facade into our Wicket pages that will allow them to access the guestbook database.

One of the new features of EE6 EJB is, unlike EE5, it doesn’t require we implement interfaces when access is local (meaning from the same container).

First, we will generate our Entity bean from the guest table and then we will create the EJB to provide access to the database. So lets get started.

Create A New Entity Class From A Database Table

In the Projects panel right click on the Source Packages item and select New | Other which will open the New File window. In the Categories list select Persistence and in File Type select Entity Classes from Database and then click the Next button.

Expand the Data Source dropdown and select New Data Source to open the Create Data Source window. Enter guestbook for the JNDI Name and from the Database Connection dropdown list select the database connection which we created in the previous article and click OK.
If prompted for the password enter the password you created when you installed MySQL and click OK.
From the list of Available Tables select the guest table and then click the Add button to add it to the Selected Table list and click the Next button.
Enter com.myapp.entities for the Package name and click the Next button.
Select java.util.List for the Collection Type and then click the Finish button.

The result of the above steps is NetBeans created Guest.java POJO with JPA annotations and placed it in the com.myapp.entities package. NetBeans also created the JPA configuration file persistence.xml. If you fully expand the project node in the Projects panel you will see the following:

If you open the Guest.java file you will see that it contains standard JPA annotations, getters and setters and numerous named queries. While you have the file open we will apply a change to its ‘toString’ method which we will use when be build at the application:

If it isn’t already, open Guest.java and replace the ‘toString’ method (it is located at the bottom of the file) with the following:

@Override
public String toString() {
return firstName + " " + lastName;
}

We will make use of this method i

Create The EJB

In the Projects panel right click on Source Packages and select New | Other to open the New File window.
From Categories select Persistence and from File Types select Session Beans For Entity Classes and click the Next button.
Select com.myapp.entities.Guest from Available Entity Classes and click the Add button to add it to the list of Selected Entity Classes and then click the Next button.
Enter com.myapp.sessionbeans for the Package and click the Finish button. Notice how we didn’t create any interfaces in this last step.

The result of the above steps is NetBeans created 2 classes in the com.myapp.sessionbeans package, AbstractFacade.java and GuestFacade.java.

AbstractFacade.java is an abstract class that implements generalized functionality.
GuestFacade.java, a subclass of AbstractFacade.java, provides Guest.java type specific behavior and is annotated with @Stateless marking it as a stateless session bean.

One more thing to do and then we are done. Fully expand Server Resources in the Projects panel and open the sun-resources.xml file. If you set up your MySQL installation to require a password then make sure the Password’s property tag in this file has your correct password. If it doesn’t add your password and save the file. I’ve modified mine as follows:

<property name="Password" value="admin"/>

In the next article we will build out the Wicket parts of GuestBook and use the features provided by the JavaEE Inject Library which we added to our project in the 3rd article to inject the GuestFacade.java session bean into our Wicket pages. Stay tuned!

Java EE6 & Wicket - Article #3 – Generating The Guest Book Web Application Using NetBeans And Deploying It To GlassFish

2011-03-28T07:49:00.001-04:00

Welcome to the 3rd in a series of detailed articles on Java EE6 & Wicket. If you haven’t already, please read the following previous articles before continuing.

In this, my 3rd article in this series, we will discuss and demonstrate the generation of the initial GuestBook Web application using the popular NetBeans IDE and the Wicket plugin so please, if you haven’t already, install these two on your development machine before continuing with the rest of this article.

Simple Deployment With Java EE6 And The EJB 3.1 Specification

EE5 frequently required the use of an Enterprise Application Archive for deploying EE Web application. This usually meant having to use multiple projects to deploy even the simplest of EE applications. One of the new features of EE6, sometimes called EAR-less applications, addresses this issue and makes deploying EE6 applications much simpler. Rather than going into the details here, you can read the article Java EE6: EJB3.1 Is a Compelling Evolution, which provides an excellent review of this new feature as well as EE6 in general. The GuestBook Web application that we are now going to create will use this new feature.

OK, lets get started.

Generating The GuestBook Web Application

If you haven’t already, fire up NetBeans.

From the main menu select File | New Project which will open the New Project window.
Select Java Web in the Categories panel and Web Application from the Projects panel and click the Next button.
Enter GuestBook for the project name and click the Next button.
If they aren’t already, select GlassFish Server 3 as the server and Java EE 6 Web as the Java EE version and then click the Next button.
The Wicket plugin added Wicket to the list of frameworks that you can use in Web applications. In the Frameworks panel select Wicket as the framework to use in our application and then click the Finish button.

When we clicked the Finish button NetBeans generated our GuestBook application for us and displays it in the Project panel. If you fully expand the GuestBook node in the Projects panel you will see the following:

Notice the Wicket jars that are listed under the Libraries node in the above image. These jars were contributed by the Wicket plugin when the project was generated. The plugin also contributed a number of files in our com.myapp.wicket package. In essence, the Wicket plugin generated a basic Wicket application for us that we can run right out of the box, so lets do that now.

Run the application by clicking on the Run Main Project icon located on the main tool bar. Your browser should open, if it isn’t already, and a new page will open and display the application’s output as in the following image:

That’s pretty cool considering the minimal effort that was required on our part to get this application up and running at this point.

If you look at the NetBeans Output window you should see a GlassFish Server 3 tab. If you click on this tab you should see that our application has been deployed onto the GlassFish server for us. Also, you should see the following output from Wicket telling us that it is running in development mode.:

Lets ignore the application that the Wicket plugin generated for us for the time being because we now want to turn our attention to adding EJB support to the project. First, though, a little background.

Wicket’s Single Purpose

Wicket has been designed to solve only one specific problem which is to enable component-oriented, programmatic manipulation of markup. In fact, its creators say as much and you can read their own words in their Wicket’s Vision statement here.

As such, Wicket doesn’t provide out-of-the-box support for EJB. Wicket does have, though, many libraries that have been contributed to the project and which provide a lot of the extras that we often need. One of these libraries is the JavaEE Inject Library and it provides the ability to use the @EJB, @PersistenceUnit and @Resource annotations in our Wicket applications. I suggest that you go to the web site hosting the library and read up on the details before continuing with the remainder of this article because it is important to understand not only what the library does for us but how it does it.

Adding The JavaEE Inject Library To Our Project

To keep things simple, I’ve created a compressed file named guestbooktutorialadditionaljars.zip which contains all the jars required by the JavaEE Inject Library and I posted it here. Download the file onto a folder on your machine and extract its content. Then follow these steps to add the jar files to the project:

In the Projects panel right click on the Libraries node and select Add Jar/Folder to open the Add Jar/Folder window.
Navigate to the folder on your machine where you extracted the contents of the guestbooktutorialadditionaljars.zip to and select all 3 jar files (important - do not select the zip file itself if it happens to also resides in the same folder, only select the 3 jar files) as pictured below.
Now click the Open button to close the window and add the 3 jar files to the project.

The result of the above is that NetBeans has added the 3 jar files we selected to our project’s classpath which we can see by looking at the files listed under the Libraries entry in the Projects panel.

We’ve now included all the jars that our project requires and in the next article we’ll discuss and demonstrate adding JPA persistence support to the project. Stay tuned!

Java EE6 & Wicket - Article #2 – Creating A Backing Datastore And Schema Using MySQL

2011-03-27T14:07:00.001-04:00

Welcome to the 2nd in a series of detailed articles on Java EE6 & Wicket. If you haven’t already, please read the following previous articles before continuing.

In this, my 2nd article in this series, we will discuss and demonstrate creating the backing datastore that our GuestBook Web application will use. To accomplish this, we will rely on NetBeans which has excellent built in support for working with MySQL. If you haven’t already created a connection to MySQL in NetBeans you will need to do so before continuing. If you’d like to view an excellent tutorial that demonstrates connecting to MySQL I recommend you read Connecting to a MySQL Database.

Create A New Database

Now that you have connected to MySQL in NetBeans we can get started. If it isn’t already, fire up NetBeans and open the Services tab.

We want to create a MySQL database that will be dedicated to the GuestBook Web application that we will build together in later articles. NetBeans MySQL support makes creating a new database trivial as the following steps demonstrates.

In Services, expand the Databases item, right click on the MySQL entry and then select Create Database.
In the Create MySQL Database window enter guestbook in the New Database Name field. It should look exactly
like the following image. Now click OK.

When we clicked OK NetBeans created a new database called guestbook. It also created a new jdbc connection for the guestbook database and added it as an item listed under Databases as the image below shows.

Create A New Table With Test Data

Now that we have created the guestbook database and jdbc connection we can create a table which we will call guest and which will serve to store the information that our GuestBook Web application visitors will provide. We also want to load the table with some test data which we will use to insure that our database is working properly and also later on when we test our GuestBook Web application.

To make this step easier for you, I’ve created a SQL script that we will run to generate the table and load it with test data. This is the script that we will run:

CREATE TABLE `guestbook`.`guest` (

`id` INT NOT NULL AUTO_INCREMENT ,

`firstName` VARCHAR(45) CHARACTER SET 'utf8' COLLATE 'utf8_general_ci' NOT NULL ,

`lastName` VARCHAR(45) CHARACTER SET 'utf8' COLLATE 'utf8_general_ci' NOT NULL ,

PRIMARY KEY (`id`) );

INSERT INTO `guestbook`.`guest` (`firstName`, `lastName`) VALUES ('James', 'Taylor');

INSERT INTO `guestbook`.`guest` (`firstName`, `lastName`) VALUES ('Eric', 'Clapton');

INSERT INTO `guestbook`.`guest` (`firstName`, `lastName`) VALUES ('Bill', 'Gates');

INSERT INTO `guestbook`.`guest` (`firstName`, `lastName`) VALUES ('Steven', 'Jobs');

INSERT INTO `guestbook`.`guest` (`firstName`, `lastName`) VALUES ('John', 'Glenn');

INSERT INTO `guestbook`.`guest` (`firstName`, `lastName`) VALUES ('John', 'Kennedy');

INSERT INTO `guestbook`.`guest` (`firstName`, `lastName`) VALUES ('Glenn', 'Ford');

INSERT INTO `guestbook`.`guest` (`firstName`, `lastName`) VALUES ('Al', 'Pacino');

INSERT INTO `guestbook`.`guest` (`firstName`, `lastName`) VALUES ('President', 'Obama');

The above script creates a table by defining its schema in the CREATE TABLE command. The schema declares 3 columns - id, firstName and lastName. The id column is defined as an auto incrementing column whose values will serve as the table’s primary key. The first and lastName columns are used to store the first and last names of the visitors to our GuestBook Web application. They are both defined as being required and able to store up to 45 characters.

The interesting part of the firstName and lastName column definitions are our use of CHARACTER SET 'utf8' and COLLATE 'utf8_general_ci' to define the character sets and collation for these columns:

By using CHARACTER SET 'utf8' in the column definitions we are instructing MySQL to use the utf8 character set for the characters stored in these columns. This will allow us to store the names of our GuestBook Web application’s visitors from all over the world whose names might require 3 bytes per character.
By using COLLATE 'utf8_general_ci' in the column definitions we are instructing MySQL to use case insensitive collation on these columns. The benefit of this is that when we query on the guest table we will be able to order the result set on firtName and lastName and MySQL will order the result set using case insensitive collation on these columns.

The remaining statements in the script, the INSERT statements, insert rows into the table whose data will be used to test the GuestBook Web application.

NetBeans has built in support for running scripts against an already created database. Please follow these steps to run the above script against the guestbook database:

In NetBeans Services right click on the jdbc connection that was created when we created the guestbook database and select Execute Command to open a SQL Command window in the editor.
Copy the script from above and paste it into the SQL Command editor window and then click on the Run SQL icon located on the window’s button bar. Now fully expand the the guestbook jdbc connection in the Services pane and you should see the following:

We can see that NetBeans successfully applied our SQL script to the guestbook database creating the guest table which contains id, firstName and lastName columns. We can now issue a query against the table to retrieve the list of names we loaded the table with:

In the Services window, right click on the guest table’s entry and select Execute Command.
In the newly opened SQL Command window, type SELECT * FROM guestbook.guest ORDER BY firstName, lastName and then click on the command window’s Run SQL icon located in its icon bar to run the query against the guest table. When the query completes the result set will be displayed listing the 9 rows of data that we loaded into the guest table:

With our database preparation out of the way the next article will focus on the fun stuff – generating an ear-less dynamic web application, adding the Wicket framework to it and deploying it to GlassFish. Stay tuned!

Java EE6 & Wicket - Article #1 - Requirements, Architecture & Resources

2011-03-24T09:59:00.000-04:00

Welcome to the first in a series of detailed articles on Java EE6 & Wicket. If you haven’t already, please read my previous article before continuing.

Lets begin with a discussion of the requirements for GuestBook, the Web application we will create.

It is always a good idea to define the purpose of an application right up front so here’s ours for GuestBook

Present a Web page that allows visitors to sign a guest book and view a list of visitors who have signed the guest book.

Rather simple, isn’t it. But even simple applications have business rules so here’s ours for GuestBook

GuestBook Requirements – Business Rules

Collect the first and last name of each visitor.
Limit the number of characters our visitor can key in for their first and last names to a maximum of 45 characters each.
Both first and last name are required. So when either are omitted we have to display appropriate and informative warning messages and also highlight the offending data entry fields.
The list of names displayed should be rendered to the browser in a case-insensitive manner.

GuestBook Requirements – GUI

Good! We’ve succinctly defined our business rules but we haven’t decided what GuestBook should actually look like. My budget for the project is zero so I can’t hire a professional graphic artist. Therefore, I’ve enlisted the assistance of Vincent Van Gosh, a friend of mine, to work up an image of the page. Below is what he came up with. Nothing fancy, mind you (so what do you expect to get for free these days, anyway?) but it will serve our purpose.

As you can see from the above image, the GuestBook application consists of a single page on which are the following sections:

A header section display the Wicket graphic and the title.
Below the header section is a form which visitors use to enter their first and last names to sign the guest book. Both fields are required and each field is limited to a maximum of 45 characters. The form also contains two buttons, one for submitting the form and one for clearing out its contents.
Below the form section is a list of the names of the visitors who have previously signed our guest book. The first and last names are in ascending order by first and then last name and collated in a case-insensitive manner.

GuestBook Requirements – Data

We can’t display the list of names of our visitors if we don’t store them somewhere. So here are the requirements for storing visitor data.

We will use the popular open source MySQL relational database as our datastore.
The name of the table in which we will store the data is going to be called ‘guest’.
The schema for the quest table defines three columns: 1) id (an auto increment identity column); 2) firstName (a variable character column able to store up to 45 characters) and 3) lastName (like firstName, a variable character column able to store up to 45 characters).
The firstName and lastName columns should be defined so that they use case-insensitive collation. Remember, above we stated that the list of names displayed should be rendered in a case-insensitive manner.

GuestBook Architecture

So far we have expressed the purpose for GuestBook, we defined its business rules, worked up a graphic for what we want the Web page to look like and defined the data requirements. But we haven’t touched on what architecture we will use for actually developing GuestBook, so lets define that now.

GuestBook will be developed as a browser-based Web application.
We will use Oracle GlassFish as the Java EE6 application server.
For our presentation tier we will use the Wicket Web framework.
MySQL will be used for the datastore tier.

So our architecture stack looks something like the following:

Browser

Java EE6/GlassFish

Wicket

MySQL

IDE

I originally thought about also using Eclipse in these articles but in all honesty the Netbeans tooling is far superior to that of Eclipse when it comes to targeting Java EE and GlassFish. In my opinion, Eclipse is a great IDE. In fact, I use it very often and I am very comfortable and productive with it but I’ve come to recognize that both IDEs have their strengths and weaknesses and so I’ve opted to use NetBeans for these articles.

What you will need to complete GuestBook

Following is a list of items that I will use to complete the GuestBook application. If you intend to code along with me (and I certainly hope that you do) then you will need to have these items installed on your development machine. The list provides links to each item’s home page and download page.

ITEM	DESCRIPTION	HOME PAGE	DOWNLOAD PAGE	COMMENT
MySQL Community Server	Open Source Database	http://www.mysql.com/	http://www.mysql.com/downloads/	Version 5.5.10 at the time of writing this article
MySQL Workbench	To design, manage and document database schemata	http://www.mysql.com/	http://www.mysql.com/downloads/	This is totally optional as I will provide the database schemas for you. But it is a very good tool to have so I thought I’d mention it here. Version 5.2.33b at the time of writing this article
NetBeans	Open Source Java IDE	http://netbeans.org/	http://netbeans.org/downloads/index.html	Version 6.9.1 at the time of writing this article.
Wicket Plugin For NetBeans	Adds wicket support to the NetBeans IDE	http://netbeans.org/	http://plugins.netbeans.org/PluginPortal/ faces/PluginDetailPage.jsp?pluginid=3586	Supports NetBeans 6.9.1 at the time of writing this article

Please download and install the items listed above. In the next article, Java EE6 & Wicket - Article #2, we will focus on setting up the GuestBook MySQL database. We will define the database schema for the GuestBook application and apply it to create the guest table. We will also load the guest table with data that will be used during testing.

Java EE6 & Wicket

2011-03-15T09:57:00.001-04:00

Back To The Future

It's been a while since I've written about Java EE & Wicket. My last articles on the subject covered Java EE5 and EJB dependency injection (DI) in Wicket objects. Since I wrote those articles Java EE6 has been released along with compliant EE6 servers like GlassFish, Wicket has seen a number of point updates and the popular NetBeans IDE has upgraded its tooling.

The most interesting new feature that EE6 provides, at least from my perspective, is EAR-less deployments. With EE5 you often needed to resort to having to implement an EAR module and tie all the sub projects into that. Java EE6 eliminates that requirement - though EARs are still supported – which greatly simplifies creating Java EE6 applications and NetBeans supports creating EAR-less projects.

It would be impossible to cover all the new features that EE6 provides so I’ve decided to write a few articles covering my favorite Java related topics – EE and Wicket. In my opinion NetBeans has much better tooling and plugin support for dynamic Web projects that use Wicket so I will also discuss its tooling support for EE6 and Wicket.

I will use a simple Guest Book application as the context for the articles and I will try to keep each article small but well focused so as not to overwhelm you with too much information all at once. As I see it now the topics for each article will be something along the lines of the following:

An introduction presenting the requirements for the GuestBook Web application as well as discuss its architecture. I will also identify those pieces of the architecture that you will need to download and install on your development box.
Creating a backing datastore and schema using MySQL – here I’ll discuss creating the database that will be used as the backing data store for the Guest Book Web application.
Generating the Guest Book Web application using NetBeans and deploying it to GlassFish. We will also add all the required jar files to the project.
Adding JPA Persistence support to the project.
Building out the Guest Book Web application using NetBeans and testing it.
A wrap up.

This is what the finished Guest Book Application will look like:

Stay tuned! I’ll be rolling these articles out over the next few weeks so please check back frequently.

Updated 3/31/2011

Here’s a list of urls for the 6 articles in this series:

I-Emote on Google AppEngine

2010-11-28T10:07:00.000-05:00

I-Emote is a social Web application I am writing that allows users to create posts that can be associated with Web based content such as other Web sites and YouTube videos. Members can add their own comments and indicate they 'like' a post or comment.

Each member has their own profile page on which other members may view their latest posts as well as any personal information the member wishes to share. Profile pages also provide the means to subscribe to members' posts as well as unsubscribing.

When I set out to write I-Emote I did so as an academic study of what it takes to create a social Web site as well as target Google's cloud infrastructure - App Engine - and as such it is a work in progress; there are numerous features that it still lacks and that I am eager to implement such as email and SMS notifications, general message broadcasting and more member-centric features such as picture albums. I will eventually fill in the gaps as time permits. I intend to use what I have learned about writing a social Web site in other projects that I am and will be working on to provide them with some light weight social Web features such as commenting, fan-out and profile pages.

Below are a few screen shots that I hope you find interesting:

Screenshots of Love My Vehicle On The Web

2010-11-18T08:31:00.071-05:00

A number of years back I had written a desktop software package for tracking and managing the maintenance of vehicles and it was called Love My Vehicle. The software was well received and it managed to attract a rather large & loyal following of paid customers and had won numerous awards from various software rating groups as well as user groups. The application was written for Windows using Microsoft C++ and the MFC framework.

Many things have changed since I originally wrote that package. Most noticeably, the Web has become the preferred target for delivering services and value to customers. The Web's influence can be said to have changed the landscape of application development and delivery. Cloud based Web services have also contributed to the changing landscape by offering software developers the opportunity to deliver services to their customers without the need to invest in infrastructure and by also providing solutions for wide scalability and resiliency. Numerous cloud options now exist including Amazon's EC2 and Google's App Engine for which I have written numerous applications .

About six months ago one of my customers contacted me about migrating her licenses for Love My Vehicle to new computers her company had purchased. Unfortunately, I wasn't able to offer her any assistance because I had lost the source code to the application a few years back (which could serve as the subject for its own article). As a result I decided to create a modern version of the software targeting, of course, the Web and the cloud and as I already had practical hands on experience with App Engine I opted to target Google's cloud.

One of the early lesson I learned about targeting App Engine is that Google's limit on the amount of time allotted to each HTTP request severely limits what I can and cannot do on their servers. I learned that the best approach was to limit each request to retrieving and updating data only and to do all HTML rendering on the browser using Ajax and DOM manipulation. The added benefit of this approach is the RIA experience for the user.

The applications I already have written for App Engine all use Java and Groovy on the servers for processing Ajax requests and jQuery on the browser for DOM manipulation. The shortcoming to this approach is that client side development tends to be tedious and you lose the benefits provided by compilers and IDEs, especially catching coding errors early and code refactoring. I wondered what other options I had that would offer the same set of resources on the client that I had become accustomed to having on the server side of development. Enter Google's GWT.

GWT is Google's pure Java approach for developing rich internet applications (RIA) and it uses a novel approach of compiling Swing like Java code to native Javascript targeting IE, FF, Chrome and the Safari browsers. Using GWT lets you develop both your servlets and client side code in Java without having to give up your favorite IDE which in my case is Eclipse.

In the course of two months and coding in my spare time I have manged to be very productive using GWT. After studying and learning its "ins and outs" I have already managed to put together a nice little prototype of Love My Vehicle running on Google's App Engine cloud. This isn't a clone of the older application but rather a complete rewrite with new features and of course, Web based. Here's the link: http://lovemyvehicle.appspot.com/. Though early in its life cycle and sans source code for the original product, I am applying my knowledge of the original software's functionality to build out the new product which will support the popular 'freemium' subscription model.

As I progress in adding and refining functionality I will post updates here. I also intend to write new articles specifically relating to its development that will also include GWT and App Engine.

Screen shots of early prototype

Updated 11/27/2010

Since posting the original article I've made numerous changes to some of the views and I've also implemented a couple of new views, all of which are included below. But first, allow me to make a few obvious but none the less important observations about application development in general.

One of the keys to successful development IMHO is the constant refinement of concepts and ideas. No matter how good a first implementation is there is always room for improvement. As concepts and ideas materialize and as the complexity of the application increases it is very important to review your implementations frequently, looking for ways to improve them. In addition, as development progresses you can sometimes find that you need to reuse an implementation but in its current state it is tightly bound to a single point of use.

IDE refactoring support makes this repetitive cycle of coding and refinement manageable and Eclipse, my preferred choice of IDE, shines in this area saving me literally hours compared to what it would have taken me to manually make all the modifications up to this point.

So, if your current IDE doesn't shine in its refactoring support look to upgrade to a better IDE. JetBrains, Eclipse and Netbeans all provide excellent support for refactoring code and of the 3 only JetBrains requires a paid license for non open source projects.

With that little tidbit out of the way here are the screen shots I promised:

Screen shots of modified views from early prototype

Screen shots of recently added views from early prototype

Updated 12/5/2010

Since my last update I've done a lot more refactoring, made some improvements and changes to the the existing views, implemented the Parts, Fluids and Suppliers views and I've added one new view, Notifications, to the Manage sub menu. The data displayed in the following screen shots is bogus of course and is for testing purposes only, mainly to verify that my sorting routines are working correctly. Screen shots follow:

Updated 12/19/2010

Complex Web 2.0 pages are highly dynamic and require a lot of DOM manipulation for adding, removing, hiding and showing page elements in response to the user's actions; that's how they mimic desktop applications providing a similar rich user experience.

Love My Vehicle's Misc. Purchases View is one such example of a complex, highly dynamic page that responds to the user's actions by manipulating the DOM accordingly. The view supports the display of a document non editing view of a purchase which has numerous areas on which the user can click on to manipulate such purchase related items as purchase line items and sales tax.

For example, when the user clicks the Add Purchase Item button DOM manipulation is used to display an editor that allows the input of a purchase item. The user can save their input by clicking the editor's Save Purchase Item button or they can cancel the operation by clicking the editor's Cancel button. If they click the Save Purchase Item button the information they entered is first validated and if it is valid the DOM is again manipulated to display a document non editing view of the line item entry. If the information fails validation then the line item editor displays an error message which provides feedback to the user prompting them to correct the data.

The same line item editor also supports editing of an existing purchase line item which would be the case if the user is editing an existing purchase or a line item they previously entered in a new purchase.

Sales tax works similarly to the purchase line item editor supporting both a document non editing view and an editing view.

Whenever the users saves their data in either the line item editor or the sales tax editor the page recalculates the net and gross amounts for the purchase.

In the coming weeks I intend to publish an article dedicated to my approach to developing these types of highly dynamic pages and of course I will focus on using GWT to implement them. It is possible that this will be a multi part article as the topic requires a lot of detail and I think would be easier to consume if it wasn't all tossed out at you at one time.

I have added some screen shots below of the views that I described above as well as a screen shot of the Purchase view which shows a list of all purchases as well as showing a document view of the selected purchase.

I hope you have found this latest update interesting and as always, feel free to provide your feedback.

Have a very happy holiday and new year.

Updated 12/19/2010

In real life one rarely gets the opportunity to do things over but software development is an exception. After implementing the Purchase views I realized that I had failed to provide the user with a report view of a purchase. What do I mean when I say a report view? A report view is any view of data that when viewed looks like a well laid out report and as close to the real life document that it is supposed to represent. An invoice is an example of a report view with a header, line items, and a summary. A purchase is also an example and is very similar to an invoice in that it also has a header, line items and a summary.

Business applications, which Love My Vehicle really is when you get down to it, usually have to provide a lot of report views and implementing them is often time consuming because of the detail required to get the views to look like real documents. I made two passes at implementing the Purchase report view, one using a div only approach and one using tables. In the end I chose the tables approach because it was more straight forward and it allowed me to use GWT's excellent support for table row and cell generation.

The following is a screen shot of a Purchase report view. Besides providing the user with a report view of what a Purchase document should look like, it also provides the user with the ability to edit and delete the backing purchase data:

"Hey Larry"

2010-02-03T10:41:00.010-05:00

As you probably know, Oracle has begun its consolidation of the assets it has obtained from its purchase of Sun Microsystems. Yesterday I received an email notifying me that Oracle has pulled the plug on Kenai.com. You can interpret this as you see fit but in my opinion this is a mistake for a number of reasons, not least of which is the message it sends to developers.

So "Hey Larry" will be my channel for commenting on both the good and the not so good steps that Oracle takes in regard to those Sun assets which we developers have come to rely on. To start things off, here's the first "Hey Larry" entry...

02/03/2010

Hey Larry,
I just heard that you are shutting down Kenai.com. Why? You don't think it is an asset for developers to have a Kenai.com service as a resource? You don't value the good will a resource like Kenai.com generates with your developer community? What else are you going to "shutdown"? Netbeans, MySql, Java, OpenOffice.org, etc.? I was enthusiastic about the Oracle/Sun deal but I feared something like this would result. I guess my fears were justified. Hey Larry ... don't be a jerk with your developer community. It might come back to haunt ya!

02/04/2010

Hey Larry,
I like what I heard in this web cast, especially what you are promising for Netbeans and Netbeans.org. Keeping the Netbeans devevelopment team intact is smart as is sharing between the 3 IDE platform groups

02/07/2010

Hey Larry,

I just read your clarification regarding your plans for Kenai.com (see below) which I received yesterday. This will, I am sure, be very well received by your developer community. I can hear their collective sigh of relief. It doesn't matter why the 180 on Kenai.com but my naturally curious nature tells me that the negative reaction to your original announcement played 'something' of a role. That you listened and reevaluated and came to what can only be called a very smart decision demonstrates a resolve to embrace your developer community. Good move!

Gentlepeople,

In an effort to get information out to the Kenai community quickly, while trying to manage the integration of our two companies, I think we did a poor job at communicating our plans for Kenai.com to you. I would like to remedy that now.

Our strategy is simple. We don't believe it makes sense to continue investing in multiple hosted development sites that are basically doing the same thing. Our plan is to shut down kenai.com and focus our efforts on java.net as the hosted development community.

We are in the process of migrating java.net to the kenai technology. This means that any project currently hosted on kenai.com will be able to continue as you are on java.net. We are still working out the technical details, but the goal is to make this migration as seamless as possible for the current kenai.com projects.

So in the meantime I suggest that you stay put on kenai.com and let us work through the details and get back to you later this month.

Thanks for your feedback and patience.

-Ted Farrell
Oracle Corporation

02/15/2010
Hey Larry,
Congratulations on winning back America's Cup. Outstanding!

Grails On The Google's App Engine - Grope... bump... ouch!

2010-01-09T12:08:00.004-05:00

I thought I'd comment on some of my experiences using Grails on Google's App Engine. I am new to the App Engine and it is quite different from the typical environment provided by Java web servers. For example, it only provides limited Java support and there is no SQL database, only BigTable. Poor or missing documentation just compounds the difficulty. It is like feeling your way around in the dark - there are a lot of things you are going to bump in to. So occasionally I will update my 'bumps' here and maybe save you some of the bruises.

Yesterday, for example, I hit a snag building an application running the grails command app-engine. This was a new problem. The app had been built and run successfully prior to this. The only difference is that I added a new domain class, a new controller and a few new views to support the new domain class to the project. The ant task that the Google App Engine SDK provides in the file config\user\ant-macros.xml was blowing up in the Datanucleus Enhancement phase because the parameter it created to feed to the enhancer included all the classes in the war and its length exceeded the max path length allowed by Windows. I finally got around the problem by modifying the ant script to only include the application's domain objects and I was able to build and run the project again. The problem here is that this isn't documented and it literally took me hours to find a blog post that provided the solution.

By the way, my environment is set up to use Grails 1.1.1 and not the latest 1.2 because the app-engine plugin doesn't yet support it. I am using GORM-Jpa as well.

GORM-Jpa plugin is another point of frustration. It claims to provide dynamic finder support but in reality it only provides a very limited subset. The experience of determining what finders it actually supports is again like groping around in the dark. What I have learned so far is to limit my queries with .findWhere queries which suffice for a majority of my queries. For fringe cases I have also resorted to JPQL which I was happy to find that GORM-Jpa supports. These take the form of <DomainObject>.findAll("SELECT o FROM <DomainObject> o WHERE o.x like :search",[search:'a%'] as an example. Again, no documentation and this discovery took considerable trial and error until I got it to work.

Developing for the App Engine with Grails is very fragile. A lot of things that you just take for granted in Grails just do not work or work differently. This is in part due to the immaturity of the Java App Engine api as well as Grails App Engine support. I hope to see both mature rapidly :) And thank heavens for Netbeans' Grails support. I'd have gotten nowhere fast if it weren't for Netbeans' ability to debug Grails apps.

So, if you have any gems you'd care to share on Grails on Google App Engine please do it here. It might save me and many others some bruises as well. And, likewise, I will share with you what I learn as I grope my way around in the darkness of Grails and Google App Engine.

Grope... bump... ouch! Grope... bump... ouch! ...

2/16/2010 Update

I probably should have posted this sooner but I have given up with Grail on AppEngine and switched to Gaelyk which was purposely designed to be light weight and run on top of Google's AppEngine. It doesn't have all the bells and wistles that Grails has but you really don't need them for AppEngine. JDO/JPA just gets in the way and really doesn't fit with the BigTable database so why use it. Gaelyk comes with some very nice wrappers for Google's cloud apis and are extremely easy to work with. Startup times for Grails apps on AppEngine are horrendous and unacceptable whereas Gaelyk apps don't suffer the same startup latency. And the best thing about Gaelyk is that it is Groovy which means you still have access to litterally thousands of open source libraries at your disposal. Grails on AppEngine is like trying to run a Rolls Royce in a Nascar race where Gaelyk on AppEngine is like a speedy agile little sports car. Gaelyk support is fantastic. Guillaume Laforge, who is the Groovy project manager and head of groovy development at SpringSource is one of Gaelyk's primary developers. He is very committed to the project and I have found him to be extremely responsive to emails posted on the Gaelyk users group.

So the bottom lines my friends is this, if you are writing an app for a typical servelet environment then go with Grails. It is a fabulous framework. But forget about it on AppEngine, it just doesn't fit.

UIComposer On Project Kenai

2009-12-26T13:44:00.009-05:00

UIComposer v0.4a Now On Project Kenai

I have created a new project on Project Kenai to house UIComposer which is currently at version 0.4a.

UIComposer is a Wicket custom control that provides similar functionality as Facebook's "What's On Your Mind" page widget. It is composed of an optional image which can be associated with a link, a data entry field for user input and a button that posts the user's data back to the server using AJAX.

UIComposer comes in many flavors but using it in your applications is easy. All its resources and dependencies are fully self contained. So adding UIComposer is as simple as adding its lib to your project, importing it into your source files and creating the control:

import UIComposer.Wicket.Component.UICompositeWithImage;
.
.
.
add(new UICompositeWithImage("uicomposite", "What's on your mind?") {
.
.
.

UIComposer's use of abstract methods allow tailoring the controls' behavior at run time making it suitable in situations that are specific to each application.

Access to the project's source code is available using Subversion at the following url:

https://svn.kenai.com/svn/uicomposer~subversion

Anonymous access to the repository is allowed but if you aren't already I would recommend you create your own account on Project Kenai to reap the greatest benefit as it affords many resources to developers.

Included in the distrobution is a Wicket application, UIComposerTestApp, for testing its various flavors and ways of using UIComposer.

You will need to install Subversion on your system in order to obtain the UIComposer source code.

If you use Netbeans then you are in luck. Netbeans has excellent integration with Subversion and Project Kenai. In Netbeans, once you are logged in to Project Kenai, you can effortlessly download the project directly into Netbeans, all without leaving the Netbeans IDE.

Please down load UIComposer. Play with it! Try to break it! Provide lots of feedback! Bug tracking is supported via Jira which is accessible from the project's home page on Project Kenai. The more feedback the better UIComposer will be.

Currently UIComposer is covered under the GPL-2.0 source license. I am entertaining loosening the licensing restrictions with the lesser version of GPL but only after considerable thought has been given to doing so.

In the new year I will contribute numerous articles that deal with creating custom Wicket components and UIComposer will serve as an example for many of them. But UIComposer is more than a tool for future articles, it is my contribution to the Wicket community. I hope users of the Wicket framework who need the features that UIComposer provides will take advantage of it, work with me and provide their feedback.

Oh, and one more thing, that mug in the picture at the top of the page is mine :)

Jeff

Some Musings About This Year & Next

2009-12-24T09:48:00.011-05:00

Oracle's pending purchase of Sun seems appropriate in the sense that it seems to add to the year end anxiety. Oracle will, I imagine, be able to alleviate the EEC's concern over MySql and will eventually see the EEC approve the deal. But developers have their concerns about where that will leave Netbeans, the free and open source Java IDE and rich client platform. Hopefully, Oracle will fully embrace Netbeans and provide the assets that are needed to move Netbeans along. And there is much to do.

Recently released Netbeans v6.8 has lots of new features. It is very good but at times it is too memory hungry and brings my HP laptop (Vista OS with 2 gigs of memory) to its knees. The project scanning/indexing issue seems to have reappeared in this release for who knows why. Current support for Groovy and Grails, which I believe will see a tremendous growth in the coming year, is nowhere near where it could be. Intellij Idea, for example, really shines here and sets the bar that Netbeans will have to aim for in the coming year if it wants to attract and keep Groovy and Grails developers. The Zend framework needs to be among the PHP frameworks that are supported and Wicket support needs to be folded into Netbeans.

Wicket has seen much improvement in 2009 and I am confident that it will continue to do so in 2010. Its developers are top-notch and its developer community is alive and well. Hopefully, the new year will see improved support for Java EE/EJB along the same lines that Wicket currently has for Spring.

Cloud computing became a reality in 2009 and should see healthy adoption in 2010.

Apparently the Intype editor project isn't dead after all and its developers seem to have a renewed determination towards putting out a new release. For all of us who have wished for a TextMate like editor for Windows, well we seem to be a few steps closer to that end.

In the few remaining days of 2009 I will place my custom Wicket component on Project Kenai which will serve as the subject for numerous future articles. I am very excited about this. I was going to postpone putting the project on Kenai because it needs some minor refactoring and there is one api that I haven't even touched on yet. After some thought, though, I decided that it was more important to get it out there, that the remaining tasks should be visible and hopefully will attract developers' input and contributions to the project.

And, finally, a voice on the radio just told me that this was the most dangerous time of the year for people to experience heart problems. I imagine this year will be even more severe than most due to the state of the economy and the prospect of a long and protracted recovery. Hopefully, those who found themselves struggling in 2009 will see better things coming their way during the coming year.

A very happy holiday and new year to you all.

Jeff

Improving Wicket's Support for Java EE5 Applications

2009-08-29T12:35:00.006-04:00

I am a huge fan of the Wicket Web framework. Wicket has made Web application development fun again for me and for many other developers by greatly lowering the impedance mismatch that exists between HTTP and the Java language. As perfect as Wicket is, though, it could use some improvement in its ability to support Java EE5 based applications. So here I offer my take on what I believe can be done to make Wicket an even better framework. Currently Wicket's support for Java EE5 applications is provided by wicket-contrib-javaee. By adding this add-on to your Wicket application you can reference the functionality exposed by any EJB simply by using the @EJB annotation and adding a few lines of initialization code to the Wicket WebApplication class. However, some developers who have worked with this add-on have voiced concerns about it causing problems in their applications. At the same time, the support behind this add-on appears to be somewhat questionable. This is an unfortunate state of affairs but one which could be rectified if the functionality provided by it was instead folded into the core Wicket distribution. This should not be seen as an endorsement of EE but rather as a recognition that there is a significant interest to employ Wicket in EE applications. This recognition would be similar to that which has already been given to Spring and Guice by having included their interfacing libraries as part of Wicket's core distribution. Such an adaption could result in a greater acceptance of Wicket in environments where EE is the chosen platform for Enterprise applications. In conjunction with this I would also suggest that the next edition of the marvelous Wicket In Action book include a new chapter dedicated to showing just how easy it is to create this type of application. I would gladly contribute it myself if I were asked :) Sincerely, Jeff

Coming Soon - An Article About Developing Custom Ajax Enabled Wicket Components

2009-08-28T17:06:00.004-04:00

As I have been very busy looking for full-time work I haven't had time to devote to writing my next article. I've got 5 cats to feed and they eat a lot so I better land a job soon or I might wind up eating my 5 cats LOL. Anyway, I gave it a lot of thought and my next article will be about developing custom Ajax enabled Wicket components. The component that I will create in the tutorial will be similar to the What's On Your Mind component seen on Facebook pages. In the process I will demonstrate how Wicket makes developing this type of component almost trivial. Sincerely, Jeff

Wicket, A Stateful Web Framework

2009-07-17T06:59:00.037-04:00

HTTP Is Stateless Desktop application programmers as well as programmers developing in a traditional multi-user, client/server environment don't normally have to worry about maintaining the state of an application's objects. After all, programming languages like C, C++, Java and C# have built-in mechanisms that maintain a variable's state during the lifetime of the application, insuring that the value of a variable is maintained and that it is 'reachable' upon referencing that variable. The stateless nature of HTTP, however, creates artificial workflows for web applications that do not exist in applications developed for the desktop or for a traditional multi-user, client/server environment. Because HTTP doesn't persist an application's state across multiple HTTP requests means that application servers and frameworks have to provide some mechanisms to allow the programmer to do this. A common method uses hash tables that are stored to physical memory or to a database or file system at the end of processing an HTTP requests. The ability to persist these values so that they can be read back when the next HTTP request hits the server for the same client session provides the glue or the narrative thread that web applications need in order to bind the multiple HTTP requests into something that simulates an unbroken (broken by HTTP request boundaries) and contiguous workflow. Managing this session state is the responsibility of the application programmer. Every application and workflow imposes its own requirements as to what and when something is required to be persisted and herein lies the problem: getting this right 100% of the time is often the most difficult challenge a developer faces when developing a web application that is maintainable, responsive and scalable. To make matters worse, the difficulty grows proportionately as the application grows in complexity and as more maintenance is done. With tight schedules and dwindling budgets there is often no time to thoroughly conduct a regression test to ensure that new bugs aren't being introduced. My own experiences working on web applications have led me to believe that this isn't the best approach to dealing with the stateless nature of HTTP and that there has to be a better way. I have spent far too many nights and weekends debugging and fixing problems related to changes made to application logic and the subsequent mismanagement of session state needed to support the work flows across multiple HTTP requests to think that this is an optimal solution. Using The Session Hash Table Perhaps now is a good time to provide an example of how hash table based session state frameworks attempt to overcome the stateless nature of HTTP and the types of problems that are associated with this technique. I will juxtapose Wicket's approach to handling this after. Lets consider what appears on the surface to be a rather simple scenario, that of maintaining and displaying a counter whose value represents the number of times the web page is processed on the server and rendered in the browser. When the user requests the web page for the first time it should be rendered displaying a value of 1 for the counter. When the user clicks the button on the web page the browser should issue a get request back to the server. The application running on the server should process the get request by incrementing the counter and rendering the page back to the browser displaying the current value of the counter. The web page itself is simple and looks like the following: The first time the user requests the page it will be rendered in the browser with a value of 1 for the counter. Each subsequent click of the button whose label is 'Click Here' will result in the browser issueing a get back to the server and the page being rendered to the browser with an incremented counter. The image below shows what the page would look like after being rendered for the second time: Notice how the counter's value in the above image is 2. This is in response to it having been incremented on the server. So what does it take code-wise on the server to provide this functionality? Using a web framework such as ASP.DotNet and ASPX Web Forms, the object associated with an aspx page would be created in response to the HTTP request and the object's load method would be called in which it would retrieve the value from the session state hash table using a string value to identify the value. It would then convert the value to an integer, increment the value by 1, convert the value back to a string, assign the value to the label on the web page, save the value to the session hash and lastly render the page back to the browser. But wait! What would happen if this is the first time the page is processing? If you didn't compensate for this and have an alternate branch of logic the named value wouldn't exist in the session hash table and the program would abort because it was attempting to manipulate a null string reference. But wait! Couldn't you instead, you ask, store the value in a field of the aspx page object and just increment it every time it processes the request? The answer is no because ASP.DotNet like many other frameworks does not persist the state of the objects that represent web pages and HTML controls on the server between HTTP requests. Instead, ASP.DotNet as do many other frameworks instantiates the object associated with the web page every time a new request arrives. Instantiation of the object causes the object's fields to be assigned their initial values according to the object constructor or to their appropriate default initial values based on their variable types. While this is a trivial example, it isn't hard to see how this way of dealing with persisting state between HTTP requests can quickly snowball out of control. Now imagine that there is a web framework out there that actually does persist the objects associated with web pages and HTML controls across HTTP requests. Suddenly, schemes such as having to save application state in hash tables and persist them across HTTP requests are no longer necessary. Now your favorite object oriented programming language behaves almost the same way in web applications as it does in desktop or client-server applications. Imagine that the fact that the web application is running in a stateless HTTP environment is hidden from the developer and the framework takes care of persisting and restoring the objects associated with your application's web pages and HTML controls for you. Enter Wicket, Simply Eloquent and Eloquently Simple Well, you are not left to your imagination because there actually is a web application framework that does this and a whole lot more for you. It is the Java based Apache Wicket web framework. Using the example from above, here is the actual code written to the Wicket web framework that renders the web page pictured above: That's it. Nowhere is there code to save or retrieve string values from a session based hash table. Nor are there alternate paths of logic needed to differentiate processing that should happen the first time a web page is being requested from all other requests. There is just "normal" Java code - i is initialized in the HomePage constructor and i is incremented in response to the button's onClick method. The current value of i is rendered back to the browser in response to each request. This style will seem very familiar to those who have coded Java SE Swing based applications or to anyone who has coded desktop applications using other programming languages such as C# or even Basic. And if you are thinking that there must be some magic happening in the HTML page well there isn't and here it is: Nothing but pure HTML. Wicket is a Model/View/Controller based framework. HTML pages never mix markup with code. They are strictly the 'view' part of the MVC equation. The actual magic is happening behind the scenes and within the Wicket framework's request cycle processing which is responsible for persisting the HomePage object at the end of each request cycle and restoring it at the start of each request cycle. This is completely transparent to the application developer who can just assume that objects behave like... objects. Wicket hides the stateless nature of HTTP and enables coding web applications like one would code non web applications. Of course the developer must exercise sound judgment when deciding what and how much to persist in the objects associated with Wicket web pages and HTML controls. Persisting a list of 100,000 database records, for instance, for thousands of concurrent users is wasteful and could cause severe degradation or even cause the server to fail altogether. For instance, persisting a database table row's unique identity in a web page object is preferable to persisting the actual row of data since the database itself already serves as the underlying cache for the data. Having the identity of the row of data is enough to allow the data to be retrieved through a query to the database when and if it is needed. Wicket also provides a model architecture that promotes this type of resource usage. Wicket's LoadableDetachableModel class provides the developer with the ability to persist only the minimum amount of information across HTTP requests - such as a data row's identity value - which can be used to query the database for the actual data when and if it is needed and released at the end of the request. Summary The Apache Wicket web framework eliminates one of the greatest challenges faced by developers of web applications, the dreaded persistence problem caused by the stateless nature of HTTP. Wicket also provides numerous other advantages to developers of web application, some of which I have already written about and which you can read here in my blog. I hope you have enjoyed reading this article as much as I have enjoyed presenting it to you. And as always, please feel free to leave your comments.

Wicket + EJB + DI With Netbeans - Part 3

2009-05-21T09:00:00.028-04:00

Part 3 - Using The @EJB Annotation To Provide Dependency Injection Support In The Web Tier And Consuming The Services Provided By Their Backing EJBs For this last part of the tutorial I am going to demonstrate how to use Wicket in an EE container environment such as Glassfish. wicket-contrib-javaee is a wicket module that provides integration through Java EE 5 resource injection. With wicket-contrib-javaee you can use the following 3 annotations in your wicket pages:

@EJB
@PersistenceUnit
@Resource

In particular, I will demonstrate how to use the @EJB annotation for dependency injection of the CustomerFacade ejb that was developed in Part 2 of this tutorial. Adding wicket-contrib-javaee-1.1.jar Begin by downloading the wicket-contrib-javaee-1.1.jar which can be found here on SOURCEFORGE.NET. Once you have downloaded the jar and saved it locally it then needs to be added to the WicketEETutorial1-war module:

Right click the Libraries node and select Add Jar/Folder. This will open the Add Jar/Folder window.
Navigate to the location where you saved the wicket-contrib-javaee-1.1.jar file and select it. Make sure that the Copy To Libraries Folder option is selected.
Click Open and Netbeans will add the jar file to the module.

Now we need to add the wicket-ioc jar to the module. wicket-ioc.jar is included with the wicket distribution which we downloaded in Part 1 of this tutorial. Adding wicket-ioc jar

Right click the Libraries node and select Add Jar/Folder. This will open the Add Jar/Folder window.
Navigate to the location where you saved the wicket distribution that we downloaded in Part 1 of this tutorial. In the lib folder select the wicket-ioc jar file. Make sure that the Copy To Libraries Folder option is selected.
Click Open and Netbeans will add the jar file to the module.

The wicket-ioc jar has a dependency on cglib jar so we need to include that in the module as well. Adding cglib jar The cglib jar is hosted on SourceForge and you can download it from here. Once you have downloaded the jar and saved it locally it then needs to be added to the WicketEETutorial1-war module:

Right click the Libraries node and select Add Jar/Folder. This will open the Add Jar/Folder window.
Navigate to the location where you saved the cglib jar file and select it. Make sure that the Copy To Libraries Folder option is selected.
Click Open and Netbeans will add the jar file to the module.

The web.xml file needs to be modified to include a reference to the CustomerFacade ejb. Adding A Reference In web.xml To CustomerFacade EJB In the Projects pane expand the Configuration Files node and double click the web.xml file to open it in the editor and click on the References tab.

Expand the EJB References panel and click the Add button. This will open the Add EJB Reference window.
Enter WicketEETutorial1-ejb/CustomerFacade for the EJB Reference Name.
Select Session for the EJB Type.
Select Local for Interface Type.
Enter ejbs.CustomerFacadeLocal for the Local Interface.
Click the OK button to save the changes to the web.xml file.

Now we need to override the init method in Application.java. Modifying Application.java Open the Application.java file and add the following code: @Override protected void init() { super.init(); addComponentInstantiationListener((IComponentInstantiationListener) new JavaEEComponentInjector(this)); } Right click in the editor and select Fix Imports to add the needed import statements. Application.java file should now look like the following:Now we need to modify HomePage.java where we wiill include the @EJB annotation for the CustomerFacade ejb and consume its services. Adding The @EJB Annotation Open HomePage.java in the editor and add the following to the HomePage class definition: @EJB(name="WicketEETutorial1-ejb/CustomerFacade") private CustomerFacadeLocal customerEjb; *** Note that the name we are providing for the @EJB annotation is the same one we used when we added the EJB reference to the web.xml file. Now everything is in place for us to actually consume the data access services that are provided by the CustomerFacade ejb so lets add some more code to the HomePage constructor to get a list of Customer entities and get a count of how many entities there are in the list. Consuming The Data Access Services Provided By The CustomerFacade ejb Modify the HomePage constructor so that it looks exactly like the following: public HomePage() { add(new Label("sayhello","Hello, World!")); List customers = customerEjb.findAll(); int count = customers.size(); add(new Label("customercount",String.valueOf(count))); } Right click the editor and select Fix Imports to add the needed import statements. Your HomePage.java file should now look like the following; Open HomePage.html in the editor and modify its markup so that it looks exactly like the following; We have added a Wicket component that will display the number of Customer entities in the list of Customers returned from calling the findAll method of the CustomerFacade ejb. We are now ready to build and run our application. Running Our Application Rick click the WicketEETutorial1 node in the Projects pane and select Run to build and run the application. Your browser should open and render the following; As you can see from the above image, we were able to obtain a reference to the CustomerFacade ejb via the use of the @EJB annotation and call the findAll method which the CustomerFacade ejb exposes. findAll returned a list of Customer entities and from the list we were able to obtain a count of Customer entities. Summary Netbeans greatly simplifies the whole process of generating the Enterprise Application's modules. Netbeans wizards generate a lot of code that we would otherwise have to hand code ourselves. To a very large degree Netbeans trivializes Java EE5 applications allowing us to focus on the domain issues of the application and not its plumbing and wiring. Who said Java EE was too heavy and complex? I hope this tutorial demonstrated that neither is true. With the addition of the wicket-contrib-javaee jar file, Wicket applications gain the ability to use Java EE5 annotations that allow it to take full advantage of services esxposed in enterprise java beans when running in a Java EE5 container such as the one Glassfish provides. All in all, very cool, isn't it? And easy, too!And how cool is it to be able to use Wicket as the web framework in a Java EE application and have it be able to consume services exposed through ejbs using standard Java EE annotations? Though this application was trivial by design so as to keep it simple for demonstration purposes, the principles demonstrated here will work for applications of much greater size and complexity. Conclusion This concludes the tutorial and I hope you had as much fun following along as I had presenting it. Please feel free to provide your comments. I look forward to hearing from you.

Wicket + EJB + DI With Netbeans - Part 2

2009-05-18T12:26:00.028-04:00

Part 2 - Creating Entity Classes That Map To An Existing Database And Exposing Data Access Services Through EJBs With Netbeans For this part of the tutorial I am going to use the Sample database that comes with the Java DB which should have been installed when you installed Netbeans and Glassfish. You can verify that the Sample database is recognized by Netbeans by expanding the Database node in the Services pane where you should see a connection listed there that looks like the highlighted one below. If you fully expand the connection node you can see that there are a number of tables already defined. For this tutorial we want to create one entity class for the Customer table. However, we will not have to hand code this entity class because Netbeans has excellent tooling support for generating entity classes that map to tables in a database. Creating Our Customer Entity Class Please follow these steps to create the Customer entity class for the Customer table in the Sample database:

In the Projects pane right click the WicketEETutorial1-ejb module node and select New|Other from the context menu. This will open the New File window. In the Categories pane select Persistence and in the File Types pane select Entity Classes From Database and click Next.
Expand the Data Source drop-down menu in the Data Tables Pane and select the jdbc/sample option. Netbeans will fill the Available Tables list with all the tables defined in the Sample DB.
Uncheck the Include Related Tables option.
Select the CUSTOMER table from the list of Available Tables.
Click the Add button and then click Next.
Enter entities as the package name in the Package field and the click the Create Persistence Unit button. In the Create Persistence Unit window accept all the defaults and click the Create button. Now click the Next button.
In the Mapping Options pane select java.util.List for the Collection Type and click the Finish button.

Upon completing the above steps, Netbeans will create the Customer entity class and place it in the entities package. Netbeans will also generate the persistence.xml file and place it under the Configuration Files tab. With our entity class and persistence unit file created we can now go on and encapsulate our database access code in EJBs. Like our entity class we will not have to hand code our database access code. Netbeans has excellent tooling support for generating database access code that map to existing entity classes. Creating Our Customer Data Access EJB Please follow these steps to create the EJB that will encapsulate the database access code:

In the Projects pane right click the WicketEETutorial1-ejb module node and select New|Other from the context menu. This will open the New File window. In the Categories pane select Persistence and in the File Types pane select Session Beans For Entity Classes and click Next. As you can see, Netbeans has filled the Available Entity Classes list with the Customer entity class we created.
Select the Customer entity in the list of Available Entity Classes.
Click the Add buttom and then click the Next button.
In the Generated Session Beans pane enter ejbs for the package name. We want to create a local interface so make sure the Local checkbox is checked.
Now click the Finish button.

Upon completing the above steps, Netbeans will create the local interface and implementation class files for the Customer entity that we selected and place these files in the ejbs package. Summary This concludes Part 2 of the tutorial. As you can see, Netbeans greatly simplifies coding the service tear in an Enterprise Application. We have taken advantage of the tooling available in Netbeans to generate our Customer entity class, persistence.xml and CustomerFacade EJB class files for us. In the next part of this tutorial, Part 3, we will expand the web tier to consume the services exposed by the CustomerFacade EJB that we have just created.

Wicket + EJB + DI With Netbeans - Part 1

2009-05-06T12:39:00.085-04:00

Introduction This 3 part tutorial demonstrates how easy it is to create a Java EE5 Enterprise Application with Netbeans. The Web tier of the Enterprise Application will be based on the Wicket Web framework and the services tier -- the EJBs (Enterprise Java Beans) -- will serve up data from a database which will be consumed by the Web tier. In particular, it demonstrates how easy it is for the Web tier to consume the services exposed by EJBs and to manage references to the EJBs through DI (dependency injection) using the @EJB annotation and the wicket-contrib-javaee jar library. The tutorial has 3 parts covered in 3 separate articles:

Part 1 will demonstrate creating the Enterprise Application in Netbeans and configuring the Web tier to use the latest build of the Wicket framework.
Part 2 will demonstrate creating entity classes that map to an existing database and exposing data access services through EJBs.
Part 3 will demonstrate using the @EJB annotation to provide dependency injection support in the Web tier and consuming the services provided by their backing EJBs.

At the conclusion of this 3 part tutorial we will have created a fully functional Wicket based Web application running in the Java EE5 container supplied by the Glassfish application server. The Web application will use standard Java EE5 based annotations such as @EJB to resolve references to EJBs at run time through the use of dependency injection. It is also my hope that this tutorial will serve to dispel the belief by many that the Java EE5 container is too heavy and complex to develop for. Part 1 - Creating A Java EE5 Enterprise Application With Netbeans Creating The Application Netbeans greatly simplifies the creation of Java EE5 based applications as the following demonstrates. Please follow these steps:

Open Netbeans.
Select File|New Project from the main menu. This will open the New Project window
In the Categories pane select Java EE and in the Projects pane select Enterprise Application and click Next.
Enter WicketEETutorial1 or any other name you chose for the Project Name as pictured below and click Next.
From the Server drop-down selection list select Glassfish v2 or better. Accept the other options' default settings as pictured below and click Finish.

As a result of completing the above, Netbeans will generate and open 3 module projects in the Projects pane as pictured below.The 3 modules and their associated projects that were generated for us are summarized below:

WicketEETutorial1 is an Enterprise Application module project and its ear (enterprise archive) file is what will be deployed to the server.
WicketEETutorial1-ejb is an EJB module project and it is here where we will define our entity classes and encapsulate our JPA data access code in EJBs (Enterprise Java Beans). This module will serve as our service layer tier and provide both domain and business functionality to our Web application. Its jar file is included in the ear file mentioned above.
WicketEETutorial1-war is a Web module project and it is here where we will define our presentation layer tier. Its war (web archive) file is included in the ear file mentioned above. As a default, Netbeans configures the web tier to serve up JSP pages. In the next step we will change this so that the web tier will use the Wicket web framework instead.

Configuring the Web tier to use Apache Wicket For this tutorial I am using the latest release candidate of the Wicket web framework which at the time of writing this was version 1.4-rc2 and which I downloaded from the Apache Wicket web site. A basic Wicket web application only needs the wicket-1.4-rc2.jar file so I added it to the module. Wicket has a dependency on the slf4j which is a logging API. I was able to download the SLF4J distribution from the SLF4J web site. This distribution also includes the jar file for log4j which is a popular logging implementation. I added 3 jar files from this distribution to the module. Now the web tier's Libraries node contains the following jars: To keep this part of the tutorial as simple as can be, the web application will for now only display the gratuitous Hello, World! In the web tier module I created the following source code package and 3 files: The contents of each of the above files is shown below: The web.xml file which is located under the Configuration Files tab in the Projects pane needs to be modified as well and should look exactly like the following highlighted text: As can be seen from the Home.html and Home.java files, the span element with the wicket:id of sayhello will have its contents replaced with Hello, World! Running The Application When we build and run the application the following is rendered in the browser:Summary This concludes Part 1 of the tutorial. As you can see, we have successfully created, built and run a Java EE5 Enterprise Application with a web tier using the Wicket web framework. The application as it now stands is trivial as it only displays the ubiquitous Hello, World! In the next part of this tutorial, Part 2, we will expand on the service side (the EJBs) and in Part 3, we will expand the web tier to consume the services exposed by the EJBs.

Will We Ever See Netbeans v7?

2009-04-29T08:26:00.008-04:00

With Oracle's acquisition of Sun Microsystems the big question in my mind and those of many dedicated Netbeans users is what will happen to the Netbeans IDE platform? Will we ever see a release of Netbeans v7? While the release of Netbeans v6.7 is highly anticipated, its development was begun under the auspices of Sun, who throughout the years has steadfastly committed itself to the platform. Will Oracle follow suit and provide the level of human, financial and organizational capital that will be required to take Netbeans to its next generation? I guess we will have to wait and see but I think you can guess what I am hoping.

JPA/Hibernate and Wicket Repeating Views with Netbeans- Part 2

2009-04-05T11:45:00.041-04:00

[***Note This is the second and final article in this series and requires that you have completed the exercises in the first article in this series. If you haven't already, please do so now before preceding with the exercises in this article.] This is the second and final article in this series of using JPA/Hibernate and Wicket repeating views. This article will cover the remaining tasks that will allow us to render the the data from the Customer table in a tabular view to the browser using Apache Wicket repeating views and models. Wicket's Repeating Views Wicket's repeating views allow you to render data from a collection of objects, such as a List. HTML tables can be used to display the information in the browser where each row in the table represents one item in the List collection and columns in the table represent each List item's fields. The markup we want to generate for this exercise is an HTML table with the following elements:

A table header with header columns for each of the columns from the Customer table that we want to display. For our exercise, we will display the Customer ID, Customer Discount Code, Customer Zip, and Customer Name columns from the Customer table.
A table row for each of the Customer entities returned when we query the Customer table for its contents. The cells in these rows will contain data from their corresponding fields in the Customer entity objects that are returned when we query the Customer table. Their corresponding fields are customerId, discountCode, zip, and name.

[***Note Because there is a one-to-many relationship between the Customer entity and the DiscountCode entity, the customer's discount code can be referenced through the Customer entity. We will see this later when we write the code to actually render the data to the browser.] Wicket provides numerous components that render content and markup to the browser. Among these are repeating view components that repetitively render the same markup but with varying content depending on the current item associated with the current view. The item associated with current view in our example is the current Customer entity from a List of Customer entities that we want to render. Models - IModel and IDetachable Wicket's components access data through models. This is the Model part in Wicket's Model View Controller implementation. Models are wrappers around data; they keep a reference to the data they are wrapping. Wicket provides numerous models such as Model, PropertyModel, CompoundPropertyModel, and LoadableDetachableModel to name a few. All models must implement the IModel interface, which publishes two methods:

T getObject() - returns and object of type T.
void setObject(T object) - set the model data to object of type T.

IModel also extends the IDetachable interface which publishes one method:

void detach() - detaches the model data and is called after rendering has completed.

Wicket Is A Stateful Framework Wicket is a stateful web framework; at the end of a request, after the markup has been sent to the browser, Wicket stores the page, component hierarchy, and associated models (state) in the page store. Since models keep references to their data, data will also be stored if it hasn't been detached from the model first. In order for the data to be stored it must be serializeable. Detaching the data from a model reduces the memory overhead on the server and also allows models to be associated with data that isn't serializeable. LoadableDetachableModel Wicket provides an abstract implementation of a detachable model, LoadableDetachableModel. It is a model that can be serialized to the page store without its data; its reference to its data is declared as transient. It implements IModel and IDetachable. LoadableDetachableModel calls its load method when the view component it is attached to needs access to its data. This allows clients, which implement this method, to load the data it wraps from any data source, a database for instance. We will see an example of using the LoadableDetachableModel later in the exercise when we implement the code for the view. DataView The DataView is a repeating view component. It makes it very simple to populate a repeating view from a database. DataView's are constructed as follows:

protected DataView(String id, IDataProvider dataProvider)
protected DataView(String id, IDataProvider dataProvider, int itemsPerPage)

Both constructors take an id of String as their first parameter. Its value must be set to the wicket:id attribute of the HTML tag we are attaching the DataView component to. Both constructors take an IDataProvider as their second parameter. The IDataProvider acts as an interface between the database and the Dataview. itemsPerPage, an int, can be passed as a third parameter and is used when implementing pagination. For this article, we will use the first constructor, which takes only two parameters, an id and an IDataprovider. The IDataProvider Interface - a wrapper around data IDataProvier is really nothing more than a wrapper around a collection. It extends IDetachable and publishes three methods that must be implemented:

iterator(int first, int count) - Gets an iterator for the subset of total data.
model(T object - Callback used by the consumer of this data provider to wrap the object retrieved from the iterator(int, int) with a model (usually a detachable one).
size() - Gets the total number of items in the collection represented by the DataProvider.

Implementing an IDataProvider Below is the implementation of IDataProvieder that will be used by our DataView component: Let's discuss each of the methods in our implementation of IDataProvider:

iterator calls the CustomerJpaController's findCustomerEntities method with 2 parameters, count and first and will return an Iterator for the list of Customer objects that the findCustomerEntities method returns.
size calls the CustomerJpaController's getCustomerCount method to get the count of Customers and returns the result.
model creates and returns an anonymous LoadableDetachableModel object which wraps our Customer entity object which will be detached after rendering has completed.
detach has an empty implementation because we do not have any models directly associated with our implementation of IDataProvider that need to be detached.

We create an anonymous instance of the DataView component and add it to our HomePage as follows: There are a few things to notice in the above code:

We are attaching the DataView to an HTML element whose wicket:id is rows. We will discuss the HomePage.html markup later.
populateItem will be called by the DataView component for each Customer object provided by customerDataProvider.
We are using a CompoundPropertyModel to bind the fields in the the Customer object to the four Label components. The field in the Customer object is identified by the id we pass to each Label's constructor.
Because there is a 1 to many relationship between the Customer and the DiscountCode entity objects, we must use discountCode.discountCode to reference the discountCode field in the DiscountCode entity associated with the Custmoer entity.

Here is the complete code for HomePage.java: Here is the complete markup for HomePage.html. Notice how each of the wicket:id attribute values match the id values we passed to our DataView and four Labels : Add some styling to our page Lets add some styling to our page:

Right click the Web Pages node in the Projects pane and select New | Other which will open the New File window.
Select Web from the Categories pane and select Cascading Style Sheet from the File Types pane and click Next.
Enter style for the CSS File Name and click Finish which will open the style.css file in the editor.

Add the following styling attributes to the style.css file:Modify CustomerJpaController Lets modify the JPA query in the CustomerJpaController class to return our Customer entities in ascending CustomerId order:

Fully expand the Source Packages node in the Projects pane and double click the CustomerJpaController node. This will open the file in the editor.
Locate the findCustomerEntities(boolean all, int maxResults, int firstResult) method and add order by o.customerId to the JPA query string.

The complete code for the method should now look like the following: Now lets run the project. Run the project Run the project by right clicking the project node in the Projects pane and selecting Run which will open your browser and render the following:Summary

We create a Wicket DataView to render repeating data in an HTML table to the browser.
We implement an instance of IDataProvider to act as an interface between the database and the DataView.
Our implementation of IDataProvider's model method creates and returns a LoadableDetachable model.
We assign a CompoundPropertyModel to the view, wrapping the Customer object.
We create four Label components. Each is bound to a field in the Customer object. The field in the Customer object is identified by the id we pass to each Label's constructor.
We modified our JPA query to return our Customer entities in customerId order.

Well, that concludes our discussion of working with JPA/Hibernate and Wicket repeating views with Netbeans. Please note that you are not limited to using Hibernate as your persistence provider; the same principles we applied here will work with any JPA compatible persistence provider, such as EclipseLink. Similarly, these techniques will work with a number of database systems, such as MySql for example. In a future post, I will discuss what I believe to be is a more efficient, effective and easier method of working with JPA and Wicket. Using Netbeans v6.5 I will demonstrate how to create a Java EE5 enterprise application and create EJBs that provide back-end database services through dependency injection to a Wicket web application. Stay tuned!

JPA/Hibernate and Wicket Repeating Views with Netbeans- Part 1

2009-03-31T11:40:00.039-04:00

This is the first part in a multi-part series of articles that will teach you how to create Web applications that use the Apache Wicket Web framework and JPA/Hibernate. In particular, these articles will demonstrate the following:

Using Netbeans to create Mavan based Apache Wicket projects.
Using Netbeans to add and configure Hibernatea, a JPA comaptable Persistence provider to the project.
Render tabular data from a database to the browser using Apache Wicket repeating views and models.

At the end of this series of articles we will have created an Apache Wicket Web application that retrieves data from a database using JPA and Hibernate and formats the data in a tabular view in the browser using an Apache Wicket DataView control. This article, the first in this series, will cover the following topics:

Creating a Maven Apache Wicket Web project in Netbeans
Configuring the project to use JPA and Hibernate.
Adding the required libraries to the project using Maven
Mapping POJOs to Database tables using JPA support in Netbeans.
Creating a JPA utility class that adds CRUD capability using JPA support in Netbeans

***Note - There are numerous ways to configure the 3 layers (presentation, business, and domain) found in 3-tier Java applications. In this article we will employ a direct approach; we will use tight-coupling that binds our code directly to the JPA persistence service. In future articles we will explore using other methods such as Spring IOC (Inversion Of Control) and EJB (Enterprise Java Beans) to layer the different services in loosely coupled fashion. You will need the following to complete this exercise:

Netbeans v6.5 or greater
Maven Netbeans Plugin
Derby Sample Database which should have been installed when you downloaded and installed Netbeans

Creating a Maven Apache Wicket Web project in Netbeans To create the project that will serve as the foundation for the remainder of this series of artices, please review and follow the exercises in my previous article, Netbeans Maven Projects. This will give you a good overview of Maven, and creating an Apache Wicket Maven based project using Netbeans. Once you have completed creating the project, please start Netbeans and open the project. Remove the junit test files from the project Testing with junit is a good practice but we won't need to use it for this exercise, so we will remove the project's test classes. Instead of physically deleting them, however, we will use Netbeans' safe delete option to remove them from the project. Please follow these steps:

Completely expand the Test Packages node in the Projects pane and select both the Start.java and TestHomePage.java files
Right click and select Delete which will open the Delete window.
Click the Safely delete checkbox so that it is checked and then click the Refactor button. This will remove the 2 files from the project but will not delete them.

Adding JPA and Hibernate to the project Please follow these steps to add JPA and Hibernate to the project:

Right click the project node in the Projects pane and select New | Other. This will open the New File window. Now select Persistence from the Categories pane and Entity Classes from Database from the File Types pane as pictured below:
Click the Next button and in the Database connection drop down menu select the jdbc derby sample database. In the Available Tables list box select Customer an click the Add button which will then add the Customer and the Discount_Code tables to be included in the Selected Tables list box as pictured below:
Now click the Next button and in the Package text field enter Hibernate for the name of the Java package and then click the Create Persistence Unit button which will open the Create Persistence Unit window.
From the Persistence Library drop down menu please select Hibernate and then click the Create button which will close the Create Persistence Unit window.
Now click Next and Finish which will close the New Entity Classes from Database window.

As a result of the above steps, Netbeans has added numerous files to our project. If you fully expand Other Sources node in the Projects pane you will see that Netbeans has added the persistence.xml file to our project. This is the file that is used by JPA to cinfigure persistence at runtime. If you double click the persistence.xml file node it will open in the editor. In this file you can see that there is a Provider tag that specifies that we have chosen Hibernate as the persistence provider:

<provider>org.hibernate.ejb.HibernatePersistence</provider>

You can also see that there are 2 class tags which identify the Java classes that represent our business entity classes, Customer and DiscountCode:

<class>hibernate.Customer</class> <class>hibernate.DiscountCode</class>

In addition to the above tags, there are numerous property tags that are used to identify the database driver, username and password, connection url and cache provider. JPA uses these properties at run time as well to connect to the da. Please fully expand the libraries node in the Project pane and you will notice that the hibernate-3.2.5.ga.jar Hibernate library has been added to our project. Later, we will use Netbeans' Maven support to replace this library with a more recent version.

Please fully expand the Source Packages node in the Project pane. Notice that 2 Pojos, Customer.java and DiscountCode.java, our entity classes, have been added and are located in the hibernate package as pictured below:Double click each Pojo and they will open in Netbeans' Java editor window. Notice how each Pojo has numerous errors which we will now correct by adding libraries to our project using Netbeans' Maven support. Replacing and adding libraries to our project We need to replace and add a few libraries to our project. We will use Netbeans Maven support to do this. First, lets replace the hibernate-3.2.5.ga.jar with a more recent version. Right click the Libraries node in the Project pane and select Add Library. This will open the Add Library window, which will allow us to search for the most recent version of this library. Please follow these steps:

In the GroupId text box enter org.hibernate
In the ArtifactId text box press the space bar on your keyboard. This will open a list of all the Artifacts that are identified by the org.hibernate GroupId we entered.
From this list select Hibernate.
In the Version text box press the space bar on your keyboard. This will open a list of all the different versions that are available for this library.
Select 3.2.6.ga from the list.

The Add Library window should now appear as pictured below: Click the Ok button to close this window. We have replaced the hibernate-3.2.5.ga.jar with the hibernate-3.2.6.ga.jar and you can confirm this by expanding the Libraries node in the Project window. Next we need to add support JPA/Hibernate annotations. We will do this using the same procedure above by right clicking the Libraries pane in the Project window, selecting Add Library which will open the Add Library window, which will allow us to search for the most recent version of this library. Please follw these steps:

In the GroupId text box enter org.hibernate
In the ArtifactId text box press the space bar on your keyboard. This will open a list of all the Artifacts that are identified by the org.hibernate GroupId we entered.
From this list select hibernate-annotations.
In the Version text box press the space bar on your keyboard. This will open a list of all the different versions that are available for this library.
Select 3.4.0.GA from the list.

The Add Library window should now appear as pictured below: Click the Ok button to close this window. We have added the hibernate-annotations-3.4.0.GA.jar and you can confirm this by expanding the Libraries node in the Project window. Next we need to add support for Hibernate entity management. We will do this using the same procedure above by right clicking the Libraries pane in the Project window, selecting Add Library which will open the Add Library window, which will allow us to search for the most recent version of this library. Please follw these steps:

In the GroupId text box enter org.hibernate
In the ArtifactId text box press the space bar on your keyboard. This will open a list of all the Artifacts that are identified by the org.hibernate GroupId we entered.
From this list select hibernate-entitymanager.
In the Version text box press the space bar on your keyboard. This will open a list of all the different versions that are available for this library.
Select 3.4.0.GA from the list.

The Add Library window should now appear as pictured below: Click the Ok button to close this window. We have added the hibernate-entitymanager-3.4.0.GA.jar and you can confirm this by expanding the Libraries node in the Project window. Next we need to add javax.persistence support. We will do this using the same procedure above by right clicking the Libraries pane in the Project window, selecting Add Library which will open the Add Library window, which will allow us to search for the most recent version of this library. Please follw these steps:

In the GroupId text box enter javax.persistence
In the ArtifactId text box press the space bar on your keyboard. This will open a list of all the Artifacts that are identified by the org.hibernate GroupId we entered.
From this list select persistence-api.
In the Version text box press the space bar on your keyboard. This will open a list of all the different versions that are available for this library.
Select 1.0 from the list.

The Add Library window should now appear as pictured below: Click the Ok button to close this window. We have added the persistence-api-1.0.jar and you can confirm this by expanding the Libraries node in the Project window. Next we need to add Derby database driver support. We will do this using the same procedure above by right clicking the Libraries pane in the Project window, selecting Add Library which will open the Add Library window, which will allow us to search for the most recent version of this library. Please follw these steps:

In the GroupId text box enter org.apache.derby
In the ArtifactId text box press the space bar on your keyboard. This will open a list of all the Artifacts that are identified by the org.hibernate GroupId we entered.
From this list select derbyclient.
In the Version text box press the space bar on your keyboard. This will open a list of all the different versions that are available for this library.
Select 10.4.2.0 from the list.

The Add Library window should now appear as pictured below: Click the Ok button to close this window. We have added the derbyclient-10.4.2.0.jar and you can confirm this by expanding the Libraries node in the Project window. Next we need to add support for transactions. We will do this using the same procedure above by right clicking the Libraries pane in the Project window, selecting Add Library which will open the Add Library window, which will allow us to search for the most recent version of this library. Please follw these steps:

In the GroupId text box enter javax.transaction
In the ArtifactId text box press the space bar on your keyboard. This will open a list of all the Artifacts that are identified by the org.hibernate GroupId we entered.
From this list select jta.
In the Version text box press the space bar on your keyboard. This will open a list of all the different versions that are available for this library.
Select 1.1 from the list.

The Add Library window should now appear as pictured below: Click the Ok button to close this window. We have added the jta-1.1.jar and you can confirm this by expanding the Libraries node in the Project window. We have added all the libraries that we will need to run and test our project. Build the project by right clicking the project node in the Projects pane and select Build. Your project should build without any errors. Creating a JPA Controller Class A JPA Controller class provides methods that support CRUD operations. We could write this ourselves but we can have Netbeans generate this class for us. To do so, please follow these steps:

Right click the project node in the Project pane and select New | Other. This will open the New File window.
Select Persistence from the Categories pane and JPA Controller Classes from Entity Classes from the File Types pane and click Next.
Click Add All to add the 2 available entity classes to the list of selected entity classes and click Next.
Select hibernate from the Package drop down menu and then click Finish.

Netbeans has added the CustomerJPAController.java file to our hibernate package and created a new hibernate.exceptions package which contains numerous files for dealing with persistence exceptions that can occur. If you double click on the CustomerJPAController.java file in the hibernate package it will open in the Netbeans Java editor. Please take a few minutes to look at the code that was generated in this file. There are methods for your basic CRUD operations including transaction support. We will take advantage of the findCustomerEntities method to retrieve a list of Customer entities. Developing a testing strategy We need to test our project to prove the following:

We can connect to the sample Derby database.
We can query the Customer table to return all the rows.
We can get a list of Customer entities as a result from the query and the list contains the correct number of entities.

We can determine the correct number of Customer entities that should be returned by viewing the contents of the Customer table using Netbeans database support. Please follow these steps:

In the Services window, expand the Databases node and right click the jdbc derby sample database node and then select Connect to connect to the database.
Once the connection to the database is made, expand the Tables node, right click the Customer table and select View Data. This will open a SQL Command window.

In the SQL Command window you should see a result set containing all the rows in the Customer table, and the total number of rows returned should be indicated as well. When I run this it indicates that there are 13 rows of data but your results may be different. What is important is that we now know that our test should confirm the number that you see when you display the contents of the Customer table in the SQL Command window: Adding code to HomePage.java to test Now lets add the code to test our project. Please follow these steps:

Fully expand the Source Packages node in the Projects pane and double click the HomePage.java file which will open the file in the Netbeans Java editor window.
Add this method to the HomePage class: private void TestDatabase(){ CustomerJpaController custcont = new CustomerJpaController(); int i = custcont.findCustomerEntities().size(); System.out.println("custcont.findCustomerEntities() returned " + Integer.valueOf(i) + " Customer entities"); }
Modify the HomePage constructor to call our new method. The constructor should look like the following: public HomePage(final PageParameters parameters) { // call out method TestDatabase(); // Add the simplest type of label add(new Label("message", "If you see this message wicket is properly configured and running")); }

Testing our application Right click the project node in the Projects pane and select Run. This could take a few moments because Maven may need to download dependencies from a Maven repository if they aren't already in your local repository. Once the project builds without errors it will be deployed to the server and then it will run. You should see the output in your browser. Now switch back to Netbeans and click on the Server tab in the Output window. Scroll down to the bottom of the window and you should see something like the following:

INFO: custcont.findCustomerEntities() returned 13 Customer entities

13 exactly matches the number of rows returned when I displayed the contents of the Customer table. We have confirmed that we can connect, query and get results back from our database. Job well done! Summary

We added all the latest versions of the required libraries.
We configured JPA/Hibernate.
We added 2 Pojos to represent our domain objects.
We added CRUD support.
We created a testing strategy.
We tested and confirmed that our application works as anticipated.

What's Next In the next article in this series we will add to our project, giving it the ability to display the contents of the Customer table in the browser. We will use Apache Wicket models and the DataView control to implement the displaying of the data.

Netbeans Maven Projects

2009-03-26T08:50:00.032-04:00

Developing Java applications today is a lot like building with Lego blocks. Applications are typically composed of numerous modules and libraries, some of which you write yourself and others which are obtained from open source projects. Relying on open source to provide functionality to your applications offers many advantages. Following the DRY (Don't Repeat Yourself) principle, why recreate the wheel?

Feedback on the Web is readily available; just Google the library or functionality you are interested in. Chatter on the web will either confirm your choice or send you looking elsewhere.
Bug issues can often be resolved by a quick Google search.
Numerous support groups are available for the most popular open source projects.

Incorporating open source into your application brings a unique set of challenges. Many open source projects rely on other open source projects to provide APIs and/or implementations to their products. This is, after all, just another example of the DRY principle. For example, numerous open source libraries incorporate logging but instead of 'hard coding' to a specific logging implementation, such as Log4J, they code to the commons-logging or the Simple Logging Facade for Java (SLF4J) library, which are open source projects which act as a bridge between different logging implementations. This is an example of the Service Provider pattern where an API and possibly abstract classes provide a contract and that contract is fulfilled by numerous implementations. So how does one create applications today when faced with piecing them together from the Lego blocks made up of open source libraries and where the challenge is in resolving all the interdependencies between libraries that exist in such an environment? Trying to manually create a build script and gather all the required libraries and their correct versions has become a monumental task. It would be far better if there were a means of offloading this responsibility from the developer. That is where Maven comes into play. Maven Maven is defined on the Apache Maven project's web site as follows:

Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.

As far as descriptions go, the above is obviously acurate. But what it doesn't describe is how Maven actually resolves the issues of dependency when developing applications in today's open source environment. Imagine that you are a provider of an open source library. If your library is anything other than trivial, you most likely incorporate other open source libraries to satisfy some API, feature or functionality. You test your library and once you are satisfied that your library works as expected you publish it and make it available to the open source community. But you also provide a POM that users of your library can use to incorporate your library into their own Maven based projects. The POM not only 'defines' your library but also defines all the dependencies that your library has on other libraries. You publish your POM on one of the POM repositories so that other developers can discover it and use it to incorporate your library into their applications. Now imagine that you are a developer writing the next killer Web application and you want to incorporate the functionality provided by the open source library mentioned above. Using Maven, how would you do that and how would you do that using the Netbeans IDE? Well, Netbeans provides excellent support for Maven based projects. In Netbeans v6.5, this support comes in the form of a Netbeans plugin. My understanding is that future versions of Netbeans will incorporate Maven directly and will not require a plugin to provide Maven project support. Installing The Netbeans Maven Plugin If you haven't already installed the Netbeans Maven plugin, doing so is easy. Please follow the steps below:

Open Netbeans v6.5.
Select Tools | Plugins from the main menu. This will open up the Plugins window.
Select the Available Plugins tab and type 'Maven' into the search text box which is located above and to the right of the Plugin window's main two pannels.
Select the Maven plugin and click the Install button located beneath and to the left of the Plugin window's main two pannels.

Follow the prompts. When all is completed you will have installed Maven project support into the Netbeans IDE. Creating a Netbeans Maven Based Project I will use Netbeans' Maven project support to create a Web project based on the Apache Wicket framework. To create a Wicket application please follow the steps below:

Open Netbeans v6.5.
Select File | New Project from the main menu. This will open the New Project window.
Select Maven from the Categories pannel and Maven Project from the Projects pannel and click the Next button on the bottom of the New Project window.
In the Maven Archetypes list box select Archetypes from remote Maven Repositories. Notice that when you select this option that Netbeans goes out to the Maven Repositores and discovers all the Archetypes available there and presents these as available options for your selection. In the list of available Archetypes select Wicket Quickstart Archetype as pictured below:
Click the Next button and then click Finish. Netbeans will now create a Maven based project based on your having previously selected the Wicket Quickstart Archetype and when it is done it will open the project in the Project window as pictured below:

You have now created an Apache Wicked Maven based application. Now lets explore some of the advantages that Maven provides to project management. POMs Maven projects in Netbeans do not use ANT build scripts. Instead, it uses a POM that it generates when the project is created. In our case, the POM it generated for our project was from the POM repository and because we selected Wicket Quickstart Archetype the POM it generated is specifc to Maven based Apache Wicket applications. When you expand the Project Files folder in the Projects pane you can see 2 items there as pictured below: If you double click on the pom.xml file, Netbeans will open it in its XML editor as pictured below: POM dependency Tag When viewing the pom.xml file in the editor, scroll down until you see the following:

<dependency> <groupid>org.apache.wicket</groupid> <artifactid>wicket</artifactid> <version>${wicket.version}</version> </dependency> The dependency tag above declares a project build dependency. In this case, it represents a dependency on Apache Wicket. The groupId and artifactId tags above serve to uniquely identify the target of the dependency, and the version tag above serves to identify the version of the dependency, which in this case is identified by a property declared as follows: <wicket.version>1.4-rc2</wicket.version> Also notice that in the POM file there are numerous other dependency declarations including the following:

slf4j - a a simple facade or abstraction for various logging frameworks such as Log4J
log4j - the actual logging implementation
junit - testing framework

The dependeny declarations in the POM declare all the dependencies for our project and are used when building the project. Building POM Based Projects Go ahead and build the project by right clicking the project node in the Project pane and selecting Build. The build process generates output in the Output window. Go ahead and take a look at the generated output by clicking the Output tab. If you have never installed the Apache Wicket framework and specifically, never installed the specified version declared in the POM, you will notice that all the required jar files were downloaded for you. You didn't have to do anything like going to a web site and downloading the jars yourself. And this is true for all the other dependencies declared in the POM, too. This is one of the great benefits of using Maven; declare a dependency in the POM and when the project is built dependencies that are not already located in in your local or other repository will be downloaded onto your computer. Yes, this can add overhead to the build process but it only occurs when the required dependencies aren't already present in your local respository or some other repository that you can declare. Selecting A Server For Deployment Before we can run our application we have to tell Netbeans what server we want to deploy it on. Right click the project node in the Project folder and select Properties which will open the Project Properties window. Select Run from the Categories pannel which will display numerous runtime options, one of which is the Server option. From the Server drop down menu located on the right panel of the Project Properties window select a server of your choice such as GlassFish V3 Prelude as pictured below: Click OK. When we build and run our application, Netbeans will deploy it to the server we just selected. Running A POM Based Project Now run the application by right clicking the project node in the Project window and selecting Run. You should see the following rendered in your browser window: Summary Using Netbeans and Maven we were able to create a brand new project based on the Wicket Quickstart Archetype we selected. All the dependencies for the project were declared in the application's pom.xml file for us. When building the project, any dependency that couldn't be resolved locally was satisfied by downloading the dependency. This only took a few minutes. Imagine if you had to do all this manually. Netbeans with Maven support has taken the hassle out of working with open source. This will allow you to take better advantage of the many great open source products that are available when you create your next killer application. URLs To Some Of The Items Mentioned Netbeans Maven Wicket

Netbeans And Apache Wicket

2009-03-13T08:51:00.035-04:00

Hi there, Today I will introduce developing Apache Wicket applications using the Netbeans IDE v6.5. So lets get started. Installing Netbeans IDE v6.5 and the Wicket v1.4 Plugin First and foremost, if you haven't already, download and install Netbeans v6.5 which you can find here. By selecting the 'All' bundle option you will download and install everything you need to follow along with the examples. Once you have installed the Netbeans IDE, you should download and install the Wicket plugin for Netbeans v6.5 which you can find here. As there are 2 plugins listed on this page, please make sure that you select, download and install the one for Wicket v1.4 which will install the v1.4 Wicket libraries. Follow the installation instructions as provided on the page. This plugin was contributed by Geertjan Wielenga, a technical writer in the Netbeans Docs team who has contributed an amazing amount of material to the Netbeans community. Creating a Wicket Application With Netbeans and the Wicket plugin installed, now we can create our first Netbeans Wicket project. Start Netbeans and click File | New Project from the main menu. This will open the New Project window as pictured below: In the Categories list select Java Web and in the Project list select Wicket Application and then click Next. Accept all the default options in the Server and Settings window and click Next. In the Framework window, select Wicket 1.4 from the list of available Frameworks and then click Finish as pictured below: This will create a Wicket project which will be opened in the Netbeans IDE as pictured below: The plugin generates numerous files for you including the Server and Web descriptor files which are used to deploy and configure your web application on the application server, as well as basic Java, HTML and resource files that you can use as templates to start developing your application. Select Run | Run Main Project from the main menu to build, deploy and run the application. You should see the following rendered in your client browser: The Structure of a Wicket Application Wicket is different than most other Java Web frameworks that I have worked with or that I am familiar with, in that Wicket's convention is that it expects Java and markup files to reside side-by-side in the same Java package. This can be seen in the above screenshot. A rendered Web page in a Wicket application is implemented with at least 2 files, a Java Class file and a markup file. Both files must have the same names and are case sensitive. As we can see from the above screehshot, both HomePage.java and HomePage.html files are used when there is a request to render the HomePage html file to the client browser and they reside side-by-side to eachother. Just Java and HTML One of the advantages when working with Apache Wicket is that you create your application using just plain old Java, X/HTML, CSS, and resources. Another advantage is that you don't mix markup and scripting in your HTML files as is often the case in other frameworks. In other words, when you view a markup file in a Wicket application you will only see HTML. There is no spaghetti-code intermixed inside your markup. This clean separation of code and markup helps when developing and maintaining your applications by making your applications easier to read and understand. It also allows programmers and designers/graphic artists to work together on the same pages. Designers and graphic artists shouldn't have to be programers in order to do their jobs so not having to work with markup files that have server-side scripting code in them can eliminate that problem. Double click on the HomePage.html file located in the Projects window. It will open in the Netbeans HTLM editor window as pictured below: What you see is what you would expect to see when viewing markup - HTML! Extending Our Application The rendered page in our new application isn't much to look at but it will serve as a foundation to demonstrate adding dynamic content to a web page using Wicket. For this demonstration we will add markup and Java code to render the ubiquitous "Hello, World!" message as well as the current date and time in the client browser. But for the first crack at this, lets cheat and show how to do this by just adding static text to the HomePage.html file. Double click HomePage.html in the Netbeans Project window. The file will open in the Netbeans HTML editor. Add the text as pictured below: Select Run | Run Main Project from the main menu to build, deploy and run the application. You should see the following rendered in your client browser: Adding Dynamic Content If all we want to do is to display static text then our job would be done, but static pages are boring. Lets add some code and markup to make this page display the current date and time as well when the page is rendered. Double click HomePage.html in the Netbeans Project window. The file will open in the Netbeans HTML editor. Modify and add the text as pictured below: Notice that we've added a span tag to the markup and that it has a wicket:id attribute whose value is lblDateTime. When we create a Wicket componet to contribute to the body of this span tag we will pass this same value to the component's constructor as its first parameter which is its id. Double click HomePage.java in the Netbeans Project window. The file will open in the Netbeans Java editor. Modify the HomePage class as pictured below: In the HomePage constructor we obtain and instance of a Calendar object which will be used to get the current date and time. Then we add a Label to the page. A Label is a Wicket component that adds its content to the body of any HTML element that it is associated with. The association between the HTML element and the component is made through the component's id value which we pass as the first parameter in the Label's constructor. The id value we pass is the same value that was assigned to the wicket:id attribute of the span tag in the HomePage.html file. The second parameter we pass in the Label's constructor is the value of what we want to add to the body of the span element that the Label component is associated with. In this case, we will pass the current date and time as a string. Select Run | Run Main Project from the main menu to build, deploy and run the application. You should see the following rendered in your client browser: Although this application is trivial, the principles used here are the same ones used when developing real world enterprise Wicket applications. Synergy - Netbeans and Wicket As demonstrated, Netbeans with the Wicket v1.4 plugin provide many features and services for creating, developing and maintaining your Wicket applications. It is a highly productive and intuitive environment. Wicket offers Java Web developers a simple, intuitive, and productive framework to create Web applications with. Now that Netbeans has solid support for Wicket, I believe both will continue to grow in popularity.

Adventure With Wicket - Custom Controls

2009-03-09T17:34:00.022-04:00

As I mentioned in my introduction, I am developing a web site and I am using Apache Wicket as my Java Web Framework. Today I decided to tackle creating a custom web page control that would encapsulate a tabbed menu bar that you find frequently used on web pages. The common method to implement a tabbed menu bar is through a combination of HTML, css and JavaScript on the client side and some server side scripting as well. As Wicket is often described as being just HTML and Java I thought this would be a good candidate to encapsulate into a Wicket custom component. So with my copy of "Wicket In Action" (a book by Martijn Dashorst and Eelco Hillenius, which is published by Manning and I highly recommend) in hand I set out to implement the control. First, like any good developer, I came up with a number of requirements which I've identified as follows:

The tabbed menu bar will be rendered in the browser using the ul and li tags which is a common practice employed by web page designers. When combined with the correct style sheet attributes the list can be rendered horizontally:

The number of tabs displayed in the menu bar must be dynamic and defined by a model which in essence would consist of a list of menu tab items. Below is the MenuItem Java class that I defined to represent a single menu bar tab:
As for usability, the control must be configurable and provide options that specify styling for the selected and non selected tabs, identity of the current tag, a model representing the list of MenuItems, and an id which will be used to render the html id attribute of the containing html div tag for the control's child html elements. The id is important because it will be used to customize the JavsScript that is rendered to provide client-side scripting of the control but more on that later. Here's the Java code for the custom control:

With the requirements identified and the implementation complete, all that is needed is a test. Here's a simple html snippet showing the tag that will be replaced by the Wicket panel hosting the control: And here is the Java code to instantiate the control in the page:

And here is how the control appears when it is rendered in the client browser: Overall, developing custom controls for Wicket applications isn't difficult and I find it much more intuitive than when I've done similar tasks with other frameworks . I use sort of a top-down approach to this kind of task, which allows for an iterative development process where each iteration adds more functionality and specificity. There were a number of topics that I admitedly didn't touch on here such as the generation of the client-side JavaScript and the use of the AbstractReadOnlyModel class. I will discuss these in a future article.

Introduction

2009-03-07T11:47:00.016-05:00

Welcome! My name is Jeff Schwartz and this is my blog where I will be posting about software development. I'll assume that if you are following the articles that you too are either a software developer or that you are interested in software development. Occasionally, I may "speak my mind" on other issues, but this will be a place where I mostly discuss software development. So you wont get a large window into my personal life here other than what I feel comfortable divulging (see bottom of article for that little window). What's wrong with Web application frameworks Developing Web sites over the years has afforded me the opportunity to experience the good, the bad and the ugly of the development process. Part of that process has been having to deal with numerous Web frameworks with promising potential but that ultimately fail to live up to what can only be described as hype. For the most part every framework that I have been exposed to have fallen far short of expectations for requiring far too much configuration and for failing to take into account established and best practices such as failing to implement the MVC (Model View Controller) pattern and failing to provide a component based architecture. In addition to these, the most egregious of their failings in my opinion is that they do not hide the fact that the Web is a stateless protocol. This is most easily recognizable when studying how most Web frameworks deal or do not deal with session state. Those that do not deal with session state offload the responsibility to the developer by providing a hash (a mechanism to save a value and associate it with a name as well as to retrieve a value by its name) to save and retrieve string values and which is stored on the server and persisted over the life of a user's session while browsing a web site. This mechanism is perhaps the greatest single source of complexity, frustration and errors that a developer will experience over the course of an application's lifetime. All this lead me on the search for the Holly Grail, a Web application frameworks that didn't succumb to the same shortcomings as I perceived them. So I began looking for alternatives. I looked at Ruby On Rails but I hated the mixed markup/code pages. I wanted a framework that promoted a separation of concerns. I looked at PHP but like ROR it also has mixed markup/code pages. I looked at Java EE but I wasn't thrilled about the popular Java Web frameworks that seemed to be discussed the most; way too much XML configuration required to get even the simplest of web applications up and running in my opinion. Then I heard of an open source, statefull, MVC, component based framework written in Java called Apache Wicket and it was like love at first sight. I read everything I could get my hands on about it and almost everything about it just seemed right to me. Most compelling is its non intrusive Ajax support. Wicket, it seemed to me, had to be written by people who actually have experience writing real world web applications, especially large applications. Below I list the strengths of the Wicket Web framework:

It is a true MVC component based framework that allows me to do everything using just Java and HTML.
It is statefull. It hides the stateless nature of the HTTP protocol from the developer.
Its Ajax support is excellent and unobtrusive.
It requires almost no XML configuration other than the typical Java application server and application descriptors which are minimal.

To be fair, Wicket isn't perfect. Its shortcomings, as I see them, are the following:

Wicket can sometimes require more coding than some frameworks (ASP.net and JSF, for example) because there are no widget libraries that allow a developer to drag and drop controls off of a palette and onto an HTML page and gaining the benefit of the generated code behind the widgets.
A developer can easily abuse the statefull nature of the Wicket framework and overtax the server. Developers must learn to employ loadable and detachable data models to reduce the likelihood of this. Thankfully, Wicket provides its own LoadableDetachable abstract implementation. Developers just need to remember to use it as Wicket itself does not enforce its use.
Like many open source projects, Wicket sometimes suffers from poor or inadequate documentation.
Wicket doesn't seem to get the tech press coverage that other Web frameworks seem to get so sometimes you as a developer may get that black sheep of the family feeling.

Warts and all, it should come as no surprise that Wicket has become my Web application framework of choice. It is my belief that most Web frameworks will follow the lead taken by Wicket and offer similar benefits to the developer. Benefits of Java and open source I have become a huge proponent of Java and open source. Of the many benefits they provide, here are a few I think are the most important :

Java is open source and hence comes under the scrutiny of a large group of stake holders. These stake holders have a great deal of influence in ensuring that Java remains relevant and competitive with all the other options available such as DotNet, C/C++, PHP, Python, Ruby, etc.
Java is continuously evolving. Java EE, JavaFX, etc.
Java supports both the client (Java SE) and the enterprise (Java EE).
There are numerous open source libraries available that provide pre-built solutions to common requirements so that as a developer I don't have to reinvent the wheel each time a new project is begun. I am a firm believer in the DRY principal.
Java supports write once, run almost everywhere via the Java run time.
There are excellent open source development tools available, IDEs such as Eclipse and Netbeans for example, that provide tooling that minimizes the implementation effort.
Java and open source minimize the upfront costs to the developer as many of the tools and libraries are free.
Java plays well with other technologies such as numerous back-end databases.
Java is a a true object oriented language. I cannot over emphasize how important OO is to me. I think it just relates to how my mind works :).

My primary Java web development environment for the most part consists of the following:

Windows running either XP or Vista though I have Ubuntu as well and I have access to Mac OSX.
The open source Netbeans IDE.
MYSQL.
GlassFish Server.
FireFox with Firebug and JavaScript Debugger.
Apache Wicket Web application framework

When developing Web applications I prefer to work with native XHTML and shy away from the WYSIWYG editors. I really like the HTML editor in Netbeans. My javascript library of choice is JQuery. It is another one of those frameworks that just seems and feels right to me. I believe it, too, was written by people who have written a lot of code. For entity persistence and database query services I use both JPA/EclipseLink and Hibernate . To tie the 3 tiers together in my enterprise applications I will use the Spring framework. Spring brings a lot of features to the table but I find it most useful for its IOC (Inversion Of Control) container. Here are some links to some of the open source items that I mentioned were mentioned

Oh, and here is a little window into my personal life. I have 5 cats and play the guitar. I am a slave to my cats and the guitar is my only passion other than developing great software. Well, that's about it for now. In the future I will post articles that I hope you find interesting and possibly even educational. Since Wicket and Netbeans are 2 of my favorite technical subjects, I'll be writing a lot about them here. So please come back often to see what is new and feel free to comment on anything that you may read about here.