Ajith, thanks for your valuable suggestions. Just the last question: can I put the two handlers into the same module or do I need two separate modules? If so, I should I configure module.xml?
Thanks, Michele Ajith Ranabahu wrote: > Hi, > I won't recommend replacing the dispatchers. Just put your second > handler after the current dispatch phase and that should do it. > > Ajith > > On 6/28/06, Michele Mazzucco <[EMAIL PROTECTED]> wrote: >> 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] >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
