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.
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.
- If you target a Liberty server and you are generating a bottom up JAX-WS Web service using the Web service wizard, you can receive a null pointer exception.
[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.The wsdlLocation 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.
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 the ejb-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 from webservicesclient.xml. Remove the incomplete component-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 the 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 the Web Services Explorer's ability to start operations, and therefore can be safely ignored.
- The 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, the 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.
- The Web Services Explorer imports WSDL without resolving relative import URLs. When you use the 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.
The 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 use WebSphere Developer Tools when it is installed in an Eclipse Mars.1 (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:
To work around this problem, install WebSphere Developer Tools in an Eclipse Mars.2 (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.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 folder EJBServiceClient/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 the ApplicationClientProject/imported_classes(class folder) entry. Add class folder ApplicationClientProject/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 the Using the AdminClient section of the Axis 1.4 User's Guide for more detail.