Re: [Dev] Is there a hard and fast rule to chose java 8 streams over for loops

[SajithAR Ariyarathna]

Its very hard to come-up with a hard & fast rule on when to use Stream
API/Lambda or traditional loops. However, in the Carbon platform we have
come-up with a rule of thumb for such scenario.

*Always give the priority to code readability*.


It doesn't matter whether you use Streams, Lambda, or traditional loops,
always write clean, readable, self-descriptive code. *Only exception is
performance*. If your code is performance critical, then you are allowed to
do optimizations that might lead to a more complex code. Even in such
situation, always try to maintain the code readability at a high level
(comments can be a good tool here).

Why Code Readability Matters? [1]

[1] https://dzone.com/articles/why-code-readability-matters

Thanks.


On Fri, Apr 7, 2017 at 12:16 PM, Vidura Nanayakkara 
wrote:

> Hi,
>
> Blog [1]  compares
> streams and loops for arrays and lists for different types of operations
> and is worth taking a look at. Blog [2]
> 
>  discusses
> when to use parallel streams which are also worth taking a look. IMO this
> depends according to the scenario you are left to deal with. For instance,
> in Carbon UUF we use loops instead of streams since the datasets we
> consider are relatively small (UUF is performance critical). There are also
> instances where we use streams where the possible performance drop due to
> using streams is small considering the code readability (the code is
> complex when loops are used).
>
> [1] Loops vs Streams 
> [2] Parallel stream processing in Java 8 – performance of sequential vs.
> parallel stream processing
> 
> [3] What's Wrong in Java 8, Part III: Streams and Parallel Streams
> 
>
> On Fri, Apr 7, 2017 at 9:02 AM, Jude Niroshan 
> wrote:
>
>> I agree with Tharika. It's more important to know that streams can be
>> considered when you need parallel processing done. Being said that, usage
>> has to be careful about the mutable operations. AFAIK, streams are good at
>> map reduction over the traditional for loops. It is more easy to manipulate
>> the collections. But it is not advisable to always go for streams.
>>
>> On Thu, Apr 6, 2017 at 8:54 PM, Pumudu Ruhunage  wrote:
>>
>>> Hi, IMO for less number of iterations/elements for loops are much
>>> efficient, and when number gets higher both are performing with similar
>>> efficiency. Advantage of parallel streams shows up when number of elements
>>> increases and cost of each iteration increases.
>>> Therefore, usage of streams/loops is highly dependent of the scenario
>>> and can not suggest either without proper knowledge of the scenario,
>>> especially for critical paths.
>>>
>>> Regards,
>>>
>>> On Thu, Apr 6, 2017 at 5:19 PM, Tharika Madurapperuma 
>>> wrote:
>>>
 Hi Rajith,

 IMO Java streams should not be used always as a practice. It is not
 a silver bullet. There can be issues in performance in some cases as you
 have pointed out.

 One of the main advantage of using streams is when the logic of
 looping is quite complex and involves different operations on collections
 together, so that it can improve readability and understandability. But at
 the same time it can result in new and subtle bugs if we are not careful
 enough [1].

  The performance aspect of streams vs loops depends on the type of
 the collection and the situation they deal with. This performance
 difference can sometimes be negligible. Hence we cannot completely go with
 one against another.

  So IMHO we can consider using streams only when necessary based on
 our requirement and use loops where it deserves.


 [1] https://blog.jooq.org/2014/06/13/java-8-friday-10-subtle-mis
 takes-when-using-the-streams-api/


 Thanks,
 Tharika.


 On Thu, Mar 30, 2017 at 12:01 PM, Rajith Roshan 
 wrote:

> Hi all,
>
> Most of our C5 development have used java8 streams api frequently more
> than the for loops.
> But there are some research have done to compare the performance of
> streams api compared to for loops. They have shown that stream API is slow
> compared to for loops in many scenarios (even for parallel streams). 
> [1][2]
>
> Is there any proper guidance to use which one over the other or are we
> using streams as a practice in C5 development
>
> [1] - https://blog.jooq.org/2015/12/08/3-reasons-why-you-shouldn
> t-replace-your-for-loops-by-stream-foreach/
> [2] - https://jaxenter.com/java-performance-tutorial-how-fast-ar
> e-the-java-

Re: [Dev] How to Wrap Java Exception in UUF

[SajithAR Ariyarathna]

Hi Gayesha, Gayan,

 This issue is fixed with PR
https://github.com/wso2/carbon-uuf/pull/222 (already
merged into the carbon-uuf/master). You can try-out the fix by moving to
UUF 1.0.0-SNAPSHOT version. Please verify the fix.

