EJB 3.1 Exceptions

SessionContext is used for Session Beans.
MessageDrivenContext is used for Message Driven Beans.

EJB 3.1 Message Driven Bean Lifecycle

MDB Lifecycle, from book "Oreilly Enterprise Javabean 3.1, 6th Edition"

EJB 3.1 Component Types

EJB 3.1 component types are:

1. Session Beans
1. Stateless Session Beans (SLSB)
2. Stateful Session Beans (SFSB)
3. Singleton Session Beans
2. Message Driven Beans (MDB's)
3. Entity Beans

• The Stateless Session Bean does not preserve conversational state.
• The Stateful Session Bean preserves conversational state and there is one instance of the session bean per client.
• The Singleton Session Bean is new to the EJB 3.1 Specification. There is only one instance of this bean type.
• The Message Driven Bean acts as an event listener. It cannot be called from the client.

For each Bean, there are lifecycle callbacks that must follow the pattern void <METHOD>().

EJB 3.1: Stateful Session Bean lifecycle

SFSB Lifecycle, from book "Oreilly Enterprise Javabean 3.1, 6th Edition"

Lifecycle events:
@PostConstruct
@PreDestroy
@PrePassivate
@PostActivate

With SessionSynchronization:

SFSB Lifecycle with SessionSynchronization, from book "Oreilly Enterprise Javabean 3.1, 6th Edition"

Programming Rules for Stateful Session Beans:

• The Stateful Session Beans maintain conversational state, so the instance variables must be Java primitives or Serializable objects.
• Since the SFSBs cannot be pooled like the SLSBs, there can be the risk of accumulating too many of them. So the client can explicitly request the removal of a bean by calling a method annotated with the @Remove annotation.

EJB 3.1: Asynchronous Methods

New to EJB 3.1, by using the @javax.ejb.Asynchronous annotation, we can achieve fire and forget invocations, useful when having long time processing methods. When the client needs to use the result, it can take use of the facilities provided by the java.util.concurrent.Future
We can use the @Asynchronous annotation on class level, so all the methods are asynchronous, or we can use the @Asynchronous annotation at the method level.

A void method can also be marked with the @Asynchronous annotation, but in this case, no exceptions will be delivered to the client.

@Asynchronous
public Future<String> doStuff(final String input){
    // do stuff and return
    return new AsyncResult<String>("myResult");
}

If the asynchronous method has a return type Future<V> and it throws an exception, the the client will get an ExecutionException when trying to retrieve the result.

Cancel a request:
The client can request a cancel on the Future<V> invocation, using
Future<V>.cancel(boolean mayInterruptIfRunning)

where the boolean parameter represents if the asynchronous method can see if the cancel was requested.
The asynchronous method can check if cancel was called by the client, by using the SessionContext.wasCancelCalled()

Retrieving the results:
final Future<String> futureTask= myEjbProxyReference.doStuff(input);
final String result= futureTask.get(10,TimeUnit.SECONDS); //should catch the TimeoutException

Please notice the if the get() method is called with no arguments, then the get() will block until the result is available. To be assure that the result is retrieved after an undefined amount of time, then the Future<V>.isDone() method should be called, to check if the asynch result processing was already finished.

Text editors for log analysis

Notepad++
I usually use the Notepad++, that deals well with big files, allows me to search in all opened files, search on a folder, use a regular expression for the search and even allows the usage of plugins for extra-stuff, like validating XML.


Baretail
For checking the tail of a log that is being written, I like to use Baretail.

Otros Log Viewer
I have already tried Otros Log Viewer, that is good to filter by threads, but I found it difficult to use... maybe it's lack of practice with this tool.

Other text editors for log analysis that I would like to try:
- LogExpert
- Sublime Text

EJB 3.1 Stateless Session Bean lifecycle

The SLSB (StateLess Session Bean) has a lifecycle with only 2 phases, the "Does Not Exist" and the "Method-Ready Pool" phase, because it does not preserve conversational state, which is the big characteristic of this EJB.

SLSB Lifecycle, from book "Oreilly Enterprise Javabean 3.1, 6th Edition"

Life-cycle Events
@PostConstruct
@PreDestroy

When going from the "Does Not Exist" to the "Method-Ready Pool", the no-argument constructor is called by the contained; next the container proceeds with code injection where applicable and the calls the method that is annotated with the @PostConstruct annotation. It is not mandatory the presence of this method, but if it exists, then it can be called with a what-so ever name, but it need to be void, have no arguments and must not throw checked exceptions.

In the "Method-Ready Pool", the bean is ready to attend the execution of the business methods.

When the container decides to destroy the bean, the bean goes back to the "Does not Exist" state and the method annotated with @PreDestroy is called, if it exists. Like the @PostConstruct method, it follows the same rules: can have anyname, needs to be void, have no arguments and must not throw checked exceptions.