Hi Subash, Depends on the type of notification you are talking about. Some for example, which are related to lifecycle operations have no repository aspect in them. Some, I agree are not registry specific.
Thanks, Senaka. On Tue, Aug 19, 2014 at 10:57 AM, Subash Chaturanga <[email protected]> wrote: > Hi Senaka, > Just a thought ;-). This notifications basically meant to provide what > happen to the repository and I would say it is NOT for registry. If I > subscribe to an update event for a service, I only interested in a > notification where I am notified ONLY when the particular service is > updated. Hence, why can't we trigger the events from the Repository layer ? > > > On Tue, Aug 19, 2014 at 3:03 AM, Senaka Fernando <[email protected]> wrote: > >> Hi Danesh, >> >> I also think #4 is proper. This is the way we track transaction >> commit/rollback status as well, so if you take a look @ the semantics of >> commit, this should be similar. So, ideally every supposedly unit >> operation, which happens to invoke other operations will increment the >> counter before invoking the subsequent operation and decrement the counter >> after it completes. This approach however, needs to be done @ every >> handler, component, kernel etc. >> >> Suggestion 05: >> Another trick though I'm not sure about the possibility is to track the >> transaction depth counter. This counter too will have information as to how >> far deep you are inside a transaction. Which is similar to the counter you >> are talking about. One catch is that the mount handler pushes this counter >> into a stack when it goes into a JDBC mount to make it possible to have >> transactions across DBs. To handle this AFAIU, you can also check whether >> the mount handler's stack is empty or not. But, I don't see it to be good >> idea to have this accessed outside of the kernel, so may be introduce a >> method inside the Transaction API of the kernel to explain whether you are >> within the terminal operation of a nested query or whether you are infact >> inside a nested operation. >> >> Thanks, >> Senaka. >> >> >> On Mon, Aug 18, 2014 at 8:05 PM, Danesh Kuruppu <[email protected]> wrote: >> >>> Hi Senaka, >>> Earlier we had an idea of having a flag and problem was how we could >>> handle the flag inside multiple request. >>> Suggestions we had earlier, >>> >>> Suggestion 01: Keep a flag in requestContext to track event firing. >>> *This is impossible because inside one request, there are multiple >>> requests and each request trigger eventing handler.* >>> >>> Suggestion 02: Keep a ThreadLocal flag to track event firing. >>> *Problem with this is we couldn't clearing identify the boundaries of >>> one user request. We need to put the flag down at the end of the request >>> which we couldn't find easily. * >>> >>> Suggestion 03: Keep a flag in requestContext and whenever new request >>> create inside the main request, transfer the flag status of the previous >>> request to the new request. transferor is a threadlocal variable. Here each >>> time we invoke registry call, we set the value of the threadlocal variable >>> to the current flag status of the requestContext and inside registry call >>> we set the flag value of the new requestContext to the value in threadLocal >>> variable. >>> >>> *This is too complex solution. we need to find out all registry call and >>> set the variable manually.* >>> Suggestion 04 : Keep a threadLocal stack to track the request flow. Here >>> each time we create request, we put it in the stack and at the end of the >>> registry call we remove that request from the stack. typical request flow >>> e.g.: >>> >>> Put | Add Request >> Stack Size >> 1 >>>> Put | Add Request >> Stack Size >> 2 >>>> Remove Association | Add Request >> Stack Size >> 3 >>>> Remove Association | Remove Request >> Stack Size >> 3 >>>> Remove Association | Add Request >> Stack Size >> 3 >>>> Put | Add Request >> Stack Size >> 4 >>>> Put | Remove Request >> Stack Size >> 4 >>>> Remove Association | Remove Request >> Stack Size >> 3 >>>> Put | Add Request >> Stack Size >> 3 >>>> Put | Remove Request >> Stack Size >> 3 >>>> Add Association | Add Request >> Stack Size >> 3 >>>> Add Association | Remove Request >> Stack Size >> 3 >>>> Put | Remove Request >> Stack Size >> 2 >>>> Put | Remove Request >> Stack Size >> 1 >>>> >>> >>> the Stack size reach the zero means we are at the end of the user >>> request. we can trigger eventing handler to generate notification. >>> *Currently this works for me, but don't know whether this is a feasible >>> solution.* >>> >>> Thanks >>> >>> >>> On Mon, Aug 18, 2014 at 6:25 PM, Senaka Fernando <[email protected]> >>> wrote: >>> >>>> Hi Eranda, >>>> >>>> Alright. So, just stop the duplication. Ideally, the handler should >>>> only be triggered once. And, AFAIU, this is doable with the >>>> association-update and recursive delete handlers (and other utility >>>> handlers of similar sort) can set some flag within themselves preventing >>>> the eventing handlers from firing events for those. Won't this work? >>>> >>>> Thanks, >>>> Senaka. >>>> >>>> >>>> On Mon, Aug 18, 2014 at 1:42 PM, Eranda Sooriyabandara <[email protected] >>>> > wrote: >>>> >>>>> Hi Senaka, >>>>> Requirement here is that when we do a artifact update the subscriber >>>>> getting massive number of mails saying resource updated where the number >>>>> depends on the number of associations and properties/hidden properties. >>>>> >>>>> thanks >>>>> Eranda >>>>> >>>>> >>>>> On Mon, Aug 18, 2014 at 6:02 PM, Senaka Fernando <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Danesh, Eranda, >>>>>> >>>>>> I think we are doing too much here. Before going ahead with this kind >>>>>> of different subscription model, we need to understand the requirement >>>>>> here. At least I'm not clear on that. Do you want it to be configurable >>>>>> as >>>>>> to whether people want to subscribe for association updates etc? or do >>>>>> you >>>>>> want to simply stop people getting multiple notifications? >>>>>> >>>>>> Also, we cannot literally get rid of the handler approach. Its either >>>>>> a handler or it has to be burnt into the kernel. I personally don't think >>>>>> the kernel needs this massive feature and if we take that approach we'll >>>>>> be >>>>>> tailoring the kernel to suit components. But, lets try to clarify the >>>>>> above >>>>>> before trying to do anything new. >>>>>> >>>>>> Thanks, >>>>>> Senaka. >>>>>> >>>>>> >>>>>> On Mon, Aug 18, 2014 at 1:28 PM, Eranda Sooriyabandara < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Senaka, >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 18, 2014 at 5:26 PM, Danesh Kuruppu <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Senaka, >>>>>>>> >>>>>>>> In the current system, event capturing is done through handlers. We >>>>>>>> couldn't come up with a solution through handlers. >>>>>>>> >>>>>>>> >>>>>>> As we went through the code and the complexity of change should be >>>>>>> done in order to achieve this with the RegistryEventHandler and the >>>>>>> handler >>>>>>> architecture is bit complected. Hence we thought of go for a different >>>>>>> solution where we introduce a new subscription type in governance level >>>>>>> and >>>>>>> we allow subscribe in artifact listing page where other subscriptions >>>>>>> will >>>>>>> remain the same. As Danesh's figure we will do subscribing and >>>>>>> unsubscribing using the list view. >>>>>>> We understand that this will complicate the list view but if we add >>>>>>> this in the resource level then the normal subscription story will >>>>>>> break. >>>>>>> There will be complications with the following areas. >>>>>>> >>>>>>> 1. How to show different event and notification types. We are >>>>>>> planning to have a pop-up which has the similar view as our normal >>>>>>> subscription >>>>>>> 2. Managing existing subscriptions. As I mentioned in 1 since we >>>>>>> use the similar view as our normal subscription it will come with >>>>>>> the view >>>>>>> and delete option for existing subscription. >>>>>>> >>>>>>> Also there is a problem of notifying in governance API since >>>>>>> governance API can be use as a client library, need to find a solution. >>>>>>> >>>>>>> thanks >>>>>>> Eranda >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Current suggested solution is, >>>>>>>> >>>>>>>> We are giving another subscribe button in artifact level(in List >>>>>>>> view) which is used for subscribe Artifact update and delete [Please >>>>>>>> find >>>>>>>> the attached screenshot]. other subscriptions(check/uncheck LC, remove >>>>>>>> LC, >>>>>>>> approve LC etc) are not going to change and are done in resource level. >>>>>>>> So user can subscribe to update and delete notifications in >>>>>>>> Artifact level and they will handle separately. >>>>>>>> >>>>>>>> Please give feedback on this. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Aug 15, 2014 at 8:50 PM, Shavantha Weerasinghe < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Danesh >>>>>>>>> >>>>>>>>> For notifications cant we have an option where the user gets to >>>>>>>>> select which group of resources user wants to update by ticking to >>>>>>>>> enable >>>>>>>>> and generate notifications for only that area. >>>>>>>>> >>>>>>>>> Will that be extra work for the user >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> On Aug 15, 2014 6:09 PM, "Senaka Fernando" <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Danesh, >>>>>>>>>> >>>>>>>>>> Yes, this is problem that we need to fix. >>>>>>>>>> >>>>>>>>>> I think we need to find a way to mask notifications for certain >>>>>>>>>> operations. Ideally the association processing is a part of the >>>>>>>>>> update and >>>>>>>>>> doesn't require separate notifications. But, this functionality of >>>>>>>>>> masking >>>>>>>>>> should not just be specific to this use-case, but generically usable >>>>>>>>>> for >>>>>>>>>> any similar scenario. Before having the call, can you do some >>>>>>>>>> research and >>>>>>>>>> propose a solution to this? Based on that, lets discuss. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Senaka. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Aug 15, 2014 at 1:11 PM, Danesh Kuruppu <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Senaka, >>>>>>>>>>> >>>>>>>>>>> With the current implementation, If user subscribe to a resource >>>>>>>>>>> which have multiple associations attached to it, user will receive >>>>>>>>>>> multiple >>>>>>>>>>> update notifications for a single update. >>>>>>>>>>> >>>>>>>>>>> This is because resource update have multiple repository update >>>>>>>>>>> and for every repository update system generates update >>>>>>>>>>> notification. >>>>>>>>>>> >>>>>>>>>>> We need to find a way to send single update notification for >>>>>>>>>>> this. >>>>>>>>>>> >>>>>>>>>>> Can we have a call on this please. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> Danesh Kuruppu >>>>>>>>>>> Software Engineer >>>>>>>>>>> WSO2 Inc, >>>>>>>>>>> Mobile: +94 (77) 1690552 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *[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 <%2B1%20408%20754%207388>; ext: 51736*; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Danesh Kuruppu >>>>>>>> Software Engineer >>>>>>>> WSO2 Inc, >>>>>>>> Mobile: +94 (77) 1690552 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> [email protected] >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *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 <%2B1%20408%20754%207388>; ext: 51736*; >>>>>> >>>>>> >>>>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >>>>>> http://linkedin.com/in/senakafernando >>>>>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . >>>>>> Middleware >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *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 <%2B1%20408%20754%207388>; ext: 51736*; >>>> >>>> >>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >>>> http://linkedin.com/in/senakafernando >>>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >>>> >>> >>> >>> >>> -- >>> >>> Danesh Kuruppu >>> Software Engineer >>> WSO2 Inc, >>> Mobile: +94 (77) 1690552 >>> >> >> >> >> -- >> >> >> *[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 <%2B1%20408%20754%207388>; ext: 51736*; >> >> >> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >> http://linkedin.com/in/senakafernando >> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >> > > > > -- > Thanks > /subash > > *Subash Chaturanga* > Senior Software Engineer & Lead WSO2 Governance Registry > Platform TG; WSO2 Inc. http://wso2.com > Contact: > email: [email protected] > blog: http://subashsdm.blogspot.com/ > twitter: @subash89 > phone: +9477 2225922 > Lean . Enterprise . Middleware > -- *[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