Thanks.

On Tue, Mar 14, 2017 at 5:41 PM, Gayan Gunawardana  wrote:

> I could able to get errorCode as well since cause.getTargetException()
> provide UserPortalUIException.
>
> On Tue, Mar 14, 2017 at 9:24 AM, Gayan Gunawardana  wrote:
>
>>
>>
>> On Tue, Mar 14, 2017 at 9:17 AM, Ayesha Dissanayaka 
>> wrote:
>>
>>> Hi,
>>>
>>> I think this[1] has to be fixed from UUF in order to be able to access
>>> original exception.
>>>
>> Still cause.getTargetException() gives original exception, how can we get
>> errorCode in that case?
>>
>>>
>>> [1] https://github.com/wso2/carbon-uuf/issues/177
>>>
>>>
Thanks!
>>> -Ayesha
>>>
>>>
>>> On Tue, Mar 14, 2017 at 9:10 AM, Gayan Gunawardana 
>>> wrote:
>>>

 Hi UUF team,

 Client OSGI service throw  UserPortalUIException with error message
 (message) and error code (errorCode).

 String error = "Failed to update user password.";
 LOGGER.error(error, e);
 throw new UserPortalUIException(error, e.getErrorCode());

 Form client side .js I can retrieve error message as below

 } catch (e) {
var message = e.message;
 var cause = e.getCause();
 if (cause != null) {
 //the exceptions thrown by the actual osgi service method is 
 wrapped inside a InvocationTargetException.
 if (cause instanceof 
 java.lang.reflect.InvocationTargetException) {
 message = cause.getTargetException().message;
 }
 }

 Is there a way to retrieve errorCode as well ?

 Thanks,
 Gayan

 --
 Gayan Gunawardana
 Software Engineer; WSO2 Inc.; http://wso2.com/
 Email: ga...@wso2.com
 Mobile: +94 (71) 8020933

>>>
>>>
>>>
>>> --
>>> *Ayesha Dissanayaka*
>>> Senior Software Engineer,
>>> WSO2, Inc : http://wso2.com
>>> 
>>> 20, Palm grove Avenue, Colombo 3
>>> E-Mail: aye...@wso2.com 
>>>
>>
>>
>>
>> --
>> Gayan Gunawardana
>> Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>
>
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>



-- 
Sajith Janaprasad Ariyarathna
Senior Software Engineer; WSO2, Inc.;  http://wso2.com/

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] GSoC 2017 - Proposal 20: [IS] OAuth 2.0 Dynamic Client Registration Management Protocol Support

[Dinuksha Ishwari]

Hi Maduranga / Ishara,

I'll look in to using client credentials grant for Registration Management
and will start a thread in the architecture list.

I looked in to the implementation of OIDC DCR and found that
registrationAccessToken and registrationClientURI are already added to the
OIDCRegistrationResponseProfile[1] although they are not added to response.

Should we make use of this or make the necessary changes to OAuth DCR
component itself.

[1]
https://github.com/dinuish94/identity-inbound-auth-oauth/blob/v5.3.4/components/org.wso2.carbon.identity.oidc.dcr/src/main/java/org/wso2/carbon/identity/oidc/dcr/model/OIDCRegistrationResponseProfile.java

Thanks,
Dinuksha.

On Fri, Apr 14, 2017 at 1:42 PM, Maduranga Siriwardena 
wrote:

