No, but it's an interesting idea. Exceptions themselves cannot be JAXB objects as you cannot feed them into JAXB without JAXB barfing due to superclasses not being mappable. Thus, we always need to do some special processing.
For java first, we know the mapping for each field is pretty simple. Thus, we call jaxb for each field directly. However, we don't have that luxury with wsdl first as the schma type for the fault can be very complex with extensions and substitution groups and all kinds of nasty things. Thus, we definitely want to pass the jaxb generated things into jaxb. One option COULD be to leave the getFaultInfo stuff there and just generate getter/setter methods for each thing on the fault info bean that just forward in. That may run into the next issue: Spec compliance - the current behavior is required for JAX-WS spec compliance. Not sure if we added additional mappers if that would cause an issue or not. Dan On Thu October 8 2009 10:49:01 am Lukasz Lichota wrote: > By default JAX-WS, while generating faults, creates a class that extends > Exception which contains a JAXB object (generated from the XSD element) > used for <details> section of soap fault. > > This article suggest it's possible to have one class for both of the above > while starting with Java > http://www.ibm.com/developerworks/webservices/library/ws-jaxws-faults/index > .html > > Is there a way to do this starting from WSDL that is to force generating > one class (that both extends Exception and contains fields from <details> > in other words Exception that is JAXB object)? > -- Daniel Kulp [email protected] http://www.dankulp.com/blog
