The fix should be in the latest nightly build.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Egger Oliver
<oliver.egger@eco To: [EMAIL PROTECTED]
fin.ch> cc:
Subject: RE: duplicate element name in
different complexType elements (I h
03/15/2002 04:33 ave a fix..should I commit for beta?)
AM
Please respond to
axis-dev
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
>
>
>
>
>
>
>