>
>
> On Fri, Apr 14, 2017 at 1:21 PM, Ishara Karunarathna 
> wrote:
>
>> Hi Dinuksha,
>>
>> On Fri, Apr 14, 2017 at 9:52 AM, Dinuksha Ishwari <
>> dinuksha.ishw...@gmail.com> wrote:
>>
>>> Hi Maduranga,
>>>
>>> I have already started working on the cloned repo of [1] in order to
>>> make the necessary changes to the DCR component. I need a few
>>> clarifications on below.
>>>
>>> 1) I used Apache Oltu's OAuthIssuer to generate the access token
>>> required for Client Registration Management. Is this fine? Is there any
>>> better way? And also what's the approach to keep these tokens stored on the
>>> server end.
>>>
>> I think you generate your own access token for this, Instead I prefer to
>> use existing client credential grant type (If use is unknown and password
>> grant type if use is known) And use special scope for this.
>>
>> And better to discuss this in architecture list [1] then you can propose
>> your design and get more input.
>> [1]
>>
>
> I think you should use client credentials grant type for this and better
> to discuss this in a mailing thread.
>
>>
>> Thanks,
>> Ishara
>>
>>>
>>> 2) In order to add the two additional fields, registration_access_token
>>> and registration_client_uri, should we modify the existing profiles,
>>> responses etc, or should we extend them and make the necessary changes.
>>>
>> You have to modify the existing profiles and responses if needed. I think
> you only need to modify the response. The reason is there is no scenario
> where the new response is sent and another scenario where the old response
> is sent. In all the situations DCR should send the response with token.
> However check the usages of this response object in OIDC DCR and see if
> there is any conflict.
>
> Thanks,
> Maduranga.
>
>>
>>> I have added the above fields to the existing response and it can be
>>> found at [2]. Kindly provide feedback.
>>>
>>> [1] https://github.com/wso2-extensions/identity-inbound-auth-oauth
>>> [2] https://github.com/dinuish94/identity-inbound-auth-oauth
>>>
>>> Thanks,
>>> Dinuksha
>>>
>>> On Fri, Apr 14, 2017 at 8:02 AM, Maduranga Siriwardena <
>>> madura...@wso2.com> wrote:
>>>
 Hi Dinuksha,

 Glad to hear the progress of the project. Will go through the code and
 let you know if anything need to improve.

 However you might consider working in a fork of the oauth repo [1]
 since you need to do some modifications to dcr component also (to send the
 token with the registration response).

 [1] https://github.com/wso2-extensions/identity-inbound-auth-oauth

 Thanks,

 On Thu, Apr 13, 2017 at 8:05 PM, Dinuksha Ishwari <
 dinuksha.ishw...@gmail.com> wrote:

> Hi All,
>
> The repo of the sample implementation is moved to [1]. So far, it
> contains the implementation of the Client Configuration Endpoint where the
> client can query registration data.
>
> The Client Registration info can be obtained by sending a GET request
> to the endpoint /identity/register/{client_id} as below.
>
> curl -H 'Authorization: Basic: YWRtaW46YWRtaW4=' -X GET '
> https://localhost:9443/identity/register/8VF3iYpzF9LkxDff4MEmwRKxt7Ua'
> -k -v
> [1] https://github.com/dinuish94/dynamic-client-registration
> -management-component
>
> Thanks,
> Dinuksha
>
> On Thu, Apr 13, 2017 at 11:54 AM, Dinuksha Ishwari <
> dinuksha.ishw...@gmail.com> wrote:
>
>> Hi All,
>>
>> I have started implementing a sample component in order to get a
>> better understanding about the code and to gain hands-on experience. So 
>> far
>> I was able to set up the component and register a processor for DCRM
>> similar to what is done in [1] and [2]. The current implementation can be
>> found at [3]. It contains the implementation up to where the request
>> processing is started by DCRMProcessor. I will proceed with the request
>> handing next.
>>
>> Meanwhile, it would be great if you could review the implementation
>> and provide feedback whether the processor registration for identity
>> endpoint is done correctly.
>>
>> [1] https://github.com/wso2-extensions/identity-inbound-aut

Re: [Dev] GSoC 2017 - Proposal 20: [IS] OAuth 2.0 Dynamic Client Registration Management Protocol Support

[Maduranga Siriwardena]

On Fri, Apr 14, 2017 at 1:21 PM, Ishara Karunarathna 
wrote:

> Hi Dinuksha,
>
> On Fri, Apr 14, 2017 at 9:52 AM, Dinuksha Ishwari <
> dinuksha.ishw...@gmail.com> wrote:
>
>> Hi Maduranga,
>>
>> I have already started working on the cloned repo of [1] in order to make
>> the necessary changes to the DCR component. I need a few clarifications on
>> below.
>>
>> 1) I used Apache Oltu's OAuthIssuer to generate the access token required
>> for Client Registration Management. Is this fine? Is there any better way?
>> And also what's the approach to keep these tokens stored on the server end.
>>
> I think you generate your own access token for this, Instead I prefer to
> use existing client credential grant type (If use is unknown and password
> grant type if use is known) And use special scope for this.
>
> And better to discuss this in architecture list [1] then you can propose
> your design and get more input.
> [1]
>

I think you should use client credentials grant type for this and better to
discuss this in a mailing thread.

>
> Thanks,
> Ishara
>
>>
>> 2) In order to add the two additional fields, registration_access_token
>> and registration_client_uri, should we modify the existing profiles,
>> responses etc, or should we extend them and make the necessary changes.
>>
> You have to modify the existing profiles and responses if needed. I think
you only need to modify the response. The reason is there is no scenario
where the new response is sent and another scenario where the old response
is sent. In all the situations DCR should send the response with token.
However check the usages of this response object in OIDC DCR and see if
there is any conflict.

