Ajith, yes, this confirm my idea. The first handler, running before the transport phase, replaces the RequestURIBasedDispatcher (I still don't know how to add it to the transport phase. Anyway, the aim of the first is only to replace RequestURIBasedDispatcher), while the second one, running after the predispatch -- I think the operation context is added into the predispatch phase -- (or should it run after the dispatch one???) saves my stuff into the operation context (which is now non-null). Furthermore, while the first handler runs only for in-messages, the second one should intercept both in and out-messages.
Thanks, Michele Ajith Ranabahu wrote: > Hi, > Hmm... you seem to have a unique situation here. Does your handler run > even *before* transport ? The operation context is added only after > the dispatch phase. > What you can do is to have two handlers - the first one stores what > ever the thing in the message context and the next one , sitting after > the dispatch phase copies the property from the message context to the > operation context. How does that sound ? > > Ajith > > On 6/28/06, Michele Mazzucco <[EMAIL PROTECTED]> wrote: >> Hi all, >> >> it seems I have a big problem: the operation context is NULL (I think it >> is because the handler runs as first, event before the transport phase. >> How can I get a valid one? >> >> >> Thanks, >> Michele >> >> Ajith Ranabahu wrote: >> > yep, >> > OperationContext is the one for you >> > >> > Ajith >> > >> > On 6/27/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: >> >> OperationContext? >> >> >> >> -- dims >> >> >> >> On 6/27/06, Michele Mazzucco <[EMAIL PROTECTED]> wrote: >> >> > Ajith , >> >> > >> >> > so where do you suggest to temporarily 'store' my stuff (I need >> to save >> >> > some data during the incoming phase to reuse it when the response is >> >> > coming back)?, could OperationContext be fine? >> >> > >> >> > p.s. I don't need to keep any data across different invocations. >> >> > >> >> > >> >> > Thanks, >> >> > Michele >> >> > >> >> > Ajith Ranabahu wrote: >> >> > > Hi >> >> > > >> >> > >> from my previous posts I understood handlers are 'application >> >> scope', >> >> > >> that is they maintain a state across different client >> invocations. >> >> > > >> >> > > Actually handlers are supposed to be stateless! They should not >> >> > > maintain anything by themselves, rather they should be using the >> >> > > appropriate context to store anything required. >> >> > > >> >> > >> I have a handler intercepting both incoming and outgoing messages >> >> and >> >> > >> unfortunately I realized that instance fields are 'reset' (see >> logs >> >> > >> below). Is there any reason for this counter intuitive behavior? >> >> > >> >> >> > > >> >> > > So what I seem to understand is your handler implementation may >> not >> >> > > have been done in the recommended way.Have a look at this >> article [1] >> >> > > by Deepal which explains how the handlers work. >> >> > > >> >> > > >> >> > > >> >> > >> >> > >> --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >> >> > >> >> >> >> >> >> -- >> >> Davanum Srinivas : http://people.apache.org/~dims/ >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
