Hi Mohan, On Fri, Aug 12, 2016 at 1:08 AM, Mohanadarshan Vivekanandalingam < [email protected]> wrote:
> > > On Thu, Aug 11, 2016 at 11:45 PM, Sriskandarajah Suhothayan <[email protected] > > wrote: > >> I think getting the claims will improve the message formatting when >> sending the message, and based on the discussion with Johann they cannot >> determine what claims the message formatting will need. if IS need to send >> the claims it has to also read the message to understand the necessary >> claims. >> >> Any suggestions ? >> > > Hmm.. Message is created/originated from IS side, Isn't it ? Then, why > can't we get whatever claims that required and send them.. > Message is not created in IS side. From IS side we only send the event specific properties. The admin can define whatever claims he wants in the email template. These are two independent actions. > Sorry, I don't see any overall impact because of that (Only thing is there > going to be another registry access to get the template and load relevant > claims). If this is an huge overhead then can't we send all the claims with > in the event (Not sure whether it is acceptable).. > We can't send all the claims because there can be sensitive information. Its not a scalable solution. > > But IMO, this is a notification task isn't. Then, I don't see a need to > worry much about performance and throughput.. > Performance is not the issue here. > And I don't think it is correct to change the generic notification event > publisher component as something which does some IS specific operation > which violates its design expectation and looks like a hack .. > That is not quite correct Mohan. Adding claim values to email template is nothing IS specific. The CEP's output adaptor framework is used by many WSO2 products for notifications. This is a common and valid requirement for all the products IMHO. It is with that intension we implemented HTML templating support and multi language template support in CEP itself. Similarly this is also another requirement. And I also don't think it is violating the existing architecture. I would think the same if the adaptors are implemented like a library which don't have any other carbon runtime dependency. However fetching the email template from registry is also done within the adaptor. So there is no good explanation to say fetching user claims from user store violates the adaptor design. If there was a layer before the adaptor layer which handles fetching email templates from registry, then in the same layer we can enrich the event stream with user claims defined in that template. So by the time the event reaches the adaptor all necessary values are in the stream. What I am saying is whether this code is in the adaptor or in a higher layer, ultimately it must be in CEP for all the products to use it. That is why we reckon that it is an improvement for CEP. Regards, Johann. > Let's have a quick chat if that help.. > > Thanks, > Mohan > > > >> >> Regards >> Suho >> >> On Thu, Aug 11, 2016 at 4:42 PM, Mohanadarshan Vivekanandalingam < >> [email protected]> wrote: >> >>> >>> >>> On Thu, Aug 11, 2016 at 11:32 AM, Indunil Upeksha Rathnayake < >>> [email protected]> wrote: >>> >>>> Hi Suhothayan, >>>> >>>> You can refer [1] for the current approach we have taken in IS side >>>> when improving notification sending with siddhi streams. As per the >>>> discussion we had previously, this approach has been taken in order to >>>> avoid the performance degradation due to the redundant loading of email >>>> template in IS and analytics. The main reason for the redundant loading is >>>> that only in IS side, the user claims can be loaded which needs for filling >>>> out the placeholders in email template. >>>> >>>> As per the current implementation you are having, we can provide the >>>> registry path and let the email template get loaded in analytics side. For >>>> that there has to be some improvement in analytics side to get the user >>>> claims from user store and filling out the template with those claim >>>> values. So that without loading the email template from IS side, we can do >>>> it in analytics side. >>>> >>>> So the suggested improvements as follows. >>>> *IS side:* >>>> >>>> >>>> >>>> >>>> >>>> >>>> *1) Modified the publisher definition to include registry path of the >>>> email template, specifying the notification type and locale as >>>> placeholders2) When an email notification need to be send, an arbitrary map >>>> (including the data needs to load the email template from registry) will be >>>> published to the streamAnalytics side:1) Load the email template from the >>>> registry (use the arbitrary data values we have provided)2) Extract the >>>> placeholders in email template3) Get the user claims from user store and >>>> fill out the placeholders in the template with the necessary claim values* >>>> >>> >>> Above [1] and [2] are already implemented in Event Publisher level and >>> can be usable for above usecase.. But [2] (which is mentioned as an >>> improvement for Analytics side) is not valid IMO.. That is not something >>> that we need to handle in analytics or Event Publisher side, it is >>> architecturally incorrect to handle in that level.. What need to be done >>> is, we need to get those claims from identity level and send those relevant >>> claims in the event itself.. >>> >>> What is the reason for defining [3] as an improvement for analytics ? >>> >>> Thanks, >>> Mohan >>> >>> >>>> >>>> >>>> We have used two prefixes in placeholders of email templates as >>>> "user.claim.identity" and "user.claim", in order to specify that the >>>> placeholders has to be filled with an identity claim and other wso2 claim >>>> respectively. The claim URIs which we are using when retrieving necessary >>>> user claims for the email templates, will be generated appending necessary >>>> prefix to the "http://wso2.org/claims/";. As an example if the >>>> placeholder is "user.claim.givenname", the claim URI should be " >>>> http://wso2.org/claims/givenname";. So that placeholder has to be >>>> filled with the user claim value corresponding to the above mentioned claim >>>> URI. You can refer [2] for the implementation done in IS side, we can move >>>> that logic to analytics side. >>>> >>>> [1] https://github.com/wso2-extensions/identity-event-handler-no >>>> tification/pull/26/files >>>> [2] https://github.com/wso2-extensions/identity-event-handler-no >>>> tification/pull/26/files#diff-2200b351eeef81ebbb5ea7f0d1f1ecb7R119 >>>> >>>> Thanks and Regards >>>> >>>> On Tue, Aug 9, 2016 at 9:50 PM, Sriskandarajah Suhothayan < >>>> [email protected]> wrote: >>>> >>>>> Based on the chat with Johann he suggested to support claims at event >>>>> publisher. >>>>> @Indunil, can you get the full requirements and update the thread. >>>>> >>>>> Regards >>>>> Suho >>>>> >>>>> On Mon, Aug 1, 2016 at 11:24 PM, Mohanadarshan Vivekanandalingam < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Aug 1, 2016 at 8:38 PM, Indunil Upeksha Rathnayake < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Suhothayan, >>>>>>> >>>>>>> Hi Indunil, >>>>>> >>>>>> I like to add some comments on this.. Please find them below.. >>>>>> >>>>>> >>>>>>> There was an issue in EventPublisherServiceDS where >>>>>>> setConfigurationContextService() method get invoked after the >>>>>>> bundle get activated. Due to that, when we are trying to invoke >>>>>>> deployEventPublisherConfiguration() of EventPublisherService from >>>>>>> the activate method of an osgi bundle in IS side, it's receiving a null >>>>>>> pointer(Since it refers the ConfigurationContextService object in >>>>>>> EventPublisherServiceValueHolder). I think you can resolve it by >>>>>>> changing the osgi reference cardinality in [1] as "1..1"(Mandatory), if >>>>>>> there is no specific reason for making it optional. >>>>>>> >>>>>> >>>>>> There is a valid reason for this.. >>>>>> I believe, as you know we cannot guarantee about OSGI bundle loading >>>>>> in carbon environment.. In this case, there is a possibility where axis2 >>>>>> deployment can start before bundle activation of a OSGI component. To >>>>>> avoid >>>>>> this we'll follow a similar approach like below, >>>>>> >>>>>> <Axis2RequiredServices> >>>>>> >>>>>> org.wso2.carbon.event.publisher.core.EventPublisherService >>>>>> >>>>>> </Axis2RequiredServices> >>>>>> >>>>>> Here, we are adding the reference of the corresponding OSGI service >>>>>> which is exposed by relevant OSGI module.. If you want to use above >>>>>> approach (Axis2RequiredServices), we cannot have 1..1 mapping for >>>>>> ConfigurationContextService since it causes cyclic dependency and affects >>>>>> bundle loading.. >>>>>> >>>>>> In IS side we were able to get rid of the null pointer by adding an >>>>>>> osgi reference for ConfigurationContextService in the service component >>>>>>> and >>>>>>> invoked the deployEventPublisherConfiguration() in activate() >>>>>>> method. >>>>>>> >>>>>> >>>>>> No, above solution is not correct and will not work all the time.. >>>>>> There is a possibility where you'll encounter same issue when >>>>>> ConfigurationContextService is bind to you component first and takes >>>>>> sometime to resolve for Event Publisher.. >>>>>> >>>>>> What is the usecase for creating an Event Publisher in server restart >>>>>> ? Can you ship the pack with an Event Publisher or deploy an event >>>>>> publisher for first event if it is not there.. >>>>>> >>>>>> >>>>>>> And also there was an issue in filling out dynamic properties of an >>>>>>> output adapter from the arbitrary data values, and sent a PR for that. >>>>>>> Please review and merge the PR in [2]. >>>>>>> >>>>>> >>>>>> Thanks, Merged it.. >>>>>> >>>>>> Regards, >>>>>> Mohan >>>>>> >>>>>> >>>>>>> >>>>>>> [1] https://github.com/wso2/carbon-analytics-common/blob/master/ >>>>>>> components/event-publisher/org.wso2.carbon.event.publisher.c >>>>>>> ore/src/main/java/org/wso2/carbon/event/publisher/core/inter >>>>>>> nal/ds/EventPublisherServiceDS.java#L56 >>>>>>> [2] https://github.com/wso2/carbon-analytics-common/pull/306/files >>>>>>> >>>>>>> Thanks and Regards >>>>>>> >>>>>>> On Mon, Aug 1, 2016 at 3:06 PM, Sriskandarajah Suhothayan < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> HI Indunil >>>>>>>> >>>>>>>> Any update on this? Was the provided solution working? >>>>>>>> >>>>>>>> We released CEP 4.2-RC1. If we need new features/improvements for >>>>>>>> this effort, we can incorporate them in the next component release. >>>>>>>> >>>>>>>> Regards >>>>>>>> Suho >>>>>>>> >>>>>>>> On Fri, Jul 22, 2016 at 3:10 PM, Sriskandarajah Suhothayan < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Jul 22, 2016 at 3:00 PM, Johann Nallathamby < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Jul 22, 2016 at 8:33 AM, Indunil Upeksha Rathnayake < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On Fri, Jul 22, 2016 at 12:28 PM, Sriskandarajah Suhothayan < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Jul 22, 2016 at 12:00 PM, Indunil Upeksha Rathnayake < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Please find the meeting notes in [1]. I have following >>>>>>>>>>>>> considerations regarding the improvements we have discussed. >>>>>>>>>>>>> >>>>>>>>>>>>> (1) Even though we have configured to load the email template >>>>>>>>>>>>> from EventPublisher(analytics side), the placeholder values has >>>>>>>>>>>>> to be sent >>>>>>>>>>>>> as meta data/correlation data/payload data/arbitrary data, since >>>>>>>>>>>>> in >>>>>>>>>>>>> analytics side, the user claim values are not getting from the >>>>>>>>>>>>> user store. >>>>>>>>>>>>> In order to send the placeholder values from IS side, anyway >>>>>>>>>>>>> we have to load the email template and retrieve the placeholders. >>>>>>>>>>>>> So as I >>>>>>>>>>>>> have understood, for email notifications, it's not needed to use >>>>>>>>>>>>> the email >>>>>>>>>>>>> template loading part in analytics, since it'll be a redundant >>>>>>>>>>>>> task. (Refer >>>>>>>>>>>>> [2]) >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Here we can set the claim values as arbitrary data, and the >>>>>>>>>>>> notification specific details as the meta, correlation & payload >>>>>>>>>>>> data. >>>>>>>>>>>> Then we can use the template loading only at the analytics >>>>>>>>>>>> side. >>>>>>>>>>>> >>>>>>>>>>> In this case, from IS side, without parsing only the user claims >>>>>>>>>>> needed for a particular email template(i.e.user claim values for the >>>>>>>>>>> placeholders in email template), we have to pass all the user >>>>>>>>>>> claims as >>>>>>>>>>> arbitrary data values. In that case there's no need for loading the >>>>>>>>>>> template from the registry in IS side. So that in analytics side, >>>>>>>>>>> all the >>>>>>>>>>> values needed for filling out the template will be there. Will >>>>>>>>>>> check on >>>>>>>>>>> that. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I don't think it will be a good solution. There can be sensitive >>>>>>>>>> information in the claims which we can't send. So for this release >>>>>>>>>> it's OK >>>>>>>>>> if we read the template in both sides - security is more important >>>>>>>>>> than >>>>>>>>>> performance; or read it only in IS side - but additionally send all >>>>>>>>>> those >>>>>>>>>> claims as arbitrary data as well, so if some one wants can use them >>>>>>>>>> in CEP >>>>>>>>>> side by their output adaptors. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I think then we can have a common configuration in IS side to >>>>>>>>> specify what are the claims that should be added to notifications. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Suho >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> (2) The email templates has to be changed as follows. >>>>>>>>>>>>> i) if the value will be provided in an arbitrary data map, >>>>>>>>>>>>> the placeholder should be with a prefix "arbitrary_" >>>>>>>>>>>>> (ex:{{arbitrary_givenname}}) >>>>>>>>>>>>> >>>>>>>>>>>> ii) if the value will be provided in an meta data map, the >>>>>>>>>>>>> placeholder should be changed as {{...}} (ex:{{givenname}}) >>>>>>>>>>>>> >>>>>>>>>>>>> No we should not use "arbitrary_" for any cases, its internal >>>>>>>>>>>> information and the names should not have "arbitrary_" even if its >>>>>>>>>>>> in >>>>>>>>>>>> arbitrary data map or otherwise. >>>>>>>>>>>> >>>>>>>>>>>> (3) Only Text OutputMapping Content can be filled from a value >>>>>>>>>>>>> in an arbitrary data map using prefix "arbitrary_" . It's not >>>>>>>>>>>>> possible to >>>>>>>>>>>>> use a value of an arbitrary data map, in a Dynamic adapter >>>>>>>>>>>>> properties, only >>>>>>>>>>>>> a value from a meta data/correlation data/payload data map can be >>>>>>>>>>>>> used. I >>>>>>>>>>>>> think that need to be extended to use even an arbitrary value as >>>>>>>>>>>>> a dynamic >>>>>>>>>>>>> adapter property.(Refer [3]) >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> @Gobi can you please fix this if that's the case. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> (4) The default stream definitions and publisher definitions >>>>>>>>>>>>> has to be deployed on super tenant as well as other tenants as >>>>>>>>>>>>> well. And >>>>>>>>>>>>> when a new tenant is added, those streams and publishers has to >>>>>>>>>>>>> be deployed >>>>>>>>>>>>> for that particular tenant as well. >>>>>>>>>>>>> >>>>>>>>>>>>> We can have a tenant creation handler to do this copying >>>>>>>>>>>> during that tenant creation time. WDYT? >>>>>>>>>>>> >>>>>>>>>>>> Really appreciate your ideas/suggestions regarding the above >>>>>>>>>>>>> mentioned concerns. >>>>>>>>>>>>> >>>>>>>>>>>>> [1] Invitation: [Architecture] [Discussion] Improvement to use >>>>>>>>>>>>> Siddhi str... @ Wed Jul 20, 2016 4:30pm - 5:30pm (IST) ( >>>>>>>>>>>>> [email protected]) >>>>>>>>>>>>> >>>>>>>>>>>>> [2] https://github.com/wso2/carbon >>>>>>>>>>>>> -analytics-common/blob/master/components/event-publisher/org >>>>>>>>>>>>> .wso2.carbon.event.publisher.core/src/main/java/org/wso2/car >>>>>>>>>>>>> bon/event/publisher/core/internal/type/text/TextOutputMapper >>>>>>>>>>>>> .java#L108 >>>>>>>>>>>>> >>>>>>>>>>>>> [3] https://github.com/wso2/carbon >>>>>>>>>>>>> -analytics-common/blob/master/components/event-publisher/org >>>>>>>>>>>>> .wso2.carbon.event.publisher.core/src/main/java/org/wso2/car >>>>>>>>>>>>> bon/event/publisher/core/internal/EventPublisher.java#L311 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks and Regards >>>>>>>>>>>>> -- >>>>>>>>>>>>> Indunil Upeksha Rathnayake >>>>>>>>>>>>> Software Engineer | WSO2 Inc >>>>>>>>>>>>> Email [email protected] >>>>>>>>>>>>> Mobile 0772182255 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> *S. Suhothayan* >>>>>>>>>>>> Associate Director / Architect & Team Lead of WSO2 Complex >>>>>>>>>>>> Event Processor >>>>>>>>>>>> *WSO2 Inc. *http://wso2.com >>>>>>>>>>>> * <http://wso2.com/>* >>>>>>>>>>>> lean . enterprise . middleware >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | >>>>>>>>>>>> blog: http://suhothayan.blogspot.com/ >>>>>>>>>>>> <http://suhothayan.blogspot.com/>twitter: >>>>>>>>>>>> http://twitter.com/suhothayan >>>>>>>>>>>> <http://twitter.com/suhothayan> | linked-in: >>>>>>>>>>>> http://lk.linkedin.com/in/suhothayan >>>>>>>>>>>> <http://lk.linkedin.com/in/suhothayan>* >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Indunil Upeksha Rathnayake >>>>>>>>>>> Software Engineer | WSO2 Inc >>>>>>>>>>> Email [email protected] >>>>>>>>>>> Mobile 0772182255 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Thanks & Regards, >>>>>>>>>> >>>>>>>>>> *Johann Dilantha Nallathamby* >>>>>>>>>> Technical Lead & Product Lead of WSO2 Identity Server >>>>>>>>>> Governance Technologies Team >>>>>>>>>> WSO2, Inc. >>>>>>>>>> lean.enterprise.middleware >>>>>>>>>> >>>>>>>>>> Mobile - *+94777776950* >>>>>>>>>> Blog - *http://nallaa.wordpress.com >>>>>>>>>> <http://nallaa.wordpress.com>* >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> *S. Suhothayan* >>>>>>>>> Associate Director / Architect & Team Lead of WSO2 Complex Event >>>>>>>>> Processor >>>>>>>>> *WSO2 Inc. *http://wso2.com >>>>>>>>> * <http://wso2.com/>* >>>>>>>>> lean . enterprise . middleware >>>>>>>>> >>>>>>>>> >>>>>>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>>>>>>>> http://suhothayan.blogspot.com/ >>>>>>>>> <http://suhothayan.blogspot.com/>twitter: >>>>>>>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | >>>>>>>>> linked-in: >>>>>>>>> http://lk.linkedin.com/in/suhothayan >>>>>>>>> <http://lk.linkedin.com/in/suhothayan>* >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *S. Suhothayan* >>>>>>>> Associate Director / Architect & Team Lead of WSO2 Complex Event >>>>>>>> Processor >>>>>>>> *WSO2 Inc. *http://wso2.com >>>>>>>> * <http://wso2.com/>* >>>>>>>> lean . enterprise . middleware >>>>>>>> >>>>>>>> >>>>>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>>>>>>> http://suhothayan.blogspot.com/ >>>>>>>> <http://suhothayan.blogspot.com/>twitter: >>>>>>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | >>>>>>>> linked-in: >>>>>>>> http://lk.linkedin.com/in/suhothayan >>>>>>>> <http://lk.linkedin.com/in/suhothayan>* >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Indunil Upeksha Rathnayake >>>>>>> Software Engineer | WSO2 Inc >>>>>>> Email [email protected] >>>>>>> Mobile 0772182255 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> [email protected] >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *V. Mohanadarshan* >>>>>> *Associate Tech Lead,* >>>>>> *Data Technologies Team,* >>>>>> *WSO2, Inc. http://wso2.com <http://wso2.com> * >>>>>> *lean.enterprise.middleware.* >>>>>> >>>>>> email: [email protected] >>>>>> phone:(+94) 771117673 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *S. Suhothayan* >>>>> Associate Director / Architect & Team Lead of WSO2 Complex Event >>>>> Processor >>>>> *WSO2 Inc. *http://wso2.com >>>>> * <http://wso2.com/>* >>>>> lean . enterprise . middleware >>>>> >>>>> >>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>>>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: >>>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: >>>>> http://lk.linkedin.com/in/suhothayan >>>>> <http://lk.linkedin.com/in/suhothayan>* >>>>> >>>> >>>> >>>> >>>> -- >>>> Indunil Upeksha Rathnayake >>>> Software Engineer | WSO2 Inc >>>> Email [email protected] >>>> Mobile 0772182255 >>>> >>> >>> >>> >>> -- >>> *V. Mohanadarshan* >>> *Associate Tech Lead,* >>> *Data Technologies Team,* >>> *WSO2, Inc. http://wso2.com <http://wso2.com> * >>> *lean.enterprise.middleware.* >>> >>> email: [email protected] >>> phone:(+94) 771117673 >>> >> >> >> >> -- >> >> *S. Suhothayan* >> Associate Director / Architect & Team Lead of WSO2 Complex Event >> Processor >> *WSO2 Inc. *http://wso2.com >> * <http://wso2.com/>* >> lean . enterprise . middleware >> >> >> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: >> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: >> http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* >> > > > > -- > *V. Mohanadarshan* > *Associate Tech Lead,* > *Data Technologies Team,* > *WSO2, Inc. http://wso2.com <http://wso2.com> * > *lean.enterprise.middleware.* > > email: [email protected] > phone:(+94) 771117673 > -- Thanks & Regards, *Johann Dilantha Nallathamby* Technical Lead & Product Lead of WSO2 Identity Server Governance Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
