Will Jaynes

« April 2006 | Main

June 11, 2006

Spring MVC, Open-Session-In-View, and validation errors

I've seen this problem discussed a lot. Here's my take on it, and my solution:

Problem: (taken mostly from a Spring Forum entry)

• Spring MVC application with OpenSessionInViewFilter enabled, in singleSession mode
• Posting a form after editing some domain object
• In formBackingObject(), you get your domain object from Hibernate, through a transactional service layer and pass it back to the MVC framework
• Form data is bound to the domain object by the framework, thus changing the hibernate session bound object
• Your registered validator fails validation for some reason
• MVC framework will return the configured formView to the browser
• The OpenSessionInViewFilter flushes the hibernate session
• Annnnnnd, your object is persisted, even though there were errors.

When valildation fails, you don't want the changes persisted, but unless you do something, hibernate will automatically update the object. Remember, in this scenario the Spring binding process changes the object, and hibernate is watching the object and knows it has been changed. My solution is to clear the hibernate session. In my controller, which extends SimpleFormController I override the processFormSubmission as follows:

    @Override
    protected ModelAndView processFormSubmission(HttpServletRequest request,
            HttpServletResponse response, Object command, BindException errors)
            throws Exception {
        if (errors.hasErrors()) {
            getService().clearSession();
        }
        return super.processFormSubmission(request, response, command, errors);
    }

The getService().clearSession() method just uses a Dao the has a clearSession method that calls getHibernateTemplate().clear()

Posted by jaynes at 09:30 AM | Comments (0) | TrackBack

June 01, 2006

JavaCosign Rewrite

This is an email I sent to the cosign-dicuss@umich.edu email list a while ago. I'm putting it here as an easy reference.

Quick summary:
Medical School Information Systems (MSIS) here at U of Michigan has written it's own version of JavaCosign-1.5. We'd like to figure out how we might join with the official development process, rather than staying out on our own.
-------------------------

As you may have gathered from my recent emails to you and the cosign-discuss group, MSIS has decided to begin using cosign on at least some of our J2EE web apps. Unfortunately, when we looked at the current implementation of JavaCosign we found that the architecture wouldn't work well for our environment. Currently the implementation tightly couples the filter with the connection pool that connects to the Cosignd servers. Each instance of the filter requires it's own pool. There's no way to share the connection pool between different apps that use the filter.

At MSIS we run many web apps per app server, and most of these apps have relatively light traffic. It isn't efficient for each app to have it's own pool.

Given this, Tony Chan (who just recently joined MSIS) and I decided to rework the code to better suit our needs. Frankly, we stepped back, reevaluated the design, and pretty much rewrote it completely. I know it would have been better to work with the cosign team rather than going off on our own, but we just didn't know how to approach the community with plans for a complete rewrite.

So, now we have an alternate version of JavaCosign-1.5. It is functionally equivalent, with one exception, however the configuration file format is different. The one feature we cut out is the dynamic rereading of the config file if it changes. If the community affirms that that feature is necessary, then we'd be willing to look at putting it back in.

This new version is designed around interfaces and modularity. The filter functionality and the connection pooling functionality are completely separate. The pooling implementation is pluggable, as well as the objects that are pooled. We have two pooled objects implemented: the ConnectionList as in the current JavaCosign, and a SingleConnection object that just keeps open one connection at a time. We have not used JAAS, we have removed all singletons and substituted stateless service objects. We think the code is much simpler to understand and easier to work with (but, of course, we would).

Although we have developed this new version on our own, we do, actually, want to work with the Cosign community. We just aren't sure how to do that. So, how do you suggest we proceed from here?

Will

Posted by jaynes at 08:29 AM | Comments (1)