[Version 5.0.2 and later]Troubleshooting command-line tools for Web services based on Web Services for J2EE

This topic discusses troubleshooting problems related to using command-line tools during the development and implementation of Web services that based on the Web Services for Java 2 platform, Enterprise Edition (J2EE) specification.

Java2WSDL and WSDL2Java command-line tools

Multiprotocol port component restrictions with JSR109 Version 1.0 and 1.1

JSR 109 specification validation errors occur when deploying an EAR file that contains a WSDL file with http, jms and ejb bindings generated by the Java2WSDL tool.

The JSR 109 specification requires each port component defined in the webservices.xml deployment descriptor file to refer to unique <servlet-class> elements in web.xml file (for a JavaBean implementation) or a unique <session> element in ejb-jar.xml file (for an EJB implementation). The servlet and session EJB are located in the webservices.xml file represented by <servlet-link> or <ejb-link>.

The WSDL2Java tool maps the ports found in a WSDL file to port components in the generated webservices.xml file. If a single Web service has multiple bindings, in addition to a port for each of these bindings, the webservices.xml file contains multiple port components that should all point to the same EJB (<session>) or JavaBean (<servlet-class>). Because of the JSR109 restrictions, the webservices.xml file is not valid and errors occur during deployment.

The error displays as follows:

Error in <module> : CHKW6030E: Implementation class <class> referred to by port 
components<port1> and <port2>. (JSR109 1.0: 7.1.2).																												
Here is the error with sample data:

Error in WebSvcsInSession20EJB.jar : CHKW6030E: Implementation class WSMultiProtocol 
referred to by port components WSMultiProtocolJMS and WSMultiProtocolEJB.(JSR109 1.0: 7.1.2).																												

You can work around the restriction by creating multiple <session> EJB definitions within the ejb-jar.xml file that all point to the same implementation class, home interface and remote interface. You can still use the same classes, but the ejb-jar.xml file <session> definitions that reference the classes and interfaces must be duplicated.

The following is an example of the webservices.xml file. Look for the classes and interfaces:

<webservices>
  <webservice-description>
    <webservice-description-name>WSMultiProtocolService</webservice-description-name>
    <wsdl-file>META-INF/wsdl/WSMultiProtocol.wsdl</wsdl-file>
    <jaxrpc-mapping file>META-INF/WSMultiProtocol_mapping.xml</jaxrpc-mapping file>
    <port-component>
      <port-component-name>WSMultiProtocolEjb</port-component-name>
      <wsdl-port>
        <namespaceURI>http://ejb.pli.tc.wssvt.ibm.com</namespaceURI>
        <localpart>WSMultiProtocolEjb</localpart>
      </wsdl-port>
      <service-endpoint-interface>com.ibm.wssvt.tc.pli.ejb.WSMultiProtocol
			</service-endpoint-interface>
      <service-impl-bean>
        <ejb-link>WSMultiProtocol</ejb-link>
      </service-impl-bean>
    </port-component>
    <port-component>
		<port-component-name>WSMultiProtocolJMS</port-component-name>
      <wsdl-port>
        <namespaceURI>http://ejb.pli.tc.wssvt.ibm.com</namespaceURI>
        <localpart>WSMultiProtocolJMS</localpart>
      </wsdlport>
      <service-endpoint-interface>com.ibm.wssvt.tc.pli.ejb.WSMultiProtocol
			</service-endpoint-interface>
      <service-impl-bean>
        <ejb-link>WSMultiProtocol_2</ejb-link>
      </service-impl_bean>
		</port-component>
        <port-component>
       		<port-component-name>WSMultiProtocolJMS</port-component-name>
      <wsdl-port>
        <namespaceURI>http://ejb.pli.tc.wssvt.ibm.com</namespaceURI>
        <localpart>WSMultiProtocolJMS</localpart>
      </wsdlport>
      <service-endpoint-interface>com.ibm.wssvt.tc.pli.ejb.WSMultiProtocol
			</service-endpoint-interface>
      <service-impl-bean>
        <ejb-link>WSMultiProtocol_3</ejb-link>
      </service-impl_bean>
		</port-component>
	</webservice-description>
</webservices>

