Category Archives: Java

Java, Java EE

Stateful JAX-WS with CDI – Part 1

Leave a comment

Usually it is desirable to keep web services stateless. This is because it allows for easier scalability (since no state has to be shared across multiple instances) and reduced load on system resources (as no state has to be held or cleaned up).

However, there are scenarios where it may be desirable to maintain server sided states across multiple requests. As I have demonstrated in my previous post CDI CONVERSATIONS FOR JAX-RS WITH JEE 6, it is possible to utilize CDI conversation scope in JAX-RS restful services. CDI conversation scope was designed to deal with the limitation of having one session per browser, allowing for tab-specific state to be kept on the server side.

JAX-WS is primarily used in fat-/smart-client server scenarios. Fat-/Smart-clients, unlike browsers, are capable of managing multiple sessions as required. JAX-WS has build-in support for SOAP and HTTP session management (see JAX-WS 2.2 Rev a, Chp. 10.4.1.4 Session Management).

Server-Side
Setting up the session context on the server side is a simple matter of defining a @SessionScoped CDI bean…

[java]
@SessionScoped
public class Interactions implements Serializable {

private List<String> names = new ArrayList<>();

public String interact(String name) {
final String interactions = "Hi " + name + ", I previously interacted with " + names;
names.add(name);
return interactions;
}

public Integer getNumberOfInteractions() {
return names.size();
}
}
[/java]
Continue reading Stateful JAX-WS with CDI – Part 1 →

Java, Java EE

CDI VooDoo – The Bean Manager and Circular Injection

Leave a comment

CDI supports circular dependency injection when at least one of the beans has a [simple_tooltip content=’standard CDI: @ApplicationScoped, @SessionScoped, @ConversationScoped, @RequestScoped’]normal scope*[/simple_tooltip], this may be useful when sharing contextual information between beans of same or different scope (e.g. MVC pattern).

The CDI BeanManager is responsible for the creation of all CDI beans and managing contextual access to all normal scoped beans.

[java]
@RequestScoped
public class Foo {
@Inject
private Bar bar;
…
}

@RequestScoped
public class Bar {
@Inject
private Foo foo;
…
}
[/java]

Continue reading CDI VooDoo – The Bean Manager and Circular Injection →

Java, Java EE

CDI 1.1/1.2 Im-/Ex-plicit bean archives

Leave a comment

Implicit bean archive
CDI 1.1 introduced the notation of implicit bean archives, making the inclusion of beans.xml optional. Only beans annotated with bean defining annotations will be considered.

An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation, or one or more session beans.
CDI 1.1 specification, 12.1. Bean archives

It is important to note that CDI 1.1 defined all JSR-330 javax.inject.* annotations as bean defining, however this caused some problems with archives that use other JSR-330 compliant injection frameworks, most notably google guava library.

The CDI 1.2 maintenance release addresses these by limiting bean defining annotations to:

  • @ApplicationScoped, @SessionScoped, @ConversationScoped and @RequestScoped annotations,
  • all other normal scope types,
  • @Interceptor and @Decorator annotations,
  •  all stereotype annotations (i.e. annotations annotated with @Stereotype),
  •  and the @Dependent scope annotation.

CDI 1.2 specification, 2.5.1. Bean defining annotations

Any bean that does not define at least one bean defining annotation, will be ignored by CDI. Most notably beans solely defining @Named or CDI pseudo-scopes other than @Dependent, such as @Singleton will be ignored.
Continue reading CDI 1.1/1.2 Im-/Ex-plicit bean archives →

Java, Java EE

CDI Conversations for JAX-RS with JEE 6

Leave a comment

RESTful services are a great basis for client sided JavaScript WebApps whether written in jQuery UI or AngularJS among others. However browsers can only associate server responses to the correct tab if the request is unique, otherwise if the site is open in multiple tabs the response may be routed to any one of the open tabs.

The routing issue can be solved by simply adding an arbitrary tab specific unique parameter to the request that allows the browser to route the response to the correct tab.

[html]
../resources/stuff?tabUniqueId=1
[/html]

This works as long as we don’t want to maintain any tab specific server sided state. CDI Conversations offer and easy and ready made solution to this problem. When dealing with JSF applications it is a simple matter of dealing with conversations, since the entire handling is performed by the respective CDI and JSF implementation.
Continue reading CDI Conversations for JAX-RS with JEE 6 →

Java, Java EE

Using JCache in JEE 6/7

Leave a comment

I can’t count the number of times I have come across yet another mostly buggy custom caching solution. Be it a HashMap stuck into a random DAO, a service or an annotation driven solution with interceptors of one flavor or another. I guess this is partially to blame on the long pending JCache specification (JSR-107), which has now been finalized last year some 13 years on from when it was first conceived.

Although JSR-107 missed the deadline for inclusion in the JEE 7 specification, it is still fairly easy to provide the required dependencies with your application to get full JSR-107 support in any JEE 6 or 7 compliant application server.

If you wanted, you could use the JSR-107 reference implementation, however it is strongly advised not to use the reference caching provider implementation since there is neither support nor an active community backing it.
Continue reading Using JCache in JEE 6/7 →

Java, Java EE

Synchronizing access to CDI Conversations

7 Comments

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 →

Java, Java EE

JSF 2 AJAX/Submit issues with @ConversationScoped Beans

1 Comment

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 →

Java, Java EE

Keeping focus on element with JSF 2 AJAX render

4 Comments

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 →

Java, Java EE

Push notifications with JEE 6

2 Comments

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 →