On Wed, Mar 15, 2017 at 11:10 AM, Pushpalanka Jayawardhana <[email protected]> wrote:
> > > On Wed, Mar 15, 2017 at 11:07 AM, Harsha Thirimanna <[email protected]> > wrote: > >> Yes, as you said, we have to provide a service by merging the dialect and >> profile. We can provide different service for that and there will more >> aggregate method that can be reusable in future. >> > +1. To avoid multiple service calls, it will be OK to provide the > functionality as mentioned, in service layer. > When we say service layer, are we talking about the OSGi service layer, or remote service layer? Avoiding multiple service calls at OSGi service layer is not a big thing IMO, because OSGi services are meant to be fine grained. But avoiding it in the remote service layer is very useful to avoid network overhead. I am also in favour of having an aggregate service at remote and/or OSGi layer. Can't that service be in profile service? Isn't the profile service already depending on claim service? > >> On Wed, Mar 15, 2017 at 10:42 AM, Pushpalanka Jayawardhana < >> [email protected]> wrote: >> >>> Hi Harsha, >>> >>> Please find the comments inline. >>> >>> On Tue, Mar 14, 2017 at 4:32 PM, Harsha Thirimanna <[email protected]> >>> wrote: >>> >>>> Hi Lanka, >>>> >>>> Shall we implement these two methods also in claim service side by >>>> merging dialect and profile ? >>>> >>>> public Set<Claim> transformToNativeDialect(Set<Claim> otherDialectClaims, >>>> String claimDialect, Optional<String> >>>> profile) { >>>> >>>> Assume the usage is given a set of external claim URIs, the dialect URI >>> and a profile, get a set of claims which are mapped to default claim >>> dialect and filtered by the profile. So that only the claims defined in >>> profile will be returned. Please correct me if this understanding is >>> incorrect. >>> >>> If that is the case aren't we merging two functionalities here? Mapping >>> from one dialect to another is a task the claim mapping service, while >>> filtering according to the profile should be done by a service for profile. >>> This same applies to below method too. >>> >>>> public Set<Claim> transformToOtherDialect(Set<Claim> nativeDialectClaims, >>>> String dialect, Optional<String> >>>> profile) { >>>> >>>> >>>> thanks >>>> >>>> *Harsha Thirimanna* >>>> *Associate Tech Lead | WSO2* >>>> >>>> Email: [email protected] >>>> Mob: +94715186770 <071%20518%206770> >>>> Blog: http://harshathirimanna.blogspot.com/ >>>> Twitter: http://twitter.com/harshathirimann >>>> Linked-In: linked-in: http://www.linkedin.com/pub/ha >>>> rsha-thirimanna/10/ab8/122 >>>> <http://wso2.com/signature> >>>> >>> >>> >>> >>> -- >>> Pushpalanka. >>> -- >>> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons). >>> Senior Software Engineer, WSO2 Lanka (pvt) Ltd; wso2.com/ >>> Mobile: +94779716248 >>> Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/p >>> ushpalanka/ | Twitter: @pushpalanka >>> >>> >> > > > -- > Pushpalanka. > -- > Pushpalanka Jayawardhana, B.Sc.Eng.(Hons). > Senior Software Engineer, WSO2 Lanka (pvt) Ltd; wso2.com/ > Mobile: +94779716248 > Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/ > pushpalanka/ | Twitter: @pushpalanka > > -- 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
