axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: More symbolTable woes
Date Fri, 15 Jul 2005 22:07:34 GMT
Please open a bunch of issues and we will resolve them one by one :)

-- dims

On 7/15/05, Steve Green <steveg@epok.net> wrote:
> Ok..  issue #2 is bogus, but now there might be an issue #3 and #4 :)
> 
> I saw this in the CVS log and without thinking tried "-
> unwrapArrays=no".
> 
>         There is a WSDL2Java flag "unwrapArrays" which defaults to
>         "yes".  If you set it to "no", we won't do this stuff (and
>         remain backwards compatible).
> 
> Of course, this is wrong for 2 reasons but for my sample xsd, it worked
> like a charm because of the 'w' in "unwrapArrays".  When I replaced that
> with a simple "-w", everything appears to be back to normal.
> 
> So issue #1 stands.  As far as I can tell, the xsd is valid so it seems
> to me that wsdl2java should accept it with or without wrapping.
> 
> Issue #3:
> 
> "-w" works great but using "--wrapArrays" in its place caused this
> error.
> 
>         The wsdl URI was not specified.
> 
> It seems that wrapArrays is configured with ARGUMENT_OPTIONAL, and if
> it's the last argument before the wsdl, --wrapArrays will swallow up the
> wsdl argument.  I haven't tried it, but I assume changing the flag to
> ARGUMENT_DISALLOWED will fix the problem.
> 
> Issue #4?:
> 
> Does this mean that you can never specify a long form option with
> missing optional argument before the wsdl argument?
> 
> On Fri, 2005-07-15 at 15:02 -0400, Davanum Srinivas wrote:
> > Can u please try the --noWrapped flag on w2j?
> >
> > -- dims
> >
> > On 7/15/05, Steve Green <steveg@epok.net> wrote:
> > > Developers,
> > >
> > > This morning, I endeavored to try my code against the latest CVS for
> > > axis.  After some fiddling, I believe I've come across some regression
> > > from axis 1.2.x.
> > >
> > > Issue #1:
> > >
> > > Unwrapped arrays is causing problems with xsd that once worked fine.
> > > It's probably not strictly regression since this is a new feature (new
> > > to me at least) but since unwrapped arrays is the default, it feels like
> > > regression.  The problem seems to lie in the fact that the array
> > > elements are from an element "ref" rather than a complex "type".
> > >
> > > This is the sample that I've been playing with.  With unwrapped arrays,
> > > wsdl2java complains about SomeElement being referenced but not defined.
> > > Without unrapped arrays, everything works as it once did.
> > >
> > >       <complexType name="AnotherType">
> > >         <sequence>
> > >           <element ref="tns:SomeElement" maxOccurs="unbounded"/>
> > >         </sequence>
> > >       </complexType>
> > >
> > >       <element name="SomeElement" type="tns:SomeType"/>
> > >
> > >       <complexType name="SomeType">
> > >         <sequence>
> > >           <xs:element name="a" type="xs:string"/>
> > >         </sequence>
> > >       </complexType>
> > >
> > >
> > > Issue #2:
> > >
> > > I've started seeing problems with wsdl references to elements too.  I
> > > have not investigated this problem much at all, so I am posting this
> > > message with the hopes that someone recognizes the symptoms and saves me
> > > a bit of trouble.
> > >
> > > For example, from the liberty alliance discover service wsdl.  This is
> > > working fine with with Axis 1.2.
> > >
> > >   <message name="Modify">
> > >     <part name="body" element="disco:Modify"/>
> > >   </message>
> > >
> > > wsdl2java will now complain about {urn:liberty:disco:2003-08}Modify not
> > > being defined, when in fact it is defined.  Using
> > > Type="disco:ModifyType" works fine.
> > >
> > > ~S
> > >
> > >
> >
> >
> --
> Steve Green <steveg@epok.net>
> 
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Mime
View raw message