Hi Eranda, Well inside the mounted environment, we run "some" handlers twice. This is legitimate. This because, we want to run the handler in the local database (non-mounted), and then the same handler on the remote database. But, this only makes sense if the handler is targetting multiple resources at the same time (ex:- WSDL, Schema). For a handler which only affects one resource it might not always be needed. But, there can be situations where this is needed. So, we decided to keep this dual invocation functionality.
The problem with the approach is that the handler context will get refreshed when it enters the mounted environment to allow all handlers to be executed again. So, unless the handler takes care of this by its own, the framework will invoke it twice. Now, this is no bug, but the way it is designed (see above). The approach we have taken today is to create a thread local variable to track the state of invocation of the handler. This also gives the handler author more flexibility, since he can control whether the handler is hit once or twice and even whether it is hit on the local database or the remote database. This gives the developer a great deal of flexibility and it is somewhat hard to generalize the concept. But, I feel that we can improve the Handler base class to avoid people having to duplicate code and to have some enumeration or something which can be set with the Handler Invocation Policy (i.e. Local, Remote, Both). But, using handlers within a mounted environment wasn't so popular in the past with only a limited products focusing on mounting, which is why this never seemed a required feature. Thanks, Senaka. On Mon, Aug 4, 2014 at 9:23 AM, Eranda Sooriyabandara <[email protected]> wrote: > Hi all, > The reason for this is because of the following code in > HandlerLifecycleManager > > requestContext.setProcessingComplete(false); > String userDefinedValue = handlerManagers.get( > USER_DEFINED_HANDLER_PHASE).put(requestContext); > isProcessingComplete |= requestContext.isProcessingComplete(); > // The reporting handler phase needs to know about the state of > processing > requestContext.setProcessingComplete(isProcessingComplete); > > Here we can see we set the processing complete to false without > considering the previous state of processing complete and invoke the user > defined handler manager. > > If we make it inside a if condition then this will work. The updated code > should be something like, > > if (!isProcessingComplete) { > String userDefinedValue = handlerManagers.get( > USER_DEFINED_HANDLER_PHASE).put(requestContext); > if (userDefinedValue != null) { > defaultValue = systemSpecificValue; > } > isProcessingComplete = requestContext.isProcessingComplete(); > } > requestContext.setProcessingComplete(isProcessingComplete); > > @Senaka, > Do you have an idea why we did something like this? > > thanks > Eranda > > > > On Mon, Aug 4, 2014 at 1:33 PM, Danesh Kuruppu <[email protected]> wrote: > >> Hi all, >> >> I created a custom handler and add resource inside mounted folder. When I >> update the property of that resource, custom handler invoke twice. >> >> Please clarify this, >> >> Thanks >> -- >> >> Danesh Kuruppu >> Software Engineer >> WSO2 Inc, >> Mobile: +94 (77) 1690552 >> > > > > -- > > *Eranda Sooriyabandara*Senior Software Engineer; > Integration Technologies Team; > WSO2 Inc.; http://wso2.com > Lean . Enterprise . Middleware > > E-mail: eranda AT wso2.com > Mobile: +94 716 472 816 > Linked-In: http://www.linkedin.com/in/erandasooriyabandara > Blog: http://emsooriyabandara.blogspot.com/ > > > > > -- *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* Software Architect; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 408 754 7388; ext: 51736*; *M: +44 782 741 1966 Linked-In: http://linkedin.com/in/senakafernando <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
