There are some design considerations that you should be aware of
when working with resource providers that you have specified to be isolated
in their own class loaders.
Be aware of the following issues that you need to address if you isolate
a resource provider in it's own class loader:
- Client container
The client container does not manage the class
path of resource providers, so resource providers that are isolated will not
be supported in the client container.
- Multiple resource provider versions per application
If an application
refers to resources from multiple versions or implementations of the same
resource provider, then all of the resource providers that are referenced
must be isolated.
- References to isolated resource provider classes
If a module
directly refers to classes that are loaded by an isolated resource provider,
which means the module has import statements of resource provider classes,
the following restrictions are in place:
- The module can only refer to resources from one version or implementation
of an isolated resource provider. This is an inherent class loading restriction,
because a module class loader can only refer to one version of a class.
- The module cannot perform direct JNDI lookup without the use of Java EE
resource reference meta-data. This restriction is required, because without
resource reference metadata the application server has no mechanism to link
the class loader of the module to the class loader of the isolated resource
provider.
The relational resource adapter does not generally allow direct access
to resource provider classes, so these restrictions will typically only affect
modules that implement the com.ibm.websphere.rsadapter.WSCallHelper class.
For mail providers, these restrictions will most likely be in place, because
the javax.mail API relies heavily on classes rather than interfaces. Therefore,
the implementation details are necessarily part of the API.