OK, I'll do that and then post a link to the page. -Bill
On Thu, 2006-05-18 at 11:27 -0400, Davanum Srinivas wrote: > How about a summary in wiki of what you think the solution should look > like? with code snippets? I got lost reading all the emails on the > thread:) > > -- dims > > On 5/18/06, Bill Nagy <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
