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.

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:
    1. View the WSDL URL in a browser, and save the WSDL file to your local computer.
    2. Remove the complexType element from the WSDL file.
    3. Copy the WSDL file to the WEB-INF/wsdl directory of your OSGi bundle project.
    4. 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.
  • [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

Important: Applicable to WebSphere Application Server traditional
  • 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

  • When you use the Web Services Wizard to generate a JAX-WS Client, the getDispatch() method of the generated Proxy class does not have the namespace part of the QName of the Port filled in. One solution is to use the namespace of the Port directly from the WSDL file.
  • If you click Cancel part way through any of the web services wizards, you might have web service entries in the deployment descriptors and generated files in your workspace. Manually delete these files after you close the wizard.
  • Web service wizards fail to publish EARs:

    Problem: When a remote server is created by using the stub run time, the EAR is not published.

    Cause: The web service wizard has no way to find out whether a server can be started or not.

    Solution: In any perspective where the Servers view is available, right-click the remote server and select Add and Remove Projects. Select the project and add it to the server.

  • Web service wizards unable to consume the chosen project type:

    Problem: If you attempt to run the web service wizards on and EAR that contains a Java™ EE application client project with the Install service on server option selected, or an EJB project that does not contain an EJB, you cannot use the wizard to generate the web service.

    Cause: The web service wizards check to ensure that they can consume the type of project that is selected on page three of the wizard. If they cannot, the wizard prevents you from continuing.

    Solution: If you cancel of the wizard and rerun with Install service on server not selected, or add an EJB to the EJB project, you can progress in the wizard.

  • If a WSIL file is selected in the workspace and then the web services wizard is launched, the wizard states that the selection is invalid because a WSDL file must be selected from the WSIL file. To resolve this, click Browse in the web services wizard to select a specific WSDL file.
  • The web services wizard might produce an error during creation of a web service if the name of the target web project includes non-latin-1 characters. The problem occurs because the web services code generators calculate HTTP URLs based on the project name, and non-Latin-1 characters are not permitted in HTTP URLs. To resolve this, use project names that contain only latin-1 characters.
  • If you have more than one EAR project in the workspace, and you select Enterprise JavaBeans in an EJB project and launch the web service wizard the selected enterprise bean might not be selected when the wizard launches. In the Select Service Implementation dialog box, the EAR project that is selected is the first EAR in the workspace alphabetically, not the EAR associated with the EJB project that contains the bean. To resolve this in the Select Service Implementation dialog box, manually select the wanted EAR project.
  • When you select to monitor web services traffic on the first page of the web services wizard, occasionally the TCP/IP Monitor view does not display automatically. You can open the view manually by selecting Windows > Show view > Debug > TCP/IP Monitor. The request and response for the web service is shown on that view.

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 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 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 Using the AdminClient section of the Axis 1.4 User's Guide for more detail.