Category Archives: Java EE

Synchronizing access to CDI Conversations

If you are using CDI’s conversations you will most likely have come across the dreaded BusyConversationException. The CDI 1.0 specification states that the container must ensure that only one request at a time may be associated with the conversation by blocking or rejecting subsequent requests.

OpenWebBeans will immediately reassign and throw a BusyConversationException if the conversation is currently held by another request. Weld on the other hand uses a 1 second timeout to obtain a lock on the conversation before reassigning the request and throwing a BusyConversationException. Although this makes it less likely to occur, if you are dealing with multiple waiting requests or long running processes, you will still encounter them.
Continue reading Synchronizing access to CDI Conversations

JSF 2 AJAX/Submit issues with @ConversationScoped Beans

When working with ConversationScoped Beans and AJAX, you always have to be careful not to run into BusyConversationExceptions.

Lets consider the following scenario where the inputField triggers an ajax event when the value is changed:

[xhtml]
<h:inputField value="#{conversationScopedBean.bar}" …>
<f:ajax event="change" render="@this" … />
</h:inputfield>

<h:commandButton … action="fooAction.proceed" />
[/xhtml]

When you change the input and click on the commandButton, without triggering the change event by exiting the field first, you will encounter a BusyConversationException. This happens because the click triggers the change event firing an AJAX request, immediately followed by the button’s submit.
Continue reading JSF 2 AJAX/Submit issues with @ConversationScoped Beans

Keeping focus on element with JSF 2 AJAX render

Anyone who has developed JSF 2 applications for any length of time, will have come across the issue that element focus may get lost when AJAX rendering is preformed.
So what is the cause of this? I have constructed a simple webapp to demonstrate the issue and show a potential solution.

One of the simplest possible scenario is a simple value change event that triggers a render on the following field:

[xhtml]
<h:outputLabel value="Input field: " />
<h:inputText id="firstValue" value="#{sessionBean.firstValue}" tabindex="1">
<f:ajax event="change" render="secondValue thirdValue" />
</h:inputText>
<h:outputLabel value="Render to Upper field: " />
<h:inputText id="secondValue" value="#{sessionBean.secondValue}" tabindex="2" />
[/xhtml]

On the server side we are simply preforming a toUpper on the firstInput and assigning it to the secondValue. In this case implemented as a simple session scoped CDI bean, the underlying backing bean infrastructure has no influence on the response that JSF produces or how it is treated by the client.
Continue reading Keeping focus on element with JSF 2 AJAX render

Push notifications with JEE 6

For most modern webapps push notifications have become a standard requirement. WebSockets would be my first choice, however it has only become available with JEE 7. It will take some time until JEE 7 compliant servers reach main stream production environments.

In the mean time we can achieve similar behavior with Servlet 3.0, which has become part of the JEE 6 specification, either by polling or long polling.

Polling relies on the client repeatedly sending requests to the server, polling for new messages. This will often result in empty responses, to avoid this unnecessary traffic we can hold on to the request until a new message is available or time-out is reached (long polling).

Effectively long polling requires the client to send a request, which is kept alive by the server until a response is available or a time out occurs. It is up to the client to initiate another request in both cases.

To do this we have to accept incoming GET requests and set asyncSupported to true. This stops the response object from being committed on method exit.
Continue reading Push notifications with JEE 6