Thanks for your answer... What if in the first handler (the one that determines whether the next one should be executed) sets a "bypass" variable in the context, then if the next handler checks whether this variable exists it can just return, and accomplish the desired behavior. Do you think that approach is feasible? It kind of breaks the whole independency between handlers, but I think it's the only way to re-use the same service for two different scenarios.
Thanks, Jose M Selman ----- Original Message ----- From: "Dimuthu Leelarathne" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 23, 2002 10:56 PM Subject: Re: Passing Values through handlers > Hi Jose, > > Properties in MessageContext are mostly used to store HTTP header > information. > > Yes there is one message context per request. This MessageContext is passed > through handlers and one of the biggest jobs of MessageContext is to carry > information. This design pattern is called the mediator pattern. You can > read all about this in developer guide. > > My instinct say that in your case this wouldn't be much help. For a service > Axis-Engine anyway executes all service handlers. You cannot control which > service handlers should/shouldn't be executed according to the data in > MessageContext, because this is a business done by the Axis-Engine. > > Regards, > Dimuthu. > > > > ----- Original Message ----- > From: Jose Miguel Selman > To: [EMAIL PROTECTED] > Sent: Tuesday, September 23, 2003 9:35 PM > Subject: Passing Values through handlers > > > Hi: > I have a question regarding on how to pass values from one handler to > another in a handler chain, this is needed in order to by-pass one of the > handlers for certain cases. > I came with the idea of using properties in the MessageContext, but I > have a few questions about it. Is there one Context per request or is it > shared within requests? Will this approach be thread safe? > I haven't found anything about this in the documentation, so any help > will be extremely appreciated. > > Cheers... > > Jose M Selman > > > > > >
