Java Reference
In-Depth Information
public interface ResourceProcessor {
void begin(DeploymentSession session);
void process(String name, InputStream stream)
throws ResourceProcessorException;
void dropped(String resource) throws ResourceProcessorException;
void dropAllResources() throws ResourceProcessorException;
void prepare() throws ResourceProcessorException;
void commit();
void rollback();
void cancel();
}
Deployment Admin connects resource types to resource processors using the
Resource-Processor
header in the resource entry of the deployment-package mani-
fest. You use this header to specify the service
PID
of the needed resource processor.
These kinds of services are provided by
customizer
bundles delivered as part of the
deployment package.
You indicate a customizer bundle by using the
DeploymentPackage-Customizer
header in the resource entry for a bundle in the deployment package. This allows
Deployment Admin to start customizers first, so they can provide the necessary
ResourceProcessor
services to handle the deployment package content. Resource
processors may result in new file system artifacts but can perform other tasks like data-
base initialization or data conversion, for example. Each nonbundle resource should
have a processor associated with it. With the necessary resource processor specified,
Deployment Admin is able to process all resource package content.
Before processing of the deployment package starts, Deployment Admin creates a
session in which all actions needed to process the package will take place. A session isn't
visible to clients of the
DeploymentAdmin
service; it's used to join the required resource
processors to the processing of the deployment package. If an exception is raised during
a session by any of the resource processors
or the session is canceled, Deployment
Admin rolls back the changes. As we men-
tioned before, this may only be a best-
effort rollback, but it's normally sufficient
to leave the framework in a consistent
state. If no exceptions are raised during a
session, Deployment Admin commits the
changes. During a commit,
Deployment-
Admin
tells all joined
ResourceProcessor
services to prepare and subsequently com-
mit their changes. Figure 10.6 shows the
transactional aspects of the session.
As you can see, this essentially pro-
vides a two-phase commit implementa-
tion. It allows
ResourceProcessor
s to
cleanly handle rollbacks. But rolling back
Begin
Operations
Yes
No
Ok?
Prepare
Roll back
No
Ok?
Yes
Commit
Figure 10.6
Transactional aspects of a session
