Known problems and limitations for web service applications
Various known problems and limitations apply when you are working with WebSphere® Developer Tools. Issues include, among others, problems when you use a secured WebSphere Application Server and when you use the web services wizards.
For more information about limitations and troubleshooting tips, see Known problems and limitations for WebSphere Application Server Developer Tools for Eclipse Beta.
The limitations that you might encounter when you work with web services are divided into the following sections:- General limitations for web services
- Problems encountered when you use a secured WebSphere Application Server
- Problems encountered when you use the web services wizards
- Problems encountered when you use WebSphere JAX-WS runtime environment and JAXB
- Limitations when you create a web service client
- Limitations of the web service sample JSPs
- Web Services Explorer problems
- Problems when you use web services command-line tool
General limitations for web services
Using the test client JSP, if you select Enable asynchronous invocation and then invoke the service, the following error message displays: The Response Class is not defined.
You can work around the problem by testing the service synchronously.
Liberty does not support publishing to UDDI. However, Publish the Web service is still selected in the Web service wizard.
You can work around this problem. Clear the Publish the Web service check selection. The Web Service Publication page also still appears; clear all check boxes on this page.
Liberty does not support thin clients by default.
You can work around this problem. To add support for thin clients, you can install WebSphere Application Server traditional, and obtain the thin client JAR files from the runtimes folder. Then, you can add them to your Java project.
You can also use a different project type, such as a Web project.
The Generic Service Client is not supported on OS X. Use the WSE or sample JSPs to test your Web service.
- If you target a Liberty server and you are generating a bottom up JAX-WS Web service by using the Web service wizard, you can receive a null pointer exception.
- When you select the REST template in the New Web Project wizard, the initial JAX-RS facet version might be 2.0. This must be manually changed to 1.1 in order for the IBM® WebSphere Application Server Liberty JAX-RS Library and IBMRestServlet Class to appear pre-filled in the REST Service configuration page.
- [Liberty]
Creating a JAX-WS Web service client with the Web service wizard might fail if the JAX-WS web
service is in an OSGi bundle project. This problem can happen if you create a Web service in an OSGi
bundle project, do not select Copy WSDL to project in the Web service wizard,
and then deploy the OSGi bundle project to Liberty.This process might fail when you create the JAX-WS client from the Web service URL with the Web Services Description Language (WSDL) file appended. The tools display the following error message:
[ERROR] A class/interface with the same name "sample.ObjectFactory" is already in use. Use a class customization to resolve this conflict.
This process might fail because the service WSDL file on the Liberty server that the Web services wizard uses to create the client contains the following element:<xs:complexType name="objectFactory"> <xs:sequence></xs:sequence> </xs:complexType>
To work around this problem, you can select Copy WSDL to project in the Web service wizard when you create a Web service project in an OSGi bundle project. As an alternative, you can complete the following steps:- View the WSDL URL in a browser, and save the WSDL file to your local computer.
- Remove the
complexType
element from the WSDL file. - Copy the WSDL file to the WEB-INF/wsdl directory of your OSGi bundle project.
- Add the
wsdlLocation
attribute to the@WebService
element of your Web service Java source file.ThewsdlLocation
attribute must have a value that points to your local WSDL file. The following line is an example of this attribute.wsdlLocation="WEB-INF/wsdl/Sample.wsdl"
Tip: If you create the Web service in a web project instead of an OSGi bundle project, then the Web service client generation is successful. The tools do not display an error message. - [WebSphere Application Server traditional] After you create a
JAX-RS web project, you can use the tools to change the facet version. When you change the facet
version between JAX-RS 1.1 and 2.0, the class path container does not automatically update the
included .jar files. You can prompt the tools to update the included
.jar files by updating any other facet levels, such as the JPA facet levels.
Then, you can reverse your changes to the JPA facet levels.Tip: If you create a JAX-RS project without specifying a facet level, the tools use JAX-RS 2.0 by default.
Problems encountered when you use a secured WebSphere Application Server
You might encounter the following error message: SSLSocketFactory error message: java.net.SocketException: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
Before you use the Web Services Explorer, generating sample JSPs, creating a web service or client from an HTTPS WSDL file, or deploying an Axis web service, you must configure the workbench to communicate with a server via Secure Sockets Layer (SSL). Information about this task can be found here: Problems working with a secured server using SSL connections.
You might encounter the following error message: Error opening socket: javax.net.ssl.SSLHandshakeException: unknown certifcate
To use the web services wizard to retrieve an HTTPS WSDL or to use the Web Services Explorer against a secured WebSphere Application Server, complete the steps in Configuring the IBM JRE to talk to a secured WebSphere Application Server.
Problems encountered when you use the web services wizards
Problems encountered when you use WebSphere JAX-WS runtime environment and JAXB
- If you try to create a schema library where there are different schema documents that use the same namespace, the function generates projects and code with compilation errors. The compilation errors are in the ObjectFactory.java file. The problem is that, for a schema, the JAXB code is generated into a package whose name is based on the targetNamespace of the schema. An ObjectFactory.java class is also generated into this package and its contents are based on all of the schemas of the same namespace. It cannot be split or duplicated to resolve the compilation errors because the runtime environment expects this one class per package. Thus the schema library feature works only if all the schema dependencies are in different targetNamespaces.
- New in JAXB, the IBMWebSphere JAX-WS runtime environment
is no longer responsible for resolving name collisions. When these
collisions occur, you might see an error message such as
error: Property "property_name" is already defined.
The following tutorial provides more information and some examples of how to work around naming collisions: The Java web services Tutorial: Customizing JAXB Bindings
Limitations when you create a web service client
When you deploy a web service client to an EJB project, on the proxy configuration page you must pick the EJB to which the web service client is scoped. This selection is a requirement defined by JSR-109 where the component-name of a
component-scoped-refs
element must match theejb-name
of an EJB in the module.When there is at least one EJB in the project, no errors occur. However, if there are no EJBs in the project, the options on the proxy configuration page are editable and have a default value equal to the service name from the WSDL suffixed by "EJB". Furthermore, the client wizard displays a warning that indicates that the deployment is incomplete because the web services client is not scoped to an existing EJB. You can fix this error by creating an EJB with the same name as the component-name used in
webservicesclient.xml
.However, if you choose to end the client creation by canceling from the wizard, the wizard does not remove the incomplete
component-scoped-refs
fromwebservicesclient.xml
. Remove the incompletecomponent-scoped-refs
manually before redeployment.
Limitations of the web service sample JSPs
- Web service sample JSPs have no support for methods that take in arrays or collections as parameters. Such methods are omitted from the sample JSP's Methods pane.
Web Services Explorer problems
- When Web Services Explorer loads WSDL files that use multiple inline schemas, warning messages
are generated for types that are referenced across these schemas. The warning message is similar to:
Reference of type <qualified_type_name> isn't resolved.
These are warnings and not errors and do not interfere with Web Services Explorer's ability to start operations, and therefore can be safely ignored. - Web Services Explorer does not support invocation of web services by authenticating proxy servers that use a protocol other than HTTP Basic Authentication, such as NTLM. If the Web Services Explorer fails to connect to the chosen web service for this or any other reason, it displays in its results pane the error IWAB0135E An unexpected error has occurred followed by information about the failure as retrieved from the HTTP response. To resolve this issue, switch to an HTTP Basic Authenticating proxy server.
- Web Services Explorer has problems when you switch from the source view to the form view if the schema uses choices that contain sequences. If you are using a choice element in a complexType, the choice contains two or more elements including a sequence, and you switch from the form view to the source view, Web Services Explorer might be unable to correctly convert the corresponding XML fragment in the source view back into the form view without losing data. To resolve this problem, start the sequence from the form view when the data is initially entered. When this configuration occurs, it is not recommended the source view be used. If the source view is used, do not switch back to the form view.
- Web Services Explorer imports WSDL without resolving relative import URLs. When you use Web Services Explorer, there is an issue when you import a WSDL from the WSDL Page to the workspace. If the option Import as a service reference to a WSIL document is chosen this refers to the original URL of the WSDL and therefore all relative imports are reachable. If Import WSDL Document is chosen and the WSDL file contains relative imports, these imports are no longer reachable, leaving the copy of the WSDL difficult or impossible to process elsewhere in the tools. If there are relative imports in the WSDL you are importing, use the WSIL method. If there is a need for a copy of the WSDL, manually check for relative imports after the import to resolve any broken links.
- Web Services Explorer does not work if you use the Java 8 version of the Java virtual machine (JVM) in Eclipse. If you start Web Services Explorer with Java 8, the main window displays HTTP Error 500. To resolve this issue, use Java 7 as the Eclipse JVM, or use the generic service client.
- If you install WebSphere Developer Tools in an Eclipse
4.5.1 workbench, then Web Services Explorer does not work. If you try to use Web Services Explorer,
then the Response/Status section of Web Services Explorer is blank, and the tools
display the following error:
Page load failed with error: cannot parse response.
To work around this problem, install WebSphere Developer Tools in an Eclipse 4.5.2 workbench. For more information about this problem, see Bug 476132 - Web services explorer issue with Java 8 - Page load failed with error: cannot parse response.
Problems when you use web services command-line tool
- Importing an EAR containing an EJB Client generated by the command-line
tools using Java EE 1.4 into
the workspace results in compilation errors. To fix the errors, right-click
the EJB project, and select Properties. Go
to Java Build Path, and select the Libraries tab.
Remove the
EJBClientProject/imported_classes(class folder)
entry. Add class folderEJBServiceClient/imported_classes/Meta-inf/classess
. Click OK. - [WebSphere Application Server traditional] After you import an EAR containing an
Application Client generated by the command-line tools using Java EE 1.4 into the workspace, you get a
ClassNotFoundException
error when you run the client. To fix the errors, right-click the Application Client project, select Properties. Go to Java Build Path, and select the Libraries tab. Remove theApplicationClientProject/imported_classes(class folder)
entry. Add class folderApplicationClientProject/imported_classes/Meta-Inf/classess
. Click OK. - The Web Services Ant tasks that target the Axis runtime handle the generation of web services
but not the deployment of them. As a result, Axis web services that are created using the Ant tasks
are not reachable on the running server until you manually deploy your services with the Apache Axis
native AdminClient utility. Deploy the generated
deploy.wsdd file in subdirectories under the
WebContent/WEB-INF directory of the web project to Axis manually using the Axis
AdminClient tool. Refer to
Using the AdminClient
section of the Axis 1.4 User's Guide for more detail.