Yeah, I must admit CXF does't exactly follow the JAXWS spec 3.7, that's could be issues when use code-first way with exception. Could you please create a jira to track this issue, and patch are welcomed, as always. Thanks Freeman
－－－－－－－－－－－－－ Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: http://weibo.com/u/1473905042 On 2012-10-18, at 下午2:24, Ivan wrote: > Yes, with current CXF generation codes, I could see only in/out jaxb > classes are generated in WrapperClassGenerator (if I did not miss anything > here ;-)) > But, think that it is required to generate the fault jaxb class per the > description in 3.7 Service Specific Exception, XmlAccessType.FIELD will not > workaroud all the issues, at least for the message property in the > Exception hierarchy. > > 2012/10/18 Freeman Fang <[email protected]> > >> Hi, >> >> If there's no FaultBean in @webFault and no getFaultInfo method in >> TestException class, currently CXF will put the exception class itself as >> the FaultBean, so you need ensure field in TestException could be >> marshaled/unmarshalled correctly by jaxb, so just add >> @XmlAccessorType(XmlAccessType.FIELD) in TestException can do the trick, >> －－－－－－－－－－－－－ >> Freeman(Yue) Fang >> >> Red Hat, Inc. >> FuseSource is now part of Red Hat >> Web: http://fusesource.com | http://www.redhat.com/ >> Twitter: freemanfang >> Blog: http://freemanfang.blogspot.com >> http://blog.sina.com.cn/u/1473905042 >> weibo: http://weibo.com/u/1473905042 >> >> On 2012-10-17, at 下午11:53, Ivan wrote: >> >>> Hi, with the exception class below , it only has a get*** method for the >>> info property. >>> >>> @WebFault >>> public TestException extends Exception { >>> private String message = null; >>> >>> public TestException () { >>> } >>> >>> public TestException (String message) { >>> this.message = message; >>> } >>> >>> public String getInfo() { >>> return message; >>> } >>> >>> } >>> >>> With the RI wsgen command, the generated schema type is : >>> RI: >>> <xs:complexType name="TestException"> >>> <xs:sequence> >>> <xs:element name="info" type="xs:string" minOccurs="0"/> >>> <xs:element name="message" type="xs:string" minOccurs="0"/> >>> </xs:sequence> >>> </xs:complexType> >>> </xs:schema> >>> >>> If using CXF tool or on the CXF runtime, the generated schema type for >> the >>> exception is : >>> >>> <xs:element name="TestException" type="tns:TestException"/> >>> <xs:complexType name="TestException"> >>> <xs:sequence/> >>> </xs:complexType> >>> >>> With the JaxWS spec, 3.7 Service Specific Exception, considering that no >>> getFaultInfo or faultBean in WebFault annotation is provided, the >>> special algorithm will be used to map the exception to jaxb bean, one of >>> the steps write below: >>> >>> For each getter in the exception and its superclasses, a property of the >>> same type and name is added to >>> the bean. All the getter methods except >>> getMessagefromjava.lang.Throwabletype hierarchy >>> are excluded from the list of getters to be mapped. >>> >>> Seems that only getter method is required, with the current codes in >> static >>> boolean JAXBContextInitializer.isMethodAccepted, it will check whether >> the >>> setter exists. I am thinking that this is not required for this scenario, >>> as we only need to read the information from the user exception. >> Thoughts ? >>> >>> -- >>> Ivan >> >> > > > -- > Ivan
