In the Java EE realm, you can migrate existing code to the observer pattern without too much
hassle. Java EE observers are usually accompanied by dependency injection, which uses @inject ,
and factories, which use @produces .
The observer pattern's greatest strength, the decoupling of classes, is also its greatest weakness. As
control of the observable moves to the observer, you lose track of the application's workl ow. Vision
becomes obscured as one event triggers another. A complicated implementation of the observer
pattern can be a nightmare to debug, so it is recommended that you keep the implementation simple.
Avoid multiple layers of observers; using just one layer (or a few) is ideal.
To help future and present developers determine the purpose of your code, the name of an observer
should rel ect its purpose. In addition, you should incorporate the reason for the observation into
the name of its methods, expressing the purpose of the class.
In the Java EE realm, existing code can be migrated to the observer pattern without much hassle.
Java EE observers are usually accompanied by dependency injection ( @inject ) and factories
( @produces ). The heavy and unnecessary use of observers may introduce hard to follow and debug
systems. However, since most developers are used to observers from UI or web frameworks, they
usually have an instinct to use in the right context most of the time.
Whenever you see a resource subject to change and callers trying to capture the data from subject,
never hesitate to use the observer pattern. Transaction‐sensitive observers offer functionality that
was not easily available in earlier versions. In the BEFORE _ COMPLETION phase, you can cancel the
current transaction by invoking the setRollbackOnly method, thus allowing nontransactional
operations to be performed within a transactional phase. If an exception is thrown, the entire
transaction can be rolled back.
During the IN _ PROCESS phase, which spans the entire transaction, observable events can be i red
and observed immediately. This can be implemented as a type of progress monitor or logger.
A call to an observer method blocks the event emitter and is synchronous but can be made
asynchronous by annotating the observer method @Asynchronous . (See Chapter 9, “Asynchronous,”
for more information about how to use this annotation.) You should take care when making
observers of the BEFORE _ COMPLETION phase asynchronous because the setRollbackOnly method is
ineffective, and the transaction will not be rolled back. The asynchronous method occurs in a new
You have seen how Java's core observer pattern's implementation has advanced in Java EE 7
and how it can be made sensitive to the transactional phase of the events that it observes. Its
implementation completely decouples business logic from the observer, leaving only the event type
and qualii er to connect them. This has raised the concern that vision over the relationship is lost,
although this can be mitigated by appropriately naming the class and methods and illustrating the
relationship in the class's documentation.
The transactional phase sensitivity has added another dimension to the observer pattern. It provides
integration between the observer methods and the transaction, allowing rollbacks to be invoked.