Page History

...

This page aims at providing some additional information about the Hibernate AdminApp. The Hibernate AdminApp (hereafter referred to as AA) was created by the Hibernate developers to show a possible implementation strategy for Hibernate with Webwork. Although AA can still be used as a starting point for webapplications, most of its libraries become quite aged (WW 2.0 beta, Hibernate 2, XWork 1.0 beta). Therefore, a shiny new fork (AA2) has been created by Ron Chan.

AA2 relies on WW2.2, Hibernate 3.1, and Spring as its IoC container (rather than XWork's, which has been deprecated in WW 2.2). We'll first discuss the original AA. Later on, we'll show the differences with AA2. Ron, if you're reading this, feel free to point out any mistakes/edit this document.

Like we pointed out before, AA shows a possible implementation strategy to use Hibernate in WebWork in combination with a so-called open-session-in-view pattern (more info, even more). This pattern allows maximum flexibility in our view layer by creating a Hibernate Session object that will live till the end of the request (after the view has been rendered). This allows lazy loading of objects in our view, rather than having to preload all objects and their associations in our business layer, and yet ensures the correct disposing of the Session object.

To accomplish this, AA uses XWork's components and interceptors:

• components: XWork manages the lifecycle of objects in several scopes (application, session, request) and takes care of the IoC through the ..Aware interfaces (so called enablers). Hibernate's expensive-to-create SessionFactory will thus be created in the application scope (meaning it will only be initialised once when the application starts up), while the Session objects, used to load our models, is registered in the request scope (will be created once per request).

• interceptors: AA uses an interceptor (the HibernateInterceptor) to extract the Session from the WebWork action, so it can control the transactions, redirect/rollback on errors and properly dispose the Session after the view is rendered.

...

In this execute() method we'll simply call a abstract go() method (which is then defined in each of the actions). When we need the Hibernate Session, we use the getSession() method, inherited from our AbstractAction. Don't worry about transactions or saving so called dirty objects (our HibernateInterceptor takes care of all that). As you can see, this totally minimizes the LoC (lines of code) needed to retrieve or manipulated our models).

...

..
    <field name="user.name.lastName">
        <field-validator type="requiredstring">
            <message>You must enter a last name.</message>
        </field-validator>
    </field>
    <field name="user.email">
        <field-validator type="email">
            <message>Please correct the e-mail address.</message>
        </field-validator>
        <field-validator type="required">
            <message>Please enter an e-mail address.</message>
        </field-validator>
    </field>
..

Several validator types are available. Here we rely on XWork to validate our Actions, but it's also possible to validate our object Models (see WW Validation). You will mostly use these to validate submitted forms in your webapp.

...

a) actually provided an input type in your xwork.xml file

	..
        <result name="input" type="dispatcher">
		<param name="location">/editUser.jsp</param>
	</result>
	..

b) you enabled the validation interceptor in your xwork.xml

	..
	<interceptor-ref name="defaultStack"/>
	<interceptor-ref name="validation"/>
	..

...

..
<ww:form name="'createUserForm'" action="'createUser.action'" method="'POST'">

    <ww:textfield label="'Username'" name="'user.handle'"/>
..

New syntax (since 2.2):

..
<ww:form name="createUserForm" action="createUser" method="POST">
    <ww:textfield label="Username" name="user.handle"/>
..

• /src/java/org/hibernate/admin/component: contains the components and enablers for both the HibernateSessionFactory and the HibernateSession. These components are declared in the /src/java/components.xml file (which will be copied to the root of your compiled classes afterwards):

...

• /src/java/org/hibernate/admin/interceptor: contains the Hibernate interceptor. Interceptors are an incredibly powerful feature of WebWork - it allows you to control invocations before and after they excute, manipulate their results, or, as in our case, extract the HibernateSession object and dispose it after the Action has been executed (and the view rendered). Because we use a try/catch/finally block, we're able to catch exceptions and yet make sure our Session gets closed properly (the number one cause of db connection leaks).

...