We also need to add setMessage(com.sun.xml.ws.api.Message). Also this
doesn't give an ability to position the Tube whereever the developer
wants. Still it will be good idea to pursue it. So this will be part of
handler chain and gets into the runtime via deployment descriptor ?
Different topic: It would have been easy for the implementations, had
there only been one type of handlers instead SOAP and
Logical(getPayload() calls could have been added to SOAPMessageContext).
Jitu
Kohsuke Kawaguchi wrote:
>
> If this can be done without too much work, I think this is excellent.
> I agree with your analysis that asking them to write assembler is just
> too much.
>
> What's your take on the implementation complexity?
>
>
> Rama Pulavarthi wrote:
>
>> Now and then, we suggest users to write their own Tube to process the
>> Message like Handler and plug it in by writing a a new
>> TubelineAssembler.
>> The reason for this is using SOAPHandler might be costly as they work
>> on DOM based SOAPMessage.
>>
>> Writing a TubelineAssembler for simple uses is difficult. How about
>> we provide a new Protocol Handler to work on com.sun.xml.ws.Message.
>>
>> public interface MessageHandler<T extends RIMessageContext>
>> extends Handler<T> {
>>
>> }
>>
>> public interface RIMessageContext
>> extends MessageContext {
>>
>> /** Gets the message from this message context
>> *
>> * @return The contained message; returns <code>null</code> if no
>> * message is present in this message context
>> **/
>> public com.sun.xml.ws.api.Message getMessage();
>> }
>>
>>
>> This way user can write a simple handler extending MessageHandler and
>> can be plugged in easily.
>>
>> thanks,
>> Rama Pulavarthi
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
>> For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net
>>
>>
>
>