I've attached to CXF1616 a demo maven project with my (simplified) WSDL to reproduce the bug.
When ASM dependency is included, the requet fails with NullPointerException Without this dependency, the request pass. 2008/5/29 Daniel Kulp <[EMAIL PROTECTED]>: > > asm 2.2.3 is our "preferred" version, so it should have worked. If you > remove asm jar from the classpath, a couple of codepaths have to revert to > using reflection based stuff. What it looks like is the reflect based > stuff is working ok, but there is a bug in the asm version. I added some > "debug" code into the asm stuff yesterday. Is there any chance you can > rerun with the latest snapshots with the asm jar and send me the new stack > trace? > > Dan > > > > > On May 29, 2008, at 3:05 AM, nicolas de loof wrote: > > This issue is definitely fixed by removing the asm.jar. >> >> As the error is really not comprehensible, is there any way cxf runtime >> could detect such icompatible JAR in classpath and warn the user for this >> ? >> >> Nico. >> >> 2008/5/28 nicolas de loof <[EMAIL PROTECTED]>: >> >> I've made more investigation as the test project I tried to package did >>> not >>> reproduce the issue. >>> >>> I found that removing asm 2.2.3 from the project classpath fixed my >>> issue. >>> >>> Is there something wrong with this version ? >>> >>> >>> 2008/5/28 Daniel Kulp <[EMAIL PROTECTED]>: >>> >>> >>> Any chance you can file a jira with a small test case? >>>> >>>> My major concern is "why is it getting into the wrapper helpers at all"? >>>> According to the JAXWS spec, the elements in the wrapper type must NOT >>>> be >>>> nillable. If there are nillable=true flag there, it cannot be >>>> considered >>>> unwrappable and thus must be code generated as "bare". Thus, the >>>> wrapper >>>> helpers shouldn't be invoked at all. >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>> On May 28, 2008, at 10:06 AM, nicolas de loof wrote: >>>> >>>> My issue is related to the following declaration : >>>> >>>>> >>>>> <element name="customerOrderUID" nillable="true" type="xsd:string" >>>>> minOccurs="0" maxOccurs="1"/> >>>>> >>>>> As you can notice, the schema set nillable="true" AND minOccurs="0" >>>>> This schema has not been writen by XSD experts, and from MSDN >>>>> documentation >>>>> I can read that nillable implies the element is required. >>>>> >>>>> Can you confirm this ? >>>>> >>>>> I can't find the same rule from the XSL Schema spec at >>>>> http://www.w3.org/TR/xmlschema-1/. Do you have any link to describe >>>>> this >>>>> XSD >>>>> rule ? >>>>> >>>>> Nico. >>>>> >>>>> >>>>> 2008/5/27 Benson Margulies <[EMAIL PROTECTED]>: >>>>> >>>>> Could you try the 2.0.6 release? If it still don't work, please make a >>>>> >>>>>> JIRA. >>>>>> >>>>>> On Tue, May 27, 2008 at 10:44 AM, nicolas de loof <[EMAIL PROTECTED] >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>>> >>>>>>> My WSDL types declares the "description" element with minOccurs="0" : >>>>>>> >>>>>>> <complexType name="DeliverLoyaltyAccountRequest"> >>>>>>> <sequence> >>>>>>> <element name="description" nillable="false" type="xsd:string" >>>>>>> minOccurs="0" maxOccurs="1"/> >>>>>>> ... >>>>>>> >>>>>>> >>>>>>> When I invoke the service (using SoapUI) it works fine with >>>>>>> <sch:description></sch:description> >>>>>>> or <sch:description/>, >>>>>>> but when I *remove *this XML element, I get a NullPointerException : >>>>>>> >>>>>>> Caused by: *java.lang.NullPointerException* >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> _33j.services.servicesmodification.schema.DeliverLoyaltyAccountRequest_WrapperTypeHelper1.getWrapperParts(Unknown >>>>>>> >>>>>> >>>>>> Source) >>>>>>> >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.apache.cxf.jaxws.interceptors.WrapperClassInInterceptor.handleMessage(* >>>>>>> >>>>>> >>>>>> WrapperClassInInterceptor.java:122*) >>>>>>> >>>>>>> I'm using cxf 2.0.5-incubator >>>>>>> >>>>>>> Did I miss something ? >>>>>>> >>>>>>> >>>>>>> >>>>>> --- >>>> Daniel Kulp >>>> [EMAIL PROTECTED] >>>> http://www.dankulp.com/blog >>>> >>>> >>>> >>>> >>>> >>>> >>> > --- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > > > >
