And what about some values I need to pass between the two handlers (in-messages): can I save them into the message context?
Thanks, Michele Ajith Ranabahu wrote: > Hi, > Just put the handlers in the same module and put the relevant phases > in the module.xml. that should do it :) > > Ajith > > On 6/28/06, Michele Mazzucco <[EMAIL PROTECTED]> wrote: >> 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] >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
