Java Reference
In-Depth Information
MORE ABOUT HANDLERS
There's a lot to working with handlers, so it's worth taking a moment to illustrate some of their darker
corners. Here are several things to consider when working with handlers in general:
▪ JAX-WS handlers have a life cycle that is managed by the container. The life cycle defines two
methods, similar to EJB 3 life cycle methods. The first is a method annotated with
@PostCon-
struct
, which acts as an initializer. The container will always call this method before calling
any other method. The second is a method annotated with
@PreDestroy
, which can perform
clean up before the handler instance is removed. You can define these life cycle methods in your
handler if you wish to receive callbacks from the container notifying you of these events. These
methods must have a
void
return type and take no arguments.
▪ If a
RuntimeException
is thrown during handler processing, the method annotated with
@PreDestroy
will be invoked so you have an opportunity to do cleanup before the handler in-
stance is removed.
▪ Containers can pool handler instances if they like, but they aren't required to. If handler instances
are pooled, they will be associated with only a single port type.
▪ Handlers are stateless. The container does not have to use the same handler instance when invok-
ing the
handleMessage
or
handleFault
methods because of the potential to pool instances.
Handlers do not maintain any client-specific state across requests.
▪ The transactional context in which handlers run is dictated to them by their associated com-
ponent.
Handlers
are
not
allowed
to
specify
their
own
transactions
using
javax.transaction.UserTransaction
.
▪ The security context in which handlers run is dictated to them by the container. A handler may
not perform security checks using role-based authorization, and cannot access the principal asso-
ciated with the request.
▪ Different threads can be used to invoke each handler, and containers are not required to use the
same thread to invoke a handler as it uses to invoke its service implementation.
▪ You can declare that your handler will process certain headers in the WSDL using the
getHead-
ers
method. This returns a
Set<QName>
. It's OK to return null if your handler doesn't process
any headers or your WSDL doesn't define any.
▪ Logical handlers are always executed before all protocol handlers. Even if you define them as
interspersed within your handler chain, they will be sorted with logicals first.
▪ Handlers are allowed to specify the
@Resource
annotation to define injectable resources for
their use if they are running inside a managed environment (i.e., a container).
