axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michele Mazzucco <Michele.Mazzu...@ncl.ac.uk>
Subject Re: [Axis2] Handler unexpected behaviour
Date Wed, 28 Jun 2006 11:18:51 GMT
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 <Michele.Mazzucco@ncl.ac.uk> 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 <Michele.Mazzucco@ncl.ac.uk> 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 <davanum@gmail.com> wrote:
>> >> >> OperationContext?
>> >> >>
>> >> >> -- dims
>> >> >>
>> >> >> On 6/27/06, Michele Mazzucco <Michele.Mazzucco@ncl.ac.uk>
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: axis-user-unsubscribe@ws.apache.org
>> >> >> > For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Davanum Srinivas : http://people.apache.org/~dims/
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> >> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: axis-user-help@ws.apache.org
>> >>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Mime
View raw message