Thanks,
Maduranga.

>
>> I have added the above fields to the existing response and it can be
>> found at [2]. Kindly provide feedback.
>>
>> [1] https://github.com/wso2-extensions/identity-inbound-auth-oauth
>> [2] https://github.com/dinuish94/identity-inbound-auth-oauth
>>
>> Thanks,
>> Dinuksha
>>
>> On Fri, Apr 14, 2017 at 8:02 AM, Maduranga Siriwardena <
>> madura...@wso2.com> wrote:
>>
>>> Hi Dinuksha,
>>>
>>> Glad to hear the progress of the project. Will go through the code and
>>> let you know if anything need to improve.
>>>
>>> However you might consider working in a fork of the oauth repo [1] since
>>> you need to do some modifications to dcr component also (to send the token
>>> with the registration response).
>>>
>>> [1] https://github.com/wso2-extensions/identity-inbound-auth-oauth
>>>
>>> Thanks,
>>>
>>> On Thu, Apr 13, 2017 at 8:05 PM, Dinuksha Ishwari <
>>> dinuksha.ishw...@gmail.com> wrote:
>>>
 Hi All,

 The repo of the sample implementation is moved to [1]. So far, it
 contains the implementation of the Client Configuration Endpoint where the
 client can query registration data.

 The Client Registration info can be obtained by sending a GET request
 to the endpoint /identity/register/{client_id} as below.

 curl -H 'Authorization: Basic: YWRtaW46YWRtaW4=' -X GET '
 https://localhost:9443/identity/register/8VF3iYpzF9LkxDff4MEmwRKxt7Ua'
 -k -v
 [1] https://github.com/dinuish94/dynamic-client-registration
 -management-component

 Thanks,
 Dinuksha

 On Thu, Apr 13, 2017 at 11:54 AM, Dinuksha Ishwari <
 dinuksha.ishw...@gmail.com> wrote:

> Hi All,
>
> I have started implementing a sample component in order to get a
> better understanding about the code and to gain hands-on experience. So 
> far
> I was able to set up the component and register a processor for DCRM
> similar to what is done in [1] and [2]. The current implementation can be
> found at [3]. It contains the implementation up to where the request
> processing is started by DCRMProcessor. I will proceed with the request
> handing next.
>
> Meanwhile, it would be great if you could review the implementation
> and provide feedback whether the processor registration for identity
> endpoint is done correctly.
>
> [1] https://github.com/wso2-extensions/identity-inbound-auth
> -oauth/blob/master/components/org.wso2.carbon.identity.oauth
> .dcr/src/main/java/org/wso2/carbon/identity/oauth/dcr/proces
> sor/DCRProcessor.java
> [2] https://github.com/wso2-extensions/identity-inbound-auth
> -oauth/blob/master/components/org.wso2.carbon.identity.oidc.
> dcr/src/main/java/org/wso2/carbon/identity/oidc/dcr/processo
> r/OIDCDCRProcessor.java
> [3] https://github.com/dinuish94/identity-inbound-auth-oauth/
>
> Thanks and regards,
> Dinuksha.
>
> On Mon, Apr 3, 2017 at 8:43 PM, Dinuksha Ishwari <
> dinuksha.ishw...@gmail.com> wrote:
>
>> Hi Maduranga,
>>
>> I submitted the final proposal. Would like to thank you for your
>> guidance, support and insight.
>>
>> Thanks,
>> Dinuksha.
>>
>> On Mon, Apr 3, 2017 at 7:54 PM, Maduranga Siriwardena <
>> madu

Re: [Dev] GSoC 2017 - Proposal 20: [IS] OAuth 2.0 Dynamic Client Registration Management Protocol Support

[Ishara Karunarathna]

Hi Dinuksha,

On Fri, Apr 14, 2017 at 9:52 AM, Dinuksha Ishwari <
dinuksha.ishw...@gmail.com> wrote:

> Hi Maduranga,
>
> I have already started working on the cloned repo of [1] in order to make
> the necessary changes to the DCR component. I need a few clarifications on
> below.
>
> 1) I used Apache Oltu's OAuthIssuer to generate the access token required
> for Client Registration Management. Is this fine? Is there any better way?
> And also what's the approach to keep these tokens stored on the server end.
>
I think you generate your own access token for this, Instead I prefer to
use existing client credential grant type (If use is unknown and password
grant type if use is known) And use special scope for this.