The following is an example of the ejb-jar.xml file. Look for the classes and interfaces must and how they are duplicated:
<ejb-jar-id="ejb-jar_ID">
	<display-name>WebSvcsInsSession20EJB</display-name>
	<enterprise-beans>
		<session-id="WSMultiProtocol">
			<ejb-name>WSMultiProtocol</ejb-name>
			<home>com.ibm.wssvt.tc.pli.ejb.WSMultiProtocolHome</home>
			<remote>com.ibm.wssvt.tc.pli.ejb.WSMultiProtocol</remote>
			<ejb-class>com.ibm.wssvt.tc.pli.ejb.WSMultiProtocolWebSvcsBean</ejb-class>
			<session-type>Stateless</session-type>
			<transaction-type>Container</transaction-type>
			<ejb-ref-id="EjbRef_1082407586720">
				<description></description>
				<ejb-ref-name>ejb/BeneficiarySession</ejb-ref-name>
				<ejb-ref-type>Session</ejb-ref-type>
				<home>com.ibm.wssvt.tc.pli.ejb.BeneficiarySessionHome</home>
				<remote>com.ibm.wssvt.tc.pli.ejb.BeneficiarySession</remote>
				<ejb-link>PolicySession20EJB.jar#BeneficiarySession</ejb-link>
			</ejb-ref>
			<ejb-ref-id="EjbRef_1082407586790">
				<description></description>
				<ejb-ref-name>ejb/PolicySession</ejb-ref-name>
				<ejb-ref-type>Session</ejb-ref-type>
				<home>com.ibm.wssvt.tc.pli.ejb.PolicySessionHome</home>
				<remote>com.ibm.wssvt.tc.pli.ejb.PolicySession</remote>
				<ejb-link>PolicySession20EJB.jar#PolicySession</ejb-link>
			</ejb-ref>
		
		
		<session-id="WSMultiProtocol_2">
			<ejb-name>WSMultiProtocol_2</ejb-name>
			<home>com.ibm.wssvt.tc.pli.ejb.WSMultiProtocolHome</home>
			<remote>com.ibm.wssvt.tc.pli.ejb.WSMultiProtocol</remote>
			<ejb-class>com.ibm.wssvt.tc.pli.ejb.WSMultiProtocolWebSvcsBean</ejb-class>
			<session-type>Stateless</session-type>
			<transaction-type>Container</transaction-type>
			<ejb-ref-id="EjbRef_1082407586720_2">
				<description></description>
				<ejb-ref-name>ejb/BeneficiarySession</ejb-ref-name>
				<ejb-ref-type>Session</ejb-ref-type>
				<home>com.ibm.wssvt.tc.pli.ejb.BeneficiarySessionHome</home>
				<remote>com.ibm.wssvt.tc.pli.ejb.BeneficiarySession</remote>
				<ejb-link>PolicySession20EJB.jar#BeneficiarySession</ejb-link>
			</ejb-ref>
			<ejb-ref-id="EjbRef_1082407586790_2">
				<description></description>
				<ejb-ref-name>ejb/PolicySession</ejb-ref-name>
				<ejb-ref-type>Session</ejb-ref-type>
				<home>com.ibm.wssvt.tc.pli.ejb.PolicySessionHome</home>
				<remote>com.ibm.wssvt.tc.pli.ejb.PolicySession</remote>
				<ejb-link>PolicySession20EJB.jar#PolicySession</ejb-link>
			</ejb-ref>
		
		
		<session-id="WSMultiProtocol_3">
			<ejb-name>WSMultiProtocol_3</ejb-name>
			<home>com.ibm.wssvt.tc.pli.ejb.WSMultiProtocolHome</home>
			<remote>com.ibm.wssvt.tc.pli.ejb.WSMultiProtocol</remote>
			<ejb-class>com.ibm.wssvt.tc.pli.ejb.WSMultiProtocolWebSvcsBean</ejb-class>
			<session-type>Stateless</session-type>
			<transaction-type>Container</transaction-type>
			<ejb-ref-id="EjbRef_1082407586790_3">
				<description></description>
				<ejb-ref-name>ejb/BeneficiarySession</ejb-ref-name>
				<ejb-ref-type>Session</ejb-ref-type>
				<home>com.ibm.wssvt.tc.pli.ejb.BeneficiarySessionHome</home>
				<remote>com.ibm.wssvt.tc.pli.ejb.BeneficiarySession</remote>
				<ejb-link>PolicySession20EJB.jar#BeneficiarySession</ejb-link>
			</ejb-ref>
			<ejb-ref-id="EjbRef_1082407586790_3">
				<description></description>
				<ejb-ref-name>ejb/PolicySession</ejb-ref-name>
				<ejb-ref-type>Session</ejb-ref-type>
				<home>com.ibm.wssvt.tc.pli.ejb.PolicySessionHome</home>
				<remote>com.ibm.wssvt.tc.pli.ejb.PolicySession</remote>
				<ejb-link>PolicySession20EJB.jar#PolicySession</ejb-link>
			</ejb-ref>
		</session>
				
	

