[
https://issues.apache.org/jira/browse/CXF-899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-899:
----------------------------
Fix Version/s: 2.0.2
Assignee: Daniel Kulp
Affects Version/s: (was: 2.1)
2.0.1
> Missing getFaultInfo() fallback patch - use @WebFault bean as faultInfo if
> getFaultInfo() is not present
> --------------------------------------------------------------------------------------------------------
>
> Key: CXF-899
> URL: https://issues.apache.org/jira/browse/CXF-899
> Project: CXF
> Issue Type: Improvement
> Components: JAX-WS Runtime
> Affects Versions: 2.0.1
> Environment: Platform independent.
> Reporter: Zarar Siddiqi
> Assignee: Daniel Kulp
> Fix For: 2.0.2
>
> Attachments: FalbackForMissingGetFaultInfo.patch
>
>
> CXF has interpreted the spec as saying that the getFaultInfo() method MUST be
> specified on a class annotated with @WebFault.
> On page 21 of the JAX-WS 2.0 Spec it says that the class annotated with
> @WebFault may have two constructors + the getFaultInfo() method. Since we're
> not enforcing the two constructors, why enforce the getFaultInfo()? There's
> absolutely no need to do this. The place where this is being enforced is the
> WebFaultOutInterceptor whose behavior should be changed to using the
> @WebFault class as the faultInfo bean if getFaultInfo() is not present. This
> is a good fallback method for cases where the user does not want the
> additional exception to part of the WSDL for whatever reason. In most cases,
> one exception is more than good enough to represent a fault.
> This also helps those who are migrating from XFire as they can't afford to
> change the WSDL for existing users. I don't know how much emphasis the CXF
> team places on backwards compatibility but this alone is a very good reason
> to make this change.
> The current behavior is that if the getFaultInfo() method is not specified
> then then the @WebFault annotated class' properties become part of the WSDL.
> The only thing stopping this from being functionally correct is the code in
> WebFaultOutInterceptor which requires a getFaultInfo() method.
> I think this offers greater flexibility to users while still complying with
> the spec. This way those who'd like to specify getFaultInfo() can do so and
> those who don't want to, don't have to. I also brought this up on the commits
> mailing list:
> http://www.nabble.com/forum/ViewPost.jtp?post=12055118&framed=y
> I'm also uploading a patch for WebFaultOutInterceptor which has the fallback
> behavior of using the @WebFault bean as the faultInfo if getFaultInfo() is
> not present.
> Thanks,
> Zarar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
