Vivek Pandey wrote:
> There was another idea that Jitu mentioned during lunch.
>
> Where we provide something like TubeDelegate and anyone implementing
> it and provides it in classpath or thru META-INF/services will be
> loaded and will be given chance to process the message. It will keep
> it simple and Tube specific way to work the delegation keeping Handler
> approach untouched or issue relating how to plug it in the runtime etc.
>
> -vivek..
Yes, I was thinking we could always keep a dummy tube on the server
side. If it finds a tube delegate, it delegates those calls. Similarly,
on the client side. That means, a developer needs to create a tube and
create META-INF/services entry for the runtime to locate it. Will that
ease any complexity ? One issue is that, how do we do per endpoint basis ?
Jitu
>
> Rama Pulavarthi wrote:
>
>> It should not be a problem to implement. We need to decide where this
>> new handler chain should be executed on an outbound message
>> (after/before SOAP handlerchain ?)
>> Inclusion of it in sun-jaxws.xml should n't be a issue.
>>
>> thanks,
>> Rama Pulavarthi
>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>