© Copyright International Business Machines Corporation 2005. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
This release notes file contains late-breaking information about limitations and known problems and workarounds for the WebSphereR Integration Developer test client.
The integration test client requires Java classes, which are arguments in method signatures, to have a zero argument constructor as well as the appropriate get/set methods for each of its fields.
The integration test client executes outside the scope of any application transactions, and so does not participate in transactions. Therefore, there is no support for emulating transaction rollbacks.
When moving or renaming the JavaTM implementation file in the emulation editor, the reference to the implementation (impl) file is not updated properly. This problem is due to a NullPointerException being thrown by the autobuild.
For a workaround, you need to turn off the ResourceMapper builder for the project that contains the programmatic emulator. To turn off the ResourceMapper builder, follow these steps:
- Right-click the module project and select Properties from the pop-up menu.
- In the properties page, select Builders in the left column.
- Clear the ResourceMapper check box on the right column.
This workaround lets the emulation editor update the reference to the Java implementation file properly.
Alternatively, if the workaround is not done, the emulation editor will report an error stating that the Java implementation file of the associated programmatic emulator was not found at the specified location. You can fix this error by closing and then reopening the programmatic emulator in the emulation editor, and then locating the missing Java implementation file.
The integration test client will start the WebSphereR Process Server 6.0 prior to invoking the test if the server has not already been started.
At that point, you can choose to start the server in either the debug mode or regular mode. If debug mode is chosen, the test client may invoke the test before the server is fully initialized. Subsequent invocations will run properly.
To work around this problem, either rerun the test if it initially fails, or start the server prior to invoking the test.
The integration test client only allows a component to be invoked using the synchronous invocation style.
For most components, this is fine since, even if the component only supports the asynchronous invocation style, the underlying SCA architecture will convert the synchronous invocation to an asynchronous invocation. But a component could support both invocation styles and could have different code paths depending on the invocation style.
You might want to test both code paths. In this case, you can either create a JavaR component that will perform the asynchronous invocation and invoke that component using the integration test client, or you can use another client such as a JSP page to invoke the component asynchronously.
The test client can not be used to invoke components that specify data using SOAP-encoded arrays.
Example XSD snippet:
..
<xsd:restriction base="soapenc:Array">
<xsd:attribute ref="soapenc:arrayType"
wsdl:arrayType="typens:ResultElement[]" />
</xsd:restriction>
..
To work around this problem, create a JavaR component to invoke the service. The test client can then be used to invoke the Java component.