Using SOAP 1.2 (typemapping="1.2" in the ant task) solved my problem #3
Long's and Long []'s are now generated correctly. I'm still working on problem #2. -M On 12/20/05, Mike DeHaan <[EMAIL PROTECTED]> wrote: > Well, that's the problem. The above wsdl does not map to a Long. > > For completeness: > > My Java property is: > > Long [] array_Long; > > and the wsdl generates as: > > ... > ... > ... > <complexType name="ArrayOf_xsd_long"> > <complexContent> > <restriction base="soapenc:Array"> > <attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:long[]"/> > </restriction> > </complexContent> > </complexType> > ... > ... > ... > <element name="array_Long" nillable="true" type="impl:ArrayOf_xsd_long"/> > > Running wsdl2java yields: > > long [] array_Long; > > -M > > On 12/20/05, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > This is correct. Both xsd:long with a nillable="true" attribute and > > soapenc:long map to Long. > > > > > > On 12/20/05, Mike DeHaan < [EMAIL PROTECTED]> wrote: > > > Yes. > > > > > > My Java property is: > > > > > > Long [] array_Long; > > > > > > and Generates as: > > > > > > ... > > > ... > > > ... > > > <complexType name="ArrayOf_xsd_long"> > > > <complexContent> > > > <restriction base="soapenc:Array"> > > > <attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:long[]"/> > > > </restriction> > > > </complexContent> > > > </complexType> > > > ... > > > ... > > > ... > > > <element name="array_Long" nillable="true" > > type="impl:ArrayOf_xsd_long"/> > > > > > > -M > > > > > > On 12/19/05, Dies Koper <[EMAIL PROTECTED]> wrote: > > > > Hello Mike, > > > > > > > > Regarding #3, do the types in the WSDL have the xsd:nillable set to > > > > "true"? In some cases I tried they did not (see below). > > > > I did not check whether these problems had already been reported in the > > > > BugDB. > > > > > > > > *(1) PRCENC -- primitive wrapper -- OK > > > > *(2) PRCENC -- primitive wrapper array -- OK > > > > *(3) RPCLITERAL -- primitive wrapper -- NG > > > > *(4) PRCLITERAL -- primitive wrapper array -- NG > > > > *(5) DOCLITERALWRAPPED -- primitive wrapper -- NG > > > > *(6) DOCLITERALWRAPPED -- primitive wrapper array -- OK > > > > > > > > Regards, > > > > Dies > > > > > > > > > > > > Mike DeHaan wrote: > > > > > Problem #3 > > > > > ======== > > > > > > > > > > After running java2wsdl -> wsdl2java > > > > > > > > > > java.lang.Long []'s are converted to primitive long []'s > > > > > > > > > > > > > > > -M > > > > > > > > > > On 12/19/05, Dies Koper <[EMAIL PROTECTED] > wrote: > > > > > > > > > >>Hi Mike, > > > > >> > > > > >>-H, --helperGen > > > > >> emits separate Helper classes for meta data > > > > >> > > > > >>(it doesn't seem to work for Enumerations) > > > > >> > > > > >>Regards, > > > > >>Dies > > > > >> > > > > >> > > > > >>Mike DeHaan wrote: > > > > >> > > > > >>>Pardon my confusion, but I was under the impression that generating > > > > >>>the wsdl/beans was a repeatable process and that I could include this > > > > >>>step as part of my build process. As my developers make changes to > > > > >>>beans and services, I want the build process to manage the creation > > of > > > > >>>the wsdl. > > > > >>> > > > > >>>I've discovered that if you remove the axis-generated functions > > > > >>>getTypeDesc(), getSerializer(), and getDeserializer() from the > > > > >>>generated beans, the wsdl re-generates perfectly. Is there a setting > > > > >>>or something I missed that prevents axis from adding these to the > > > > >>>beans? Or is there a setting to override their existence? > > > > >>> > > > > >>>-M > > > > >>> > > > > >>>On 12/18/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > > > >>> > > > > >>> > > > > >>>>Mike, > > > > >>>> > > > > >>>>You should run java2wsdl only once to get you started, once you have > > a > > > > >>>>WSDL that you like you should check it into your version control > > > > >>>>system and treat it as "gold" :) please don't try to run java2wsdl > > -> > > > > >>>>wsdl2java -> java2wsdl. > > > > >>>> > > > > >>>>thanks, > > > > >>>>dims > > > > >>>> > > > > >>>>On 12/18/05, Mike DeHaan <[EMAIL PROTECTED]> wrote: > > > > >>>> > > > > >>>> > > > > >>>>>I'm having a few issues with generated classes using java2wsdl and > > > > >>>>>wsdl2java ant tasks. I'm not sure if these issues belong to wsdl4j > > or > > > > >>>>>axis, nor am I sure if these are user errors, but hopefully someone > > > > >>>>>will be able to provide some insight. > > > > >>>>> > > > > >>>>>Problem #1 > > > > >>>>> > > > > >>>>>Duplicating steps: > > > > >>>>>1) Create a service with a single function that takes a bean as a > > parameter. > > > > >>>>>2) write the bean to contain a single private property with the > > datatype long [] > > > > >>>>>3) create the getters and setters for the bean > > > > >>>>>4) compile the project and package it as a jar file > > > > >>>>>5) run java2wsdl referencing the jar file and the service > > > > >>>>>6) at this point you should have a correct, good looking wsdl. > > > > >>>>>7) Run wsdl2java to have axis create the new bean (this overwrites > > > > >>>>>your handwritten bean) > > > > >>>>>8) compile the project and package it as a jar file > > > > >>>>>9) run java2wsdl referencing the jar file and the service > > > > >>>>>10) at this point, the wsdl will now have a bad definition of the > > bean. > > > > >>>>>11) Running wsdl2java will generate a bean with a private Long > > value > > > > >>>>>instead of a long []. > > > > >>>>> > > > > >>>>>I'm probably leaving out a lot of details, so please let me know > > where > > > > >>>>>I can fill in the blanks. > > > > >>>>> > > > > >>>>>Problem #2 > > > > >>>>> > > > > >>>>>beans that implement interfaces will not have their interfaces > > carried > > > > >>>>>over to the wsdl-generated beans. > > > > >>>>> > > > > >>>>>Am I missing a setting? > > > > >>>>> > > > > >>>>>Problem #3 > > > > >>>>> > > > > >>>>>Long []'s are converted to long []'s > > > > >>>>> > > > > >>>>>Thanks in advance for your help, > > > > >>>>> > > > > >>>>>-M > > > > >>>>> > > > > >>>> > > > > >>>> > > > > >>>>-- > > > > >>>>Davanum Srinivas : http://wso2.com/blogs/ > > > > >>>> > > > > >>> > > > > >>> > > > > >> > > > > > > > > > > > > > > > > > > > > >