And better to discuss this in architecture list [1] then you can propose
your design and get more input.
[1]

Thanks,
Ishara

>
> 2) In order to add the two additional fields, registration_access_token
> and registration_client_uri, should we modify the existing profiles,
> responses etc, or should we extend them and make the necessary changes.
>
> I have added the above fields to the existing response and it can be found
> at [2]. Kindly provide feedback.
>
> [1] https://github.com/wso2-extensions/identity-inbound-auth-oauth
> [2] https://github.com/dinuish94/identity-inbound-auth-oauth
>
> Thanks,
> Dinuksha
>
> On Fri, Apr 14, 2017 at 8:02 AM, Maduranga Siriwardena  > wrote:
>
>> Hi Dinuksha,
>>
>> Glad to hear the progress of the project. Will go through the code and
>> let you know if anything need to improve.
>>
>> However you might consider working in a fork of the oauth repo [1] since
>> you need to do some modifications to dcr component also (to send the token
>> with the registration response).
>>
>> [1] https://github.com/wso2-extensions/identity-inbound-auth-oauth
>>
>> Thanks,
>>
>> On Thu, Apr 13, 2017 at 8:05 PM, Dinuksha Ishwari <
>> dinuksha.ishw...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> The repo of the sample implementation is moved to [1]. So far, it
>>> contains the implementation of the Client Configuration Endpoint where the
>>> client can query registration data.
>>>
>>> The Client Registration info can be obtained by sending a GET request to
>>> the endpoint /identity/register/{client_id} as below.
>>>
>>> curl -H 'Authorization: Basic: YWRtaW46YWRtaW4=' -X GET '
>>> https://localhost:9443/identity/register/8VF3iYpzF9LkxDff4MEmwRKxt7Ua'
>>> -k -v
>>> [1] https://github.com/dinuish94/dynamic-client-registration
>>> -management-component
>>>
>>> Thanks,
>>> Dinuksha
>>>
>>> On Thu, Apr 13, 2017 at 11:54 AM, Dinuksha Ishwari <
>>> dinuksha.ishw...@gmail.com> wrote:
>>>
 Hi All,

 I have started implementing a sample component in order to get a better
 understanding about the code and to gain hands-on experience. So far I was
 able to set up the component and register a processor for DCRM similar to
 what is done in [1] and [2]. The current implementation can be found at
 [3]. It contains the implementation up to where the request processing is
 started by DCRMProcessor. I will proceed with the request handing next.

 Meanwhile, it would be great if you could review the implementation and
 provide feedback whether the processor registration for identity endpoint
 is done correctly.

 [1] https://github.com/wso2-extensions/identity-inbound-auth
 -oauth/blob/master/components/org.wso2.carbon.identity.oauth
 .dcr/src/main/java/org/wso2/carbon/identity/oauth/dcr/proces
 sor/DCRProcessor.java
 [2] https://github.com/wso2-extensions/identity-inbound-auth
 -oauth/blob/master/components/org.wso2.carbon.identity.oidc.
 dcr/src/main/java/org/wso2/carbon/identity/oidc/dcr/processo
 r/OIDCDCRProcessor.java
 [3] https://github.com/dinuish94/identity-inbound-auth-oauth/

 Thanks and regards,
 Dinuksha.

 On Mon, Apr 3, 2017 at 8:43 PM, Dinuksha Ishwari <
 dinuksha.ishw...@gmail.com> wrote:

> Hi Maduranga,
>
> I submitted the final proposal. Would like to thank you for your
> guidance, support and insight.
>
> Thanks,
> Dinuksha.
>
> On Mon, Apr 3, 2017 at 7:54 PM, Maduranga Siriwardena <
> madura...@wso2.com> wrote:
>
>> Hi Dinukshi,
>>
>> I will not have time to go through your proposal now. As the deadline
>> is getting closer, please go ahead and submit the proposal.
>>
>> Thanks,
>>
>> On Mon, Apr 3, 2017 at 12:41 AM, Dinuksha Ishwari <
>> dinuksha.ishw...@gmail.com> wrote:
>>
>>> Hi Maduranga,
>>>
>>> I have made the suggested changes in the proposal. Would appreciate
>>> if you could review and provide feedback.
>>>
>>> Thanks,
>>> Dinuksha.
>>>
>>> On Mon, Apr 3, 2017 at 1:14 AM, Maduranga Siriwardena <
>>> madura...@wso2.com> wrote:
>>>
 Hi Dinushika,

 I have added some comments to the the draft proposal.