PQ97214: LOOKUP OF A FORMATHANDLER WHEN A MESSAGE PART HAS AN ELEMENT ATT AND DEFINITION POINTS TO A NAMED COMPLEXTYPE DOES NOT WORK | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
APAR status Closed as program error. Error description The lookup of a formatHandler when a message part has an element attribute and the element's type definition points to a named complexType does not work. Description of WSDL message and schema <message name="dashboardCreateRequestMessage"> <part name="dashboardCreateRequest" element="xsd1:dashboardCreateNotification"></part> </message> The element is defined like this: <xs:complexType name="dashboardUpdateNotification_Type"> <xs:sequence> ... <xs:sequence/> <xs:complexType/> <xs:element name="dashboardCreateNotification" type="dashboardCreateNotification_Type"/> If the element's type definition points to a named complexType then the bean and formatHandler generation is done using the QName of the complexType, and not the element. If the element's type definition points to an anonymous complexType then the bean and formatHandler are generated using the QName of the element, and the text "Element" is added to the local name. Currently the WSIFUtils.getFormatHandler() does not look at the element definition to determine its type definition is named or anonymous. It needs to be updated to do this so that it can match the rules followed in bean and formatHandler generation. In the above example, WSIFUtils.getFormatHandler() looks for a formatHandler named <namespace of element mapped to package + binding>.DashboardCreateNotificationFormatHandler versus <namespace of type mapped to package + binding>.DashboardCreateNotification_TypeFormatHandler If the type is determined then the two stage lookup to determine whether to append "Element" would not need to happen.Local fix Check the problem description.Problem summary **************************************************************** * USERS AFFECTED: Users of WSIF using the Native JMS provider * * or the Apache SOAP provider. In the * * WSDL, a message part has an element * * attribute and the elements type definition * * points to a named complexType. The WSIF * * client has been generated using WebSphere * * Studio Application Developer Integration * * Edition, or a BPEL process. * **************************************************************** * PROBLEM DESCRIPTION: The lookup of a formatHandler when a * * message part has an element attribute * * and the elements type definition * * points to a named complexType does not * * work. * * * * Description of WSDL message and schema * * * * <message * * name="dashboardMessage"> * * <part name="dashboard" * * element= * * "xsd1:dashboardCreate"> * * </part> * * </message> * * * * The element is defined like this: * * * * <xs:complexType * * name= * * "dashboardUpdate_Type"> * * <xs:sequence> * * ... * * <xs:sequence/> * * <xs:complexType/> * * <xs:element * * name="dashboardCreate" * * type= * * "dashboardUpdate_Type"/> * * * * In WebSphere Studio Application * * Developer Integration Edition, if * * the elements type definition points * * to a named complexType then the * * bean and formatHandler generation is * * done using the QName of the * * complexType, and not the element. * * * * If the elements type definition * * points to an anonymous complexType * * then the bean and formatHandler are * * generated using the QName of the * * element, and the text "Element" is * * added to the local name. * * * * Currently the WSIF method * * WSIFUtils.getFormatHandler() * * does not look at the element * * definition to determine if its type * * definition is named or anonymous. * * This therefore does not match the * * rules followed in bean and * * formatHandler generation in * * WebSphere Studio. * * * * In the above example, * * WSIFUtils.getFormatHandler() looks * * for a formatHandler named * * <namespace of element mapped to * * package + * * binding>. * * DashboardCreateFormatHandler * * versus * * <namespace of type mapped to * * package + binding>. * * DashboardUpdate_TypeFormatHandler * * * * If WSIF does not find the * * FormatHandler class, a default * * FormatHandler will be used which * * generally performs a .toString() * * on the input part. Therefore, the * * Web Services request will not appear * * in the format the Service is * * expecting, and an error will occur * * in the Service. * **************************************************************** * RECOMMENDATION: * **************************************************************** WSIF has been fixed to examine the element, if a FormatHandler cannot be found using existing mechanisms. If the element has a named type, the QName of the type is used to look up the FormatHandler.Problem conclusion This fix is scheduled to be delivered in WebSphere Application Server version 5.1.1 cumulative fix 4. Please refer to the recommended updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
Publications Referenced
|
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 00W
Software edition:
Reference #: PQ97214
IBM Group: Software Group
Modified date: Feb 9, 2005
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.