WebSphere Process Server (WPS) might be slow to start up when using schemas, such as Spring components, in a limited network
When an application that uses Spring components is deployed to WebSphere Process Server, the WebSphere Process Server server takes a long time to startup. The WebSphere Process Server server has limited network access and cannot reach the http://www.springframework.org site.
This issue occurs even if the application is not a Service Component Architecture (SCA) application.
Log files or ArtifactLoader trace might indicate delays that are similar to the following message:
[9/20/11 13:09:16:264 EDT] 0000000a XMLParser W java.net.SocketException occurs during processing http://www.springframework.org/schema/tool/spring-tool-2.0.xsd: Connection timed out:could be due to invalid address.
The .xsd files in the Spring .jar files contain references to other .xsd files that are located remotely using the schemalocation value. The schemalocation value refers to the following remote site: http://www.springframework.org
<xsd:import namespace="http://www.springframework.org/schema/tool" schemaLocation="http://www.springframework.org/schema/tool/spring-tool-2.5.xsd"/>
If your server does not have network access to this site, then the server waits for the timeout period to connect to the URL that is specified for the schemaLocation value. If there are many "imports" to unreachable URLs, this process can add up to significant delays.
During the startup process, the actual subsystem that does the look up is the ArtifactLoader system in WebSphere Process Server. This system must scan all artifacts to index to be aware of all possible artifacts. During this scan, the system also looks up all declared "imports" to remote schemas. This index is used solely for WebSphere Process Server Business Object functionality and does not interact or interfere with third party functionality. This indexing takes place even if the artifact or the entire application is not involved with a WebSphere Process Server scenario.
This issue can occur on any server that has slow or no network access to locations that are specified by the schemaLocation value in XSD files. Although this issue often occurs when you use Spring components, it might occur with any XSD files that have remote schemaLocation values.
Diagnosing the problem
You can use ArtifactLoader trace to identify the delay and the specific XSD files that have remote schemaLocation values.
For more information on setting up ArtifactLoader trace, see Collect troubleshooting data for artifact loader problems with WebSphere Process Server.
For this specific problem, the following trace specification provides the most comprehensive information:
Resolving the problem
The ArtifactLoader does not have the capability to override the schemaLocation values that are declared within the files. However, completing either of the following steps might resolve the issue:
- Modify the Spring Java™ archive (.jar) files and change all the XSD files that have a remote schemalocation value to either:
- Remove the schemaLocation reference.
- Point to a locally accessible copy of the file.
- Remove the schemaLocation reference.
- Modify your machine (Hosts file) to map the schemaLocation host name to the local host IP address (127.0.0.1). Although this approach does not change functional behavior, it causes the error to occur immediately, which removes the delays. You can implement this modification if the XSD definitions are not used in a WebSphere Process Server scenario (typically for Spring component usage, or non-SCA modules run on WebSphere Process Server).
More support for:
WebSphere Process Server
Software version: 6.1, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 6.1.2, 18.104.22.168, 22.214.171.124, 126.96.36.199, 6.2, 188.8.131.52, 184.108.40.206, 220.127.116.11, 7.0, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52
Operating system(s): AIX, HP-UX, IBM i, Linux, Solaris, Windows, z/OS
Reference #: 1567328
Modified date: 14 June 2012