Users Guide

6 Use SSL-J with J2EE Applications and Application Servers
RSA BSAFE SSL-J 6.2.6 Troubleshooting Guide
Where applications have their own copies of SSL-J, it is possible for one application
to use a combination of classes from its own SSL-J jars along with those from an
RsaJsse instance registered by a different application. Problems such as unexpected
ClassCastExceptions and unrecognized AlgorithmParameters can result.
This can even occur with a single application as it is being upgraded as there may
briefly be two instances of the same application. If applications are using different
versions of SSL-J then the problems can be more severe.
Explicit use of Provider Instances
SSL-J can be used as a library bundled within the EAR file of each application that
uses it. This provides all the usual advantages of an Application Server environment
such as allowing different applications to use different versions of SSL-J, however
there are some restrictions:
• SSL-J jars should not be loaded by a parent class loader and visible to the
application in addition to the private jars bundled in the EAR file.
– SSL-J jars should not be installed in the
ext directory of the Java runtime.
– SSL-J jars should not be added to the Application Server’s class path unless
the Application Server provides a mechanism to isolate this from applications.
• Applications must be written to exclusively use the
getInstance methods that
take a provider instance. To reduce the number of RsaJsse instances created, they
could:
– Pass around the RsaJsse instance
– Place the RsaJsse instance as a static field on an application class.
• Applications should not register the RsaJsse instance as that can interfere with
other applications.