© Copyright International Business Machines Corporation 2006. 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 that pertain to one of the following tools:
- A component that does not have a release notes file of its own
- The entire WebSphereR Integration Developer product
WebSphereR Integration Developer V6 gives users the ability to rename file names and workspaces. Refactoring the changes to artifacts referencing the file will not occur.
With this in mind, caution should be taken when making changes to file names and workspaces.
Non-English characters, such as double-byte and bidirectional characters, should not be used for a module name when the application includes a Web interface with a JSP file.
The use of non-English characters results in a failure to invoke the Web interface, and issues the following error:
JSPG036E Resource /xxxxxWeb/index.jsp cannot be found.
The XML catalog is used primarily as a cache for performance improvement by avoiding unecessary Web access for internet-located schemas. As such, for all Web-based XSD imports, where the schemaLocation attribute points to a Web address, the XML catalog is always used first to resolve the import. If no entry is in the catalog, then it is accessed from the Web. For file-relative imports, where the schemaLocation attribute points to a file, the actual schema location is used to resolve the import.
The XML catalog can also be used to store system-specific schemas that are referenced in many schemas. An example of this is the BusinessGraph.xsd. In these cases, if an XSD import schemaLocation attribute points to a file that is not found in the file system, but the schema is in the catalog, then the catalog version is used. As a result, when sharing XSDs that use system schemas registered in the XML catalog, you should either include the system schema with the shared XSDs, or share the contents of the XML catalog.
You might receive errors indicating that a WSDL object or business object (or XSD type) cannot be found, but you cannot see any reason for the error, since the file containing the object resides in a dependent project.
Ensure that the file is in a WebSphereR Integration Developer module or a WebSphere Integration Developer library. The object might not be found if its file resides in a Java project even if that project is a dependent project.
Most often, these errors are displayed in the Problems view. You could also encounter them in the workbench's log file or in a message dialog box.
One way you might generate such an error is to drag an object from a Java project onto one of the WebSphere Integration Developer editors, creating a reference to that artifact in the file you are editing.
To work around the problem, move the file to a WebSphere Integration Developer library or a WebSphere Integration Developer module. Move the file to a WebSphere Integration Developer library if the object needs to be shared among several WebSphere Integration Developer modules.
A file called orbtrc<TIMESTAMP>.txt could be present in the WebSphereR Integration Developer home directory.
Testing has discovered no known issues as a result of the contents of this file. It can be safely ignored.