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 > > >
