Jitiu,
Right - no cast is required in handler. So, how to you recommend I
create a SOAPFault instance inside the endpoint? Is it OK to do
SOAPFactory.newInstance() ? Or should I use injection?
Thanks,
Mark
Jitendra Kotamraju wrote:
> Bobby Bissett - Javasoft wrote:
>
>>> Interesting. Is that a legit use of SAAJ - to add a Fault to a
>>> message, and then throw away the message, and just use the fault to
>>> construct a SOAPFaultException - which ends up getting serialized to
>>> a different SOAP message?
>>
>>
>>
>> I hope so. :) Actually, in the RI code where the handlers are called,
>> if a handler throws a ProtocolException then this is exactly what I
>> do -- I throw away the header and any body contents, then use the
>> body and add fault elements to it. No use creating a whole new
>> message object when the old one can just be changed.
>>
>>>
>>> This approach works inside a handler where the MessageContext can be
>>> cast so SOAPMessageContext, but inside the endpoint, that produces a
>>> class cast exception.
>>
>>
>>
> You shouldn't require to cast in handler too. The API takes care of
> all that using generics, the signatures of your handler impl reflect
> SOAPMessageContext. Why do you require to cast ?
>
> You cannot cast WebServiceContext.getMessageContext() object to
> SOAPMessageContext. From endpoint, you can only modify property bag
> ie. MessageContext.
>
> Jitu
>
>> I'm not sure what happens at the endpoint, but in the handlers at
>> least you should always get a SAAJ SOAPMessage so this is ok. Maybe
>> Jitu can comment again about the endpoint case.
>>
>> Cheers,
>> Bobby
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
>> For additional commands, e-mail: users-help_at_jax-ws.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: users-help_at_jax-ws.dev.java.net
>