Avoiding application errors after uninstalling an interim fix, a cumulative fix, or a fix pack

If an application uses functions that are provided by a particular fix and you remove the fix, the application can throw an error message. If you remove a fix, retest your applications to check for errors. Redeploy any applications that throw an error message because of the missing fix.

For example, suppose you install Fix Pack 1 on WebSphere Application Server Version 5.1.0. You create a stock quote Web service named StockQuote. The WSDL2Java tool is used in a deployer role and generates a ServiceLocator class that extends the AgnosticService class. The AgnosticService class is new in Version 5.1.1.

If you uninstall the fix pack, the application is using a new Web services class (AgnosticService) that Version 5.1.0 does not support. The application throws the following error:

java.lang.NoClassDefFoundError:
	Error while defining class:
	com.ibm.ws.wsfvt.test.stockquote.StockQuoteServiceLocator
	This error indicates that the class:
	com.ibm.webservices.multiprotocol.AgnosticService
	could not be located  while defining the class:
	com.ibm.ws.wsfvt.test.stockquote.StockQuoteServiceLocator 																														
You need to redeploy the application on the Application Server to emit code that does not use the Version 5.1.1 Web services class.

Using a proxy server to access the Internet while executing the WSDL2Java command causes your connection to time out

If you are using an environment that requires a proxy server to access the Internet during the execution of the WSDL2Java command, the WSDL2Java command might not find the Internet information because the proxy server has the potential to time out. For example, if the input wsdl file is located on the Internet instead of a local drive, and you need to retrieve it from the Internet, the WSDL2Java command fails to find it because the proxy server timed out.

You can work around this problem by editing the WSDL2Java.bat file when using a Windows operating system or the WSDL2Java.sh file if you are using a UNIX operating system. These files are located in the <install_root>/WebSphere/AppServer/bin directory.

If you are using a Windows operating system, set your proxy host and port values in the WSDL2Java.bat file:

PROXY_INFO="-Dproxy.httpHost=yourPproxyHost -Dproxy.httpPort=yourProxyPort
If you are using a UNIX operating system, set your proxy host and port values in the WSDL2Java.sh file:
PROXY_INFO="-Dproxy.httpHost=yourProxyHost -Dproxy.httpPort=yourProxyPort

Emitter failure error occurs when running the WSDL2Java command on a WSDL document containing a JMS-style endpoint URL

If you run the WSDL2Java command-line tool on a WSDL document that contains a JMS-style endpoint URL , for example jms:/..., the urlprotocols.jar file that contains the custom protocol handler for the JMS protocol must be in the CLASSPATH. The error WSWS3099E: Error: Emitter failure. Invalid endpoint address in port <x> in service <y>: <jms-url-string> can be avoided by making sure the urlprotocols.jar file is in the CLASSPATH.

To add the urlprotocols.jar file to the CLASSPATH:

On Windows platforms, edit the install_root\bin\setupCmdLine.bat and locate the line which sets the WAS_CLASSPATH environment variable. Add %install_root%\lib\urlprotocols.jar to the end of the line that sets the WAS_CLASSPATH environment variable.

On UNIX platforms, edit the install_root/bin/setupCmdLine.sh file and add $install_root/lib/urlprotocols.jar to the end of the line that sets the WAS_CLASSPATH environment variable.

Make sure to use the proper deliminator character for your platform, for example, use a semi-colon (;) for Windows platforms and a colon (:) for UNIX platforms.


Related tasks
Troubleshooting Web services based on Web Services for J2EE



Searchable topic ID:   rwbs_trbcommand
Last updated: Jun 21, 2007 9:56:50 PM CDT    WebSphere Application Server for z/OS, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/rwbs_trbcommand.html

Library | Support | Terms of Use | Feedback