Hi dims, I'm happy to do that, but it's not an insignificant amount of work and so I wanted to try to get some high-level agreement before I went down that path.
-Bill On Thu, 2006-05-18 at 11:08 -0400, Davanum Srinivas wrote: > Bill, > > Could u please flesh it out? It may be easier to push the proposal > with a proposed patch :) > > thanks, > dims > > On 5/16/06, Bill Nagy <[EMAIL PROTECTED]> wrote: > > Since v1.0 has been released, and now that everyone has had time to > > recuperate, I would like to resume the discussion below. The full > > thread can be found at http://marc.theaimsgroup.com/?l=axis- > > dev&m=114573566701675&w=2 if you need your memory refreshed. > > > > -Bill > > > > > > On Sat, 2006-04-22 at 15:53 -0400, Bill Nagy wrote: > > Hi Sanjiva and Glen, > > > > On Tue, 2006-04-18 at 01:35 +0600, Sanjiva Weerawarana wrote: > > > > 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 > > > right?? > > > > > > > I'm going to start a new discussion thread for this, as it's really a > > separate issue from the discussion below. > > > > > > 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.) > > > > > > Accepted. > > > > > > > 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. > > > > > > > I'm not sure that I would necessarily tie the code to the module itself. > > Logically the code is most likely tied to the piece of function that a > > single handler is implementing (e.g. if a handler creates a transaction, > > it seems most logical that it should be the one to commit or abort the > > transaction.) That is why I was suggesting extending the Handler > > interface with another method. I will agree that this is more of a code > > structure issue than anything. (While it does require a retrofit of > > existing handlers, it does not require changes to the deployment > > mechanism/module.xml.) > > > > Likewise, I'm not sure that I would tie it to a MEP either. [The > > following is from the inbound perspective:] In the case of a failure, > > there is no guarantee that a MEP will have been resolved (e.g. if the > > dispatch fails after security and one of the initial RM handlers has > > executed, there would be no way for them to clean up if the execution of > > their completion code is tied to the MEP.) The only handlers/modules > > who would be assured that their completion code would be executed in the > > case of all faults are those who execute everything post-dispatch. This > > would create an avoidable inconsistency in the handler/module > > mechanism. > > > > I believe that a more consistent solution would be to have the > > handlers/phases that have executed during the processing of the message > > be invoked again (in the reverse order) after processing of the message > > path has been completed (e.g. Key: IH == inbound handler, OH == outbound > > handler -- one-way inbound: IH1, IH2, MessageReceiver, IH2, IH1 -- > > request-response inbound: IH1, IH2, MessageReceiver, OH1, OH2, > > Transport, OH2, OH1, IH2, IH1) Since the phases are executed > > explicitly, some portion of the completion path will depend upon the > > unwinding of the Java call stack, while some will be explicit. While I > > recognize that this is more complex of a solution than what Glen > > proposed, I believe that it addresses the issues above and that it will > > lead to a more easily understandable flow in the code. > > > > -Bill > > > > > > > > > > > > > > >
