+1
This is good stuff (and the bug was reported by a user). -- Tom Jordahl Macromedia -----Original Message----- From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 7:42 PM To: [EMAIL PROTECTED] Cc: '[EMAIL PROTECTED]' Subject: RE: duplicate element name in different complexType elements (I have a fix..should I commit for beta?) I have a fix in my sandbox that fixes the problem presented by Tom. The fix also has improves the way root elements are handled, per chat dialogue with Glen last week. I feel confident in the fix, should I go ahead and commit it. (I will assume that no response means yes.) ----------------------------------------------------------- Here is a more detailed description of the changes: Changes for anonymous type processing in WSDL2Java Symbol Table. Problem Description: An anonymous type is a type (simpleType or complexType) that does not have a name. Here is an example: ... <element name="foo"> <complexType> .... </complexType> The WSDL2Java symbol table uses the QName as the key to access a symbol table entry. Since an anonymous type does not have a qname, the qname of the containing element is used. Unfortunately it is possible that the element is not unique, which results in a symbol table collision. (As reported by Tom Jordahl.) Solution: 1) The first change is to give anonymous type elements unique names to avoid symbol table collisions. The unique name must be something that can be determined by examining the dom tree. I chose to use the following format for the local name: <qname-of-containing-simple/compleType>.<qname-of-element> If the anonymous type is used to define a global element, its local name is: .<qname-of-element> 2) Change to the SchemaUtils code that queries the qname of an anon type. 3) Change to the JavaWriterFactory.javifyNames method. This method is enhanced to ensure that anonymous java type name collisions don't occur. If a name collision is detected, the suffix ANON### is appended to the name of the anonymous class java name to prevent the collision (### is a unique number). 4) Changed the refattr.wsdl to have a anonymous type collision similar to the one submitted to axis-dev by Tom Jordahl. Phase 2: Anonymous types for root elements are not put into the symbol table. Instead the emitter writer classes use the DefinedElement information when generating code. This can lead to some fuzzy logic and subtle bugs. (I promised Glen last week that I would look at changing this code.) Solution: 1) Anonymous types for root elements are added to the symbol table just like all other anonymous types. 2) The JavaWriterFactory.resolve() method is modified to ensure that the java name of the root DefinedElement matches the java name of its anonymous DefinedType. 3) Changed Utils.getNested to get the anonymous DefinedType. 4) Changed the emitter writeTypes() method to only process Type entries (not Element entries). This is an improvement, writeTypes only deals with types! 5) Changed the deploy and stub writers to not register type mappings for Elements. (Before the deploy and stub writers had to examine the Element to see if it had an anonymous type...) * There are a number of existing testcases that use anonymous types for root elements. All of the tests passed. Rich Scheuerle XML & Web Services Development 512-838-5115 (IBM TL 678-5115) Tom Jordahl <tomj@macromedia. To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> com> cc: Subject: RE: duplicate element name in different complexType elements. 03/12/2002 10:18 AM Please respond to axis-dev +1 on number two. I like detecting the collision and munging the name. +1 on waiting to make them inner classes. :-) -- Tom Jordahl -----Original Message----- From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 11:03 AM To: [EMAIL PROTECTED] Subject: Re: duplicate element name in different complexType elements. Tom, Ouch! The problem is that the embedded return elements both have anonymous types. The emitter needs to generate a name for the anonymous types, so it chooses the most reasonable name (return). This results in a collision. Brainstorming...... 1) I like the fact that we use the name "return" for the anonymous type. This is a nice solution in the majority of cases. But this can result in a collision, like this testcase... 2) We could detect the collisions and munge the name of the anonymous type....i.e. name one return_anon### (where ### is a unique number). This would require changing the referent element in the symbol table to refer to the new special qname. 3) Could always generated nested anonymous types as inner classes? This might be the ultimate solution, but there is no support for this yet in the emitter. Plus I don't want to complicate the Bean class until after the meta data issue is resolved. So I think 2 is the correct approach for now. Agree ? Comments ? Rich Scheuerle XML & Web Services Development 512-838-5115 (IBM TL 678-5115) Tom Jordahl <tomj@macromedia. To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> com> cc: Subject: duplicate element name in different complexType elements. 03/12/2002 09:48 AM Please respond to axis-dev This WSDL: http://services.xmltoday.com/vx_engine/wsdl.vep?flight.wsdl Gives this error: java.io.IOException: urn:vgx-flight:return already exists The error is correct, there are two instances of "return" in the same namespace, but they are in different complexType declarations. I am afraid this might be hard to address given the way we put entries in the Symbol Table. Rich, could you take a look at this? Can we process this WSDL correctly? -- Tom Jordahl Macromedia Server Development
