axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chamikara Jayalath" <chamikar...@gmail.com>
Subject Re: [Axis2] Addressing handlers do not set mustUnderstand to false
Date Tue, 23 Jan 2007 21:33:57 GMT
Hi David,

I understand the performance issue. Will settle for this kind of a solution
for now.
This is something we should document.

Thanks,
Chamikara


On 1/23/07, David Illsley <davidillsley@gmail.com> wrote:
>
> Well I agree that it's a more general problem, but not with the
> suggested solution.
>
> There are 2 solutions which pop into my head which I think are
> cleaner, and in order of preference:
> 1. Before serialising the message, examine the headers and store the
> QName or similar of all processed messages in the Message Context
> 2. Before serialising the message, examine the headers and remove the
> mustUnderstand attribute from those which have getProcessed()==true
>
> These limit the changes to Sandesha2 and will be, imo more performant
> in the non-RM case.
>
> David
>
> P.S. This might also be a case where allowing the mustUnderstand check
> to be done outside the engine would be of benefit but I need to
> confirm the handler ordering.
>
> On 23/01/07, Chamikara Jayalath <chamikaramj@gmail.com> wrote:
> > Hi David,
> >
> > Well, it is possible to do it that way as well. But it seemed to me like
> a
> > more general problem. Whenever somebody does somehing like
> > serialization/deserialization of an envelope or storing an envelope in a
> > database this 'processed state' will be lost.
> >
> > Chamikara
> >
> >
> >
> > On 1/23/07, David Illsley <davidillsley@gmail.com> wrote:
> > >
> > > Hi Chamikara,
> > >
> > > Grrr, whose bright idea was mustUnderstand!
> > >
> > > It seems to me that what you're asking is that we tell handler writers
> > > not to call setProcessed(true) if they want their handlers to work
> > > with Sandehsa2. That seems pretty ugly and doesn't fit in with the way
> > > the mustUnderstand checking works now... and at a guess, calling
> > > setMustunderstand(false) will be MUCH slower than setProcessed(true)
> > >
> > > Surely it's a general Sandesha2 responsibility to somehow store (and
> > > restore) the results of previous handlers which have run or,
> > > alternatively re-run the handler? Can't you store away the
> > > setProcessed information in the same way you must be storing To,
> > > ReplyTo etc etc?
> > >
> > > David
> > >
> > > On 23/01/07, Chamikara Jayalath <chamikaramj@gmail.com> wrote:
> > > > Hi All,
> > > >
> > > > Currently whenever the  AddressingInHandler processes a SOAP Header
> > Block it
> > > > sets the setProcessed() method to avoid mustUnderstand failures. In
> > > > Sandesha2 we have a requirement to serialize and deserialize SOAP
> > envelopes
> > > > before the actual mustUnderstand check. Since the setProcessed()
> method
> > > > simply sets an internal boolean variable this information get lost
> in
> > this
> > > > process.
> > > >
> > > > A solution might be to do 'setMustUnderstand(false)' as well. Is
> there
> > any
> > > > reason not to do this ?
> > > >
> > > > Thanks,
> > > > Chamikara
> > > >
> > >
> > >
> > > --
> > > David Illsley - IBM Web Services Development
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

Mime
View raw message