Considerations for isolated resource providers
There are some design considerations that you should be aware of when working with resource providers specified to be isolated in their own class loaders.
Be aware of the following issues that we need to address if we 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 appserver 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.
Related tasks
Set Resource Adapters
Set a JDBC provider and data source
Use mail