There are requirements and considerations that are unique
to developing applications that use the Cross-Release Class Loading
(CRCL) feature.
Configuration Parameters Syntax
The
general syntax rules for setting configuration parameters are described
in CONNECTION_IMPLEMENTATION_API_LOCATIONS. In addition,
keep in mind the following syntax points:
- When you set a URL that uses the WSI transport protocol, the URL
that is specified in a configuration parameter must exactly match
the URL that's specified in creating the Connection object. Failure
to match the URL specifiers results in the implementation API not
getting loaded for the connection that uses the URL.
For
example, the URL in the configuration parameter:
~http://svr1:9080/wsi/FNCEWS40SOAP/
~ 6.0.2.3
Does not exactly match the URL that is used
to create the Connection object:
conn520
= Factory.Connection.getConnection("http://svr1:9080/wsi/FNCEWS40SOAP",
parameters);// Note the missing forward slash ("/") at the end of
the URL.
- The delimiter character for separating key/value pairs in a configuration
parameter is defined by you.
Debugging
- A common error in developing a CRCL application is misconfiguring
a Connection object, which forces CRCL to use the
visible API instead of loading the server-appropriate implementation
API for the connection. Verify that the FileNet P8 connection configurations
in your application are correct. If you use the CONNECTION_IMPLEMENTATION_API_LOCATIONS and CONNECTION_IMPLEMENTATION_API_URLS connection
parameters, verify that the connection URLs are correctly mapped to
the locations of the Jace.jar files.
- Use client-side logging. Trace the "API" subsystem at the debug
log level. In the resultant log, review the "CRCL" debug messages.
Verify that CRCL finds the server-appropriate Jace.jar file
for each FileNet P8 connection.
Best practices
- Only put the Jace.jar file for the visible
API on the application class path. Do not put the Jace.jar files
of the implementation APIs on the class path.
- Be aware of the supported features in the Content Platform Engine releases to which your
cross-release application connects. The application should gracefully
handle unavailable features in Content Platform Engine releases.
- Do not attempt to mix objects that are obtained from different
implementation APIs. For example, do not copy properties from one
release to another, and don't use an object from one release as a
property value or method argument with an object of another release.
If you do so, it usually results in exceptions due to Java type incompatibilities.
- Applications must never make direct use of non-exposed API classes
(com.filenet.apiimpl.*). That rule is a fundamental
assumption of the CRCL implementation. Using non-exposed classes in
a CRCL environment generally leads to Java™ type
incompatibility exceptions, though their occurrence might seem random
or intermittent.