axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <>
Subject Re: [Axis2] Proposal: Extending the handler invocation pattern
Date Mon, 17 Apr 2006 19:35:23 GMT
Hi Bill,

> > This is not the right way to do this in Axis2 ... you shouldn't be
> > putting stuff in the thread context as you run thru Axis2. The right way
> > to store it is in one of the *Context classes in Axis2 and then move it
> > to the thread where appropriate (for example, in the message receiver).
> > If you follow that approach then the behavior is absolutely fine- the
> > message receiver is fully in charge and can do the right thing.
> OK, so you're suggesting that we architect another plug point in the
> message receivers where handler (type)/message receiver (programming
> model) specific  plugins can be added to move things between the Axis2
> contexts and whatever is required by the programming model.  I
> completely agree, and was actually going to suggest that in a later
> discussion (for a different reason.) 

Basically yes but I wasn't suggesting another plugpoint- u can just use
the message receiver plugpoint and write your own message receiver

>  That still doesn't really address
> the general problem of allowing handlers to "clean up" when necessary.
> If a handler acquires a resource/starts a protocol, it's not generally
> desirable to leave everything waiting for a timeout upon completion or
> an error (which is all that can currently be done under some
> circumstances.) 


> I was trying to keep my examples simple for the sake of discussion.  You
> could imagine scenarios where responsibility of managing transactions
> falls upon the middleware (handler in this case.)  If the handler
> creates a transaction when a message comes in, it may be desirable for
> the handler to be responsible for committing the transaction after the
> message finishes being processed.

OK then let's address that .. what you're suggesting is that it would be
useful for a module author to be able to give some code that should be
run once a MEP is complete. I agree with that .. so let's come up with a
model to make that work.

That's a clean extension of Axis2 1.0 function so should not cause any
difficulty to add immediately after. 

We'd need to create a new interface (or I guess it could be a Handler
but I think that'll be confusing) and a syntax for registering them in a
module.xml probably. Then the engine would notify all such parties once
the MEP has been completed. We may need an additional bit on the
MessageReceiver interface to ask whether the MEP has been completed.

> > In any case, there's no way to consider this type of a change in time
> > for 1.0 at this point. I'm happy to continue the discussion on the list
> > for possible inclusion in a future version, but realistically with the
> > proposed 1.0 timeframe being like a week away (or even if it was a month
> > away!) this kind of a change is not an option at this time.
> If no one has problems with extending the Handler interface (i.e.
> changing the interface) after 1.0, I don't see any need to make the
> changes now either.  (If there is a desire to keep the interface stable
> after 1.0, I would still only suggest modifying the interface and
> putting a comment in saying that the method will not be invoked in this
> version.)  

I don't have any problem extending it after 1.0 .. I personally don't
think for a second we're done improving and adding concepts to Axis2.
However, I am dead keen on making sure whatever we have now works and
has been widely validated. So far we've used all the functionality we've
built (via Sandesha, Kandula or elsewhere). The key point being that
whatever goes in 1.0 we're stuck with ... we can add but we can't remove
or change without major cost.

So let's continue the discussion, come up with a design, implement it
and then try it out. When we're happy it works we'll get it into the
next release.


View raw message