Exception messages
Exception messages, like trace messages, convey information about problems. The
difference is that exception messages are tailored more directly to support teams
familiar with adapter source code, and therefore need not be translated.
Treat text included in exception messages as you would text for trace messages. In
general, exception messages are not directed at general users but rather at support
teams who have the ability to investigate adapter source code. For that reason,
exception messages need not be translated and can be hard-coded. If an exception
is thrown and the customer must be informed of the problem, use an appropriate
log message, which can be translated, to inform the customer; refrain from simply
printing out the contents of the exception.
When implementing an adapter exception message, do the following:
v
Define subclasses of
ResourceException
where appropriate and include relevant
properties on these implementations
v
Raise the exception with a message that can be hard-coded in English.
v
Print the stack trace of the exception using the trace API. This allows support
teams to see all exception details.
v
When appropriate, the exception messages raised should have a corresponding
high level message in the
LogMessages.properties
file. The developer should log
this high-level message after raising the exception so that general users can see
an explanation of the error in their native language.
Changing the Java logging API settings
To change the Java logging API settings, you modify a permission in the adapter
deployment descriptor.
The following permission must be added to the adapter deployment descriptor,
represented as the file
ra.xml
in the RAR package:
permission java.util.logging.LoggingPermission "control";
In the
ra.xml
file, this permission is as follows:
<security-permission>
<security-permission-spec>
grant {
permission java.util.logging.LoggingPermission "control";
};
<security-permission-spec>
<security-permission>
Validating the code
Validate your adapter implementation by unit testing it outside of a JCA container
(unmanaged testing mode). You can then deploy to the target runtime server and
test instances of the adapter (managed testing mode).
Unmanaged and managed testing modes are not mutually exclusive. A thorough
testing regime typically involves unit testing to debug and refine adapter
components prior to managed testing in the target environment.
Testing enterprise metadata discovery (EMD) of the adapter
Testing the EMD implementation means testing if the adapter can connect to EIS
and discover services from an existing metadata repository or is able to build the
appropriate interactions with the EIS by generating the required artifacts.
WebSphere Adapter development overview
193
Summary of Contents for WebSphere Adapters
Page 2: ......
Page 6: ...iv WebSphere Adapters WebSphere Adapter Toolkit User Guide...
Page 220: ...214 WebSphere Adapters WebSphere Adapter Toolkit User Guide...
Page 224: ...218 WebSphere Adapters WebSphere Adapter Toolkit User Guide...
Page 225: ......
Page 226: ...Printed in USA...
