It’s been a while since I last blogged. I keep thinking of blogging something technical but end up getting busy with other things. This last week there was a very interesting discussion at the coderanch forums. It was even more interesting because it involved JBoss.
Developers familiar with Java EE web applications would know that the web application deployment descriptor (web.xml) allows you to specify ‘error pages’ which the container will display when a specific exception (class) or a error code is thrown by the server for a web request. Here’s a quick example of how it looks like:
<web-app>
...
<!-- A custom error page for error code == 500 -->
<error-page>
<error-code>500</error-code>
<location>/my-foo-bar-500-page.html</location>
</error-page>
<!-- A custom error page for exception type org.myapp.foo.bar.MyException -->
<error-page>
<exception-type>org.myapp.foo.bar.MyException</exception-type>
<location>/my-foo-bar-exception-page.html</location>
</error-page>
...
</web-app>Simple enough – a couple of custom error pages defined for a specific error code and an exception type respectively. All of this works fine. In current days, more and more programming models and frameworks come into picture while developing web applications. CDI and JSF are some of those. CDI has this concept of scopes (ex: request scope, session scope, application scope, conversation scope). We won’t go into the details of what those are and when those are used, but let’s consider conversation scope in this blog since that’s what the discussion was about in the forum thread that prompted this blog.
So CDI allows multiple requests to be part of a ‘conversation scope’. A conversation has a ‘start’ and an ‘end’, both of which can be managed by the application. When the application involves JSF, any conversation (id) gets auto-propagated to the JSF request(s). Apart from an explicit start/end demarcation of conversations, a conversation can also timeout. A request which refers to a conversation which has ended or timed out will run into an exception.
So we know have a bit of background on CDI conversation scope. So let’s consider a case where the application wants to present a good looking page when the ‘conversation no longer present’ exception is thrown (maybe because of a timeout). We have seen how to write a web.xml for error-page configurations – it would be as simple as:
<web-app>
...
<!-- A custom error page for exception type org.jboss.weld.context.NonexistentConversationException -->
<error-page>
<exception-type>org.jboss.weld.context.NonexistentConversationException</exception-type>
<location>/my-foo-bar-exception-page.html</location>
</error-page>
...
</web-app>Simple enough. The org.jboss.weld.context.NonexistentConversationException is the exception class type which gets thrown when the conversation has timed out (note that we are assuming that the web application is relying on Weld as the CDI spec implementation library). The above configuration works fine. The my-foo-bar-exception-page.html gets displayed when the org.jboss.weld.context.NonexistentConversationException is thrown. BUT, let’s now consider that we want to involve JSF in the error page just like the other parts of our application. So let’s point the error-page to a URL pattern which maps to the JSF servlet:
<web-app>
...
<!-- A custom error page for exception type org.jboss.weld.context.NonexistentConversationException.
Notice the "nocid" parameter being passed to make sure that the non-existent conversation id
isn't passed to the error page
-->
<error-page>
<exception-type>org.jboss.weld.context.NonexistentConversationException</exception-type>
<location>/my-foo-bar-exception-page.xhtml?nocid=true</location>
</error-page>
...
</web-app>Notice that we are passing the 'nocid' parameter as part of the query string of the error page location. The value for 'nocid' parameter really doesn't matter but for the sake of keeping that value logical, we have used the value 'true' here. Once this change is done, you'll start noticing that the error page (backed by JSF) now renders correctly!
It took a while for us to get to this solution in that forum thread because it looked so simple that it should have 'just worked', but it didnt' Here's the forum thread at coderanch that I've been talking about. Credit goes to Greg Charles for figuring out how to pass that nocid parameter.
Reference: Custom error pages for expired conversations involving CDI and JSF from our JCG partner Jaikiran Pai at the Jaikiran My Wiki blog.
