Hello, I run into the same problem today. Could you indicate when this fix will be available in the nightly builds?
Thanks a lot Oliver NEU: NZZ finfox, personal finance, die finanz- und vermögensplanung für private http://finfox.nzz.ch ECOFIN Research and Consulting AG Neumuensterallee 6 CH-8032 Zuerich +41 1 389 65 29 [EMAIL PROTECTED] www.ecofin.ch <http://www.ecofin.ch> > -----Original Message----- > From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] > Sent: Mittwoch, 13. März 2002 01:42 > 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 > > > > > > >
