claymitchell.net

While working on some existing code (that someone else wrote), I got this error:

_recon_5F_tabs.java:45: code too large for try statement

I discovered a bug while monkeying around with trac, the absolutely wonderful, not to mention free (as in beer) wiki & bug tracking system aimed at software development – it’s Subversion browser breaks if your database is PostgreSQL 8.3. It works if it’s an empty repository, but as soon as you add a file or folder, it throws an error message like this:

Traceback (most recent call last):
File "/usr/local/lib/python2.5/site-packages/Trac-0.11b1-py2.5.egg/trac/web/api.py", line 339, in send_error
'text/html')
File "/usr/local/lib/python2.5/site-packages/Trac-0.11b1-py2.5.egg/trac/web/chrome.py", line 670, in render_template
if not req.session or not int(req.session.get('accesskeys', 0)):
File "/usr/local/lib/python2.5/site-packages/Trac-0.11b1-py2.5.egg/trac/web/api.py", line 168, in __getattr__
value = self.callbacks[name](self)
File "/usr/local/lib/python2.5/site-packages/Trac-0.11b1-py2.5.egg/trac/web/main.py", line 255, in _get_session
return Session(self.env, req)
File "/usr/local/lib/python2.5/site-packages/Trac-0.11b1-py2.5.egg/trac/web/session.py", line 48, in __init__
self.get_session(sid)
File "/usr/local/lib/python2.5/site-packages/Trac-0.11b1-py2.5.egg/trac/web/session.py", line 74, in get_session
(sid, int(authenticated)))
File "/usr/local/lib/python2.5/site-packages/Trac-0.11b1-py2.5.egg/trac/db/util.py", line 50, in execute
return self.cursor.execute(sql_escape_percent(sql), args)
File "/usr/local/lib/python2.5/site-packages/Trac-0.11b1-py2.5.egg/trac/db/util.py", line 50, in execute
return self.cursor.execute(sql_escape_percent(sql), args)
ProgrammingError: current transaction is aborted, commands ignored until end of transaction block

Fortunately there is a work around: Change the repository_type value in trac.ini to direct-svnfs instead of svn. A ticket has been opened on over on trac’s trac site

I spent a fair amount of time banging my head against the wall trying to figure out how @SessionAttributes works in Spring’s annotations. The concept and implementation is fairly simple, the use and lack of documentation is confusing. Here’s your standard usage:

@Controller@RequestMapping("/someForm.do")
@SessionAttributes("fooForm")
public class FooFormController {
	@RequestMapping(method = RequestMethod.GET)
	public String setupForm(ModelMap model) {
 		FooForm fooForm = new FooForm();
 		// populate fooForm
 		model.addAttribute("fooForm", fooForm);
 		return "fooFormDisplayPage.jsp";
 	}

	@RequestMapping(method = RequestMethod.POST)
 	public String processForm(@ModelAttribute("fooForm") FooForm fooForm) {
 		// do something with fooForm
 		status.setComplete();
 		return "redirect:/someOtherView";
	}
}

The way this works is that the object that is inserted into the ModelMap and identified by @SessionAttributes is stored in the session across the life of the controller. The ModelMap object’s lifespan is tied directly to that of the controller object. Despite it’s name, @SessionAttributes has absolutely nothing to do with HttpSession.set/getAttribute(), it’s simply the annotated version of <sessionForm> from the xml version of the Spring configuration. The upshot of this is that the value identified in @SessionAttributes is not available to a different controller.

What if you want to store something in the session across multiple requests? The tried and true method of storing it in the HttpSession is still valid:

@RequestMapping(method = RequestMethod.POST);
public String processForm(@ModelAttribute("fooForm") FooForm fooForm,
                          HttpSession session) {
	// do something with fooForm
        session.setAttribute("fooForm", fooForm);
	status.setComplete();
        return "redirect:/someOtherView";
}

You can also define multiple request mappings inside of the same Controller object

@Controller
public class MultiViewController {
	@RequestMapping("/foo");
	public String handleFooRequest(ModelMap model) {
		// Handle request
	}
	@RequestMapping("/bar");
	public String handleBarRequest(ModelMap model) {
		// Handle request
	}
}

And there you go. Annotations are neat, allow for straight up pojos, and remove a lot of unnecessary XML configuration. Use them, just make sure they are adequately documented.