Have you tried:
messageContext.getOperationContext().setProperty(
MyConstant, var);
Long var = (Long) messageContext.getOperationContext().getProperty(
MyConstant);
Now if IIRC correctly that will mantain state across invokations. If
that's a problem, you may have to get creative on your property name.
HTH,
Robert
http://www.braziloutsource.com/
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
