On a related note, I have been thinking about adding additional handler
apis to the spec to expose a more efficient representation of the
message, so whatever you work on, keep in mind that we might want to
expose it through the spec so it hopefully would not be RI specific.
Jitendra Kotamraju wrote:
> 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
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
>