|
Problem(Abstract) |
A test version of a RAR installed for use at the server
level is ignored. Applications deployed within the node dependent on the
test version of the Resource Adapter will fail since the test version of
the Resource Adapter is not actually available for use in the node. |
|
|
|
Cause |
Resource Adapters are always installed at the node level.
This is the way the Administrative Console was designed. This is also
described in the Information Center. This presents a problem whenever a
new version of the Resource Adapter becomes available. It is impossible to
configure a test version of the Resource Adapter in the same node with the
production Resource Adapter. |
|
|
Resolving the
problem |
The final solution for having multiple RARs active in a
node looks like this:
- remove the RAR from the node level
- package each version of the RAR into its own EAR
- deploy the RAR applications into the appropriate servers.
There can only be one RAR application per server. Applications needing the
new RAR must be deployed with the new RAR EAR. Applications needing the
old RAR must be deployed with the old RAR EAR.
- Set the application classloader policy to "Single"
- Define connection factories for the resource adapters and
provide unique Java™ Naming and Directory Interface (JNDI) names for each.
Re-map resource references in other applications to the appropriate JNDI
names.
- Force the RAR EAR application to initialize ahead of the
other applications so that the connection factory JNDI name gets
registered in the server before the other applications need it. Do this by
making the RAR EAR application Starting Weight numerically lower than the
other application Starting Weights in the server. The path to Starting
Weight is Applications -> Enterprise Applications ->
your_application -> Starting Weight
|
|
|