[Architecture] Include Ninja Framework for MSF4J performance benchmark tests

[Sagara Gunathunga]

What about ${Subject}  [1]


[1] - http://www.ninjaframework.org/


Thanks !
-- 
Sagara Gunathunga

Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Open questions in C5 permission model

[Manuranga Perera]

Following are few questions I have on C5 permission model. Answers may have
already been discussed, and I might have missed. If so, shall we get them
on mail.

Action namespaces
We have namespaced the permission by the “protocol” of the resource URI.
Then, do we need to namespace the actions as well? topoic:view, api:view,
dashboard:view has almost the semantic. Having it just as “view” will be
useful when we want to use the same code or same lifecycle xml to govern
them. Because unlike resource URI, which are just arbitrary strings,
semantic of these words are understood by the code/ lifecycle xml.

Permissions for UI pages
I think there is no need to introduce a separate permission namespace for
UI (or use a very limited one). Actual customer is concerned about giving
permission to a real resource (topic, API, proxy  ...) not to a UI
URL. Ideally, for each page, we associate the page with an existing
permission space using a URI pattern mapping.

Eg: Let’s assume
http://mb.cloud.wso2.com/mb-explorer/topics/petNews/catNews has
to be associated with {jms://petNews/catNews, jms.view }
And for this we may introduce following UUF directive to the page

In ./pages/topics/{+topicPath}.hbs file
…
{{secure “jms://{topicPath}” ”jms:view”}}

Info about the topic: {{topicPath}}
…

Getting paginated list of resources
Following performance issue will occur when we try to obtain a paginated
resource list (Greg/Store artifices, DAS rows?) view for a given user. Lets
assume we need to show first 10 store artifacts (eg: APIs) in UI / or
through API. To archive this we get the first 10 resource, and then filter
it by permission in Java by iterating each. Assume out of that 10, the user
can only see 4, then we need to get next 10 and filter and next 10 …

Now assume we need to show the last 10 resources in UI. This is even worse.
In current GReg with LDAP this will take about 10min if we have 8000
resources regardless of the user (last time I checked). Hypothetically, if
we have a JDBC user store and the resource are in the same DB, this is a
single join query. Obviously, this will not work in a real world case since
permission are in different place.

Perhaps we can use Lucene indexing? But how do we invalidate the indexer
cache?

Criteria for using to Group vs Role
Currently we have associated everything with a role, in C5 some should
become groups and others should become groups.

Eg: Currently in dashboard server, any given dashboard can be associated
with any role via UI, and only that role (and admins) will be able to see
it. In C5 should dashboard will have a permission
{dashboard://xyz-cxo-dahboard,dashboard:view}. Then in UI should we give
the ability to associate it with a Role or Group?

(I personally don’t see the point of having two concepts, but if we do, we
should have a clear guideline when to use which)

Code duplication due to un-polymorphic Group and Role

Group class and the Role class share lot of method signatures but there is
no common interface both implements. Therefore, devs may have to repeat
code sections for each by copy-pasting, not using proper polymorphism. Eg:
UI for adding users to a Role/Group cannot share same code.

Maybe this kind of code is rare, is it? If so we can ignore this.

-- 
With regards,
*Manu*ranga Perera.

phone : 071 7 70 20 50
mail : m...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Dev] WSO2 Identity Server 5.2.0 Beta2 Released

[Kasun Bandara]

WSO2 Identity Server 5.2.0-BETA2 Released!

Date: 14th July 2016The WSO2 Identity Server team is pleased to announce
the release of WSO2 Identity Server 5.2.0 Beta2. You can download this
distribution from
https://github.com/wso2/product-is/releases/tag/v5.2.0-beta2
This release comes with both the Runtime and Analytics, providing support
for authentication and session data analysis. You can download these
distributions below.


Runtime : *wso2is-5.2.0-beta2.zip*


Analytics : *wso2analytics-is-5.2.0-beta2.zip*




Following list [1] contains all bug fixes and improvements available with
Beta2 release. We encourage you to report issues, improvements and feature
requests regarding WSO2 Identity Server through the public WSO2 Identity
Server JIRA 







~ The WSO2 Identity Server Team ~

[1] Release Notes - WSO2 Identity Server - Version 5.2.0-Beta2 Fixes
Bug

   - [IDENTITY-4569 ] -
   countClaims and countByClaimsInDomain methods are not implemented
   - [IDENTITY-4640 ] - The
   memory dump is not creating in the IS510 when the server goes OOM
   - [IDENTITY-4654 ] - Search
   Button in XACML policy standard editor ends up in an error
   - [IDENTITY-4664 ] - Getting
   a 404 page when adding attribute values to in XACML standard policy editor
   - [IDENTITY-4670 ] -
   Identity Server dashboard SLO not working
   - [IDENTITY-4685 ] -
   Remember me is not working
   - [IDENTITY-4695 ] -
   Remember me can be extended just by extending the expiry of the browser
   cookie
   - [IDENTITY-4703 ] - Session
   Analytics do not show remember me status correctly when session is updated
   - [IDENTITY-4706 ] - Error
   while refreshing token (loadbalanced setup MSSQL DB)
   - [IDENTITY-4707 ] - No
   events are created for login failures in federated authenticators
   - [IDENTITY-4708 ] -
   isFederated attribute value is wrong for federated scenario in
   authentication stream
   - [IDENTITY-4711 ] - Syntax
   Errors in Identity DB scripts with MySQL 5.7
   - [IDENTITY-4722 ] -
   RequestSecurityToken Response is not qualified for "
   http://schemas.xmlsoap.org/ws/2005/02/trust";
   - [IDENTITY-4723 ] - [IS as
   KM] observed 'NoSuchMethodError' error in IS carbon log after installed
   apim features
   - [IDENTITY-4724 ] -
   NullPointerException thrown when trying to add new Service Provider
   - [IDENTITY-4725 ] - When I
   try to create a new Service Provider a received a message
   - [IDENTITY-4748 ] - WSO2
   Identity Server as window service issue
   - [IDENTITY-4749 ] - Not
   validating some of the configurations done in identity.xml
   - [IDENTITY-4750 ] -
   ClaimCache of the OAuth component is not invalidated when user is deleted
   from the system.
   - [IDENTITY-4767 ] - session
   termination events are not triggered when commonauth is directly called
   with wrong relyingParty
   - [IDENTITY-4777 ] - count
   roles module does not list the Active Directory user store only jdbc user
   store
   - [IDENTITY-4794 ] - OIDC
   Session Management OP Iframe fails to load SHA256 hash JS function
   - [IDENTITY-4797 ] - Custom
   Inbound Authenticator configs and UIs not working as expected.

Improvement

   - [IDENTITY-4683 ] - JWT
   token (id_token) does not contain the token end point as an audience value.
   - [IDENTITY-4690 ] - "ISS"
   value of JWT token (id_token) can not be configurable in WSO2IS for given
   tenant.
   - [IDENTITY-4720 ] - Code
 

Re: [Architecture] Open questions in C5 permission model

[Rasika Perera]

Hi Manu,

Please find my inline comments.

Action namespaces
> We have namespaced the permission by the “protocol” of the resource URI.
> Then, do we need to namespace the actions as well? topoic:view, api:view,
> dashboard:view has almost the semantic. Having it just as “view” will be
> useful when we want to use the same code or same lifecycle xml to govern
> them. Because unlike resource URI, which are just arbitrary strings,
> semantic of these words are understood by the code/ lifecycle xml.​

Action namespaces won't make any sense in somecases. But namespaces can
derive the scope of the action. For instance; consider a scenario we have a
resource on registry path system/governance/security/*. Same resource is
accessible through web and mqtt. When we need to allow user to access this
resource only through the web. We can define it as *reg*:
system/governance/security/*:[*web:view].*

Thanks,
Rasika​

On Thu, Jul 14, 2016 at 8:40 PM, SajithAR Ariyarathna 
wrote:

> Hi Manu,
>
>
>> Permissions for UI pages
>> I think there is no need to introduce a separate permission namespace for
>> UI (or use a very limited one). Actual customer is concerned about giving
>> permission to a real resource (topic, API, proxy  ...) not to a UI
>> URL. Ideally, for each page, we associate the page with an existing
>> permission space using a URI pattern mapping.
>>
> +1. We can derive the permission of a web page (URL) from the resource/s
> that are associated with/shown in that page. Until we encounter a situation
> where we cannot derive permission of the URL (any examples?), let's use
> existing permissions.
>
> Thanks
>
>
>
> On Thu, Jul 14, 2016 at 8:18 PM, Manuranga Perera  wrote:
>
>> Following are few questions I have on C5 permission model. Answers may
>> have already been discussed, and I might have missed. If so, shall we get
>> them on mail.
>>
>> Action namespaces
>> We have namespaced the permission by the “protocol” of the resource URI.
>> Then, do we need to namespace the actions as well? topoic:view, api:view,
>> dashboard:view has almost the semantic. Having it just as “view” will be
>> useful when we want to use the same code or same lifecycle xml to govern
>> them. Because unlike resource URI, which are just arbitrary strings,
>> semantic of these words are understood by the code/ lifecycle xml.
>>
>> Permissions for UI pages
>> I think there is no need to introduce a separate permission namespace for
>> UI (or use a very limited one). Actual customer is concerned about giving
>> permission to a real resource (topic, API, proxy  ...) not to a UI
>> URL. Ideally, for each page, we associate the page with an existing
>> permission space using a URI pattern mapping.
>>
>> Eg: Let’s assume
>> http://mb.cloud.wso2.com/mb-explorer/topics/petNews/catNews has to be
>> associated with {jms://petNews/catNews, jms.view }
>> And for this we may introduce following UUF directive to the page
>>
>> In ./pages/topics/{+topicPath}.hbs file
>> …
>> {{secure “jms://{topicPath}” ”jms:view”}}
>> 
>> Info about the topic: {{topicPath}}
>> …
>>
>> Getting paginated list of resources
>> Following performance issue will occur when we try to obtain a paginated
>> resource list (Greg/Store artifices, DAS rows?) view for a given user. Lets
>> assume we need to show first 10 store artifacts (eg: APIs) in UI / or
>> through API. To archive this we get the first 10 resource, and then filter
>> it by permission in Java by iterating each. Assume out of that 10, the user
>> can only see 4, then we need to get next 10 and filter and next 10 …
>>
>> Now assume we need to show the last 10 resources in UI. This is even
>> worse. In current GReg with LDAP this will take about 10min if we have 8000
>> resources regardless of the user (last time I checked). Hypothetically, if
>> we have a JDBC user store and the resource are in the same DB, this is a
>> single join query. Obviously, this will not work in a real world case since
>> permission are in different place.
>>
>> Perhaps we can use Lucene indexing? But how do we invalidate the indexer
>> cache?
>>
>> Criteria for using to Group vs Role
>> Currently we have associated everything with a role, in C5 some should
>> become groups and others should become groups.
>>
>> Eg: Currently in dashboard server, any given dashboard can be associated
>> with any role via UI, and only that role (and admins) will be able to see
>> it. In C5 should dashboard will have a permission
>> {dashboard://xyz-cxo-dahboard,dashboard:view}. Then in UI should we give
>> the ability to associate it with a Role or Group?
>>
>> (I personally don’t see the point of having two concepts, but if we do,
>> we should have a clear guideline when to use which)
>>
>> Code duplication due to un-polymorphic Group and Role
>>
>> Group class and the Role class share lot of method signatures but there
>> is no common interface both implements. Therefore, devs may have to repeat
>> code sections for each by copy-pasting, not using p

[Architecture] Open questions in C5 permission model

[Manuranga Perera]

Following are few questions I have on C5 permission model. Answers may have
already been discussed, and I might have missed. If so, shall we get them
on mail.

Action namespaces
We have namespaced the permission by the “protocol” of the resource URI.
Then, do we need to namespace the actions as well? topoic:view, api:view,
dashboard:view has almost the semantic. Having it just as “view” will be
useful when we want to use the same code or same lifecycle xml to govern
them. Because unlike resource URI, which are just arbitrary strings,
semantic of these words are understood by the code/ lifecycle xml.

Permissions for UI pages
I think there is no need to introduce a separate permission namespace for
UI (or use a very limited one). Actual customer is concerned about giving
permission to a real resource (topic, API, proxy  ...) not to a UI
URL. Ideally, for each page, we associate the page with an existing
permission space using a URI pattern mapping.

Eg: Let’s assume
http://mb.cloud.wso2.com/mb-explorer/topics/petNews/catNews has
to be associated with {jms://petNews/catNews, jms.view }
And for this we may introduce following UUF directive to the page

In ./pages/topics/{+topicPath}.hbs file
…
{{secure “jms://{topicPath}” ”jms:view”}}

Info about the topic: {{topicPath}}
…

Getting paginated list of resources
Following performance issue will occur when we try to obtain a paginated
resource list (Greg/Store artifices, DAS rows?) view for a given user. Lets
assume we need to show first 10 store artifacts (eg: APIs) in UI / or
through API. To archive this we get the first 10 resource, and then filter
it by permission in Java by iterating each. Assume out of that 10, the user
can only see 4, then we need to get next 10 and filter and next 10 …

Now assume we need to show the last 10 resources in UI. This is even worse.
In current GReg with LDAP this will take about 10min if we have 8000
resources regardless of the user (last time I checked). Hypothetically, if
we have a JDBC user store and the resource are in the same DB, this is a
single join query. Obviously, this will not work in a real world case since
permission are in different place.

Perhaps we can use Lucene indexing? But how do we invalidate the indexer
cache?

Criteria for using to Group vs Role
Currently we have associated everything with a role, in C5 some should
become groups and others should become groups.

Eg: Currently in dashboard server, any given dashboard can be associated
with any role via UI, and only that role (and admins) will be able to see
it. In C5 should dashboard will have a permission
{dashboard://xyz-cxo-dahboard,dashboard:view}. Then in UI should we give
the ability to associate it with a Role or Group?

(I personally don’t see the point of having two concepts, but if we do, we
should have a clear guideline when to use which)

Code duplication due to un-polymorphic Group and Role

Group class and the Role class share lot of method signatures but there is
no common interface both implements. Therefore, devs may have to repeat
code sections for each by copy-pasting, not using proper polymorphism. Eg:
UI for adding users to a Role/Group cannot share same code.

Maybe this kind of code is rare, is it? If so we can ignore this.

-- 
With regards,
*Manu*ranga Perera.

phone : 071 7 70 20 50
mail : m...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Open questions in C5 permission model

[SajithAR Ariyarathna]

Hi Manu,


> Permissions for UI pages
> I think there is no need to introduce a separate permission namespace for
> UI (or use a very limited one). Actual customer is concerned about giving
> permission to a real resource (topic, API, proxy  ...) not to a UI
> URL. Ideally, for each page, we associate the page with an existing
> permission space using a URI pattern mapping.
>
+1. We can derive the permission of a web page (URL) from the resource/s
that are associated with/shown in that page. Until we encounter a situation
where we cannot derive permission of the URL (any examples?), let's use
existing permissions.

Thanks



On Thu, Jul 14, 2016 at 8:18 PM, Manuranga Perera  wrote:

> Following are few questions I have on C5 permission model. Answers may
> have already been discussed, and I might have missed. If so, shall we get
> them on mail.
>
> Action namespaces
> We have namespaced the permission by the “protocol” of the resource URI.
> Then, do we need to namespace the actions as well? topoic:view, api:view,
> dashboard:view has almost the semantic. Having it just as “view” will be
> useful when we want to use the same code or same lifecycle xml to govern
> them. Because unlike resource URI, which are just arbitrary strings,
> semantic of these words are understood by the code/ lifecycle xml.
>
> Permissions for UI pages
> I think there is no need to introduce a separate permission namespace for
> UI (or use a very limited one). Actual customer is concerned about giving
> permission to a real resource (topic, API, proxy  ...) not to a UI
> URL. Ideally, for each page, we associate the page with an existing
> permission space using a URI pattern mapping.
>
> Eg: Let’s assume
> http://mb.cloud.wso2.com/mb-explorer/topics/petNews/catNews has to be
> associated with {jms://petNews/catNews, jms.view }
> And for this we may introduce following UUF directive to the page
>
> In ./pages/topics/{+topicPath}.hbs file
> …
> {{secure “jms://{topicPath}” ”jms:view”}}
> 
> Info about the topic: {{topicPath}}
> …
>
> Getting paginated list of resources
> Following performance issue will occur when we try to obtain a paginated
> resource list (Greg/Store artifices, DAS rows?) view for a given user. Lets
> assume we need to show first 10 store artifacts (eg: APIs) in UI / or
> through API. To archive this we get the first 10 resource, and then filter
> it by permission in Java by iterating each. Assume out of that 10, the user
> can only see 4, then we need to get next 10 and filter and next 10 …
>
> Now assume we need to show the last 10 resources in UI. This is even
> worse. In current GReg with LDAP this will take about 10min if we have 8000
> resources regardless of the user (last time I checked). Hypothetically, if
> we have a JDBC user store and the resource are in the same DB, this is a
> single join query. Obviously, this will not work in a real world case since
> permission are in different place.
>
> Perhaps we can use Lucene indexing? But how do we invalidate the indexer
> cache?
>
> Criteria for using to Group vs Role
> Currently we have associated everything with a role, in C5 some should
> become groups and others should become groups.
>
> Eg: Currently in dashboard server, any given dashboard can be associated
> with any role via UI, and only that role (and admins) will be able to see
> it. In C5 should dashboard will have a permission
> {dashboard://xyz-cxo-dahboard,dashboard:view}. Then in UI should we give
> the ability to associate it with a Role or Group?
>
> (I personally don’t see the point of having two concepts, but if we do, we
> should have a clear guideline when to use which)
>
> Code duplication due to un-polymorphic Group and Role
>
> Group class and the Role class share lot of method signatures but there is
> no common interface both implements. Therefore, devs may have to repeat
> code sections for each by copy-pasting, not using proper polymorphism. Eg:
> UI for adding users to a Role/Group cannot share same code.
>
> Maybe this kind of code is rare, is it? If so we can ignore this.
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>



-- 
Sajith Janaprasad Ariyarathna
Software Engineer; WSO2, Inc.;  http://wso2.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] UUF Application Delivery Approach

[Rasika Perera]

Hi All,


In UUF, We have three different artifact types. UUF Applications(A),
Components(C) and Themes(T). Given that an Application can have UUF
dependencies (i.e. Components & Themes) and non-UUF dependencies(i.e.
Back-end osgi bundles, jax-rs or p2-features(BE)). Same way, a Component
also can have UUF dependencies and non-UUF dependencies.

[image: Inline image 3]

Diagram 1: sample apps dependency hierarchy

When deploying, the *deployable* artifact is an UUF-Application (you cannot
deploy a theme or a component alone). Moreover, the source project and
built project of the UUF-Application is bit *different*. Hence, we have
created uuf-maven-plugin [1] to build the application.


[image: Inline image 4]

Diagram 2: source project and built app comparison

When building the application we are resolving & copying the UUF
dependencies into the deployable artifact (i.e. a zip file).

As per the above diagram;  when resolving non-UUF dependencies, we need a
way to carry forward the back-end dependency (BE) information of components(
C) and apps(A).

For example:

A1’s pom.xml will declare T1, C1, C2, C3, and BE1A1 as its dependencies. It
will not aware of the dependencies BE1C1, BE1C2 and BE1C3. However, when
running the “create-application” goal in uuf-maven-plugin, we need to
resolve these BE dependencies as well.

This will be more complex; If there’s an App A2 from different product team
he will only add T2 and C1 as dependencies. BE1C1 should be resolved when
creating the app A2.

Problems:

   1.

   How to copy deployed uuf-application and its BE dependencies into a
   product (delivering app)?
   2.

   How to transfer meta-information of the BE dependencies along with
   components and apps?


Proposed Solution:

One solution is to create a new “create-feature” goal to create a
*carbon-feature*.


[image: Inline image 7]

Diagram 3: sample apps dependency hierarchy: BE can be a Bundle(B) or
Feature(F) (maven goals on the left)


Suppose the application feature is Foo;



   1.

   Plugins (i.e. B1A1, B1C3) need be copied to the /plugins directory in
   the feature Foo. Those will be copied into the PRODUCT_HOME/components path
   by carbon-feature-plugin when installing the feature.
   2.

   UUF application (i.e. A1, A2) will be in /features in the feature Foo.
   It will be copied into PRODUCT_HOME/deployments/uufapps directory. We
   can declare the copy path of UUF application through p2 touchpoints.
   3.

   Since transitive features(F1C1, F1C2) are not immediate dependencies of
   the App. It will be added as  in the feature Foo.


For the second problem; we can allow adding non-UUF dependencies in
pom.xml. Since we are using uuf-maven-plugin we can ignore non-uuf
dependencies when running goals of create- components, create-themes and
create-application.

Your comments and suggestions are highly appreciated.

Thanks,
Rasika

[1] https://github.com/rasika/carbon-uuf-maven-plugin/

-- 
With Regards,

*Rasika Perera*
Software Engineer
M: +94 71 680 9060 E: rasi...@wso2.com
LinkedIn: http://lk.linkedin.com/in/rasika90

WSO2 Inc. www.wso2.com
lean.enterprise.middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] UUF Application Delivery Approach

[Rasika Perera]

Hi All,

Please ignore this mail and reply to the thread "[Architecture] Unified UI
Framework(UUF) Application Delivery Approach".

Thanks,
Rasika

On Thu, Jul 14, 2016 at 6:24 PM, Rasika Perera  wrote:

> Hi All,
>
>
> In UUF, We have three different artifact types. UUF Applications(A),
> Components(C) and Themes(T). Given that an Application can have UUF
> dependencies (i.e. Components & Themes) and non-UUF dependencies(i.e.
> Back-end osgi bundles, jax-rs or p2-features(BE)). Same way, a Component
> also can have UUF dependencies and non-UUF dependencies.
>
> [image: Inline image 3]
>
> Diagram 1: sample apps dependency hierarchy
>
> When deploying, the *deployable* artifact is an UUF-Application (you
> cannot deploy a theme or a component alone). Moreover, the source project
> and built project of the UUF-Application is bit *different*. Hence, we have
> created uuf-maven-plugin [1] to build the application.
>
>
> [image: Inline image 4]
>
> Diagram 2: source project and built app comparison
>
> When building the application we are resolving & copying the UUF
> dependencies into the deployable artifact (i.e. a zip file).
>
> As per the above diagram;  when resolving non-UUF dependencies, we need a
> way to carry forward the back-end dependency (BE) information of
> components(C) and apps(A).
>
> For example:
>
> A1’s pom.xml will declare T1, C1, C2, C3, and BE1A1 as its dependencies.
> It will not aware of the dependencies BE1C1, BE1C2 and BE1C3. However,
> when running the “create-application” goal in uuf-maven-plugin, we need to
> resolve these BE dependencies as well.
>
> This will be more complex; If there’s an App A2 from different product
> team he will only add T2 and C1 as dependencies. BE1C1 should be resolved
> when creating the app A2.
>
> Problems:
>
>1.
>
>How to copy deployed uuf-application and its BE dependencies into a
>product (delivering app)?
>2.
>
>How to transfer meta-information of the BE dependencies along with
>components and apps?
>
>
> Proposed Solution:
>
> One solution is to create a new “create-feature” goal to create a
> *carbon-feature*.
>
>
> [image: Inline image 7]
>
> Diagram 3: sample apps dependency hierarchy: BE can be a Bundle(B) or
> Feature(F) (maven goals on the left)
>
>
> Suppose the application feature is Foo;
>
>
>
>1.
>
>Plugins (i.e. B1A1, B1C3) need be copied to the /plugins directory in
>the feature Foo. Those will be copied into the PRODUCT_HOME/components path
>by carbon-feature-plugin when installing the feature.
>2.
>
>UUF application (i.e. A1, A2) will be in /features in the feature Foo.
>It will be copied into PRODUCT_HOME/deployments/uufapps directory. We
>can declare the copy path of UUF application through p2 touchpoints.
>3.
>
>Since transitive features(F1C1, F1C2) are not immediate dependencies
>of the App. It will be added as  in the feature Foo.
>
>
> For the second problem; we can allow adding non-UUF dependencies in
> pom.xml. Since we are using uuf-maven-plugin we can ignore non-uuf
> dependencies when running goals of create- components, create-themes and
> create-application.
>
> Your comments and suggestions are highly appreciated.
>
> Thanks,
> Rasika
>
> [1] https://github.com/rasika/carbon-uuf-maven-plugin/
>
> --
> With Regards,
>
> *Rasika Perera*
> Software Engineer
> M: +94 71 680 9060 E: rasi...@wso2.com
> LinkedIn: http://lk.linkedin.com/in/rasika90
>
> WSO2 Inc. www.wso2.com
> lean.enterprise.middleware
>



-- 
With Regards,

*Rasika Perera*
Software Engineer
M: +94 71 680 9060 E: rasi...@wso2.com
LinkedIn: http://lk.linkedin.com/in/rasika90

WSO2 Inc. www.wso2.com
lean.enterprise.middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] ESB Analytics Dashboard Memory Usage

[Tharik Kanaka]

Hi Sinthuja,

Its not observed in the VizGrammar sample website [1]. Here we maintain a
max length on real time charts where library will drop points and data. I
will give you an update by conducting an extensive test on DAS pack and
check whats causing the memory leak.

[1] http://wso2.github.io/VizGrammar/samples/

Regards,

On Thu, Jul 14, 2016 at 3:40 PM, Sinthuja Ragendran 
wrote:

> Hi,
>
> When i further analyze this issue, it looks like it's coming from charting
> library. Basically I commented out chart.insert(data); and then I don't see
> the memory growth. So I doubt there is some sort of memory leak from the
> charting library.
>
> @Tharik,
> Can you please check further in this issue?
>
> Thanks,
> Sinthuja.
>
>
> On Thu, Jul 14, 2016 at 1:53 PM, Sinthuja Ragendran 
> wrote:
>
>> Hi,
>>
>> I tried this scenario with DAS 3.1.0 beta pack, and this is only
>> observable for the gadgets created by the gadget generation wizard. And I
>> could see a fast growth of the memory usage when the refresh interval for
>> the gadget is reduced. I think the data is getting accumulated in the
>> gadget without getting properly cleaned up. I'll check it further and
>> update.
>>
>> Thanks,
>> Sinthuja.
>>
>> On Thu, Jul 14, 2016 at 10:28 AM, Chamila De Alwis 
>> wrote:
>>
>>> Hi Udara,
>>>
>>> I've seen this behavior both in Windows and in Ubuntu (and in Ubuntu
>>> Firefox as well). I even saw memory usage values of more than 2GB for a
>>> window which was kept open for some time. Could you try with the steps
>>> mentioned in [1]?
>>>
>>> [1] - https://wso2.org/jira/browse/DAS-465
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Wed, Jul 13, 2016 at 11:53 PM, Udara Rathnayake 
>>> wrote:
>>>
 Hi Chamila,

 I did some profiling for dashboard view with few sample gadgets (using
 chrome dev tools) sometime back and haven't noticed any memory issues.
 Noticed memory growth with the time and then gc ran as expects,
 observed this behavior continuously. Let us try the same in the latest
 portal app and update you.



 On Thu, Jul 14, 2016 at 6:50 AM, Chamila De Alwis 
 wrote:

> I'm seeing this behavior in Ubuntu 16.04 Google Chrome as well (for a
> newly created dashboard with 4 generated gadgets in one page). The amount
> of memory consumed seems to be increasing gradually as the window is kept
> open. Sometimes the memory usage goes well beyond 1GB.
>
> IMO we should do a profiling to see what causes this much of memory to
> be used.
>
> [image: Inline image 1]
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Thu, Jun 30, 2016 at 11:19 AM, Chamila De Alwis 
> wrote:
>
>> Hi Sinthuja,
>>
>> I'm seeing around 500MB of memory usage in the DAS 3.1.0-SNAPSHOT
>> "Generate Gadget" page as well, specially when the gadget is being
>> previewed. At that moment, there is only one gadget in play, and the 
>> number
>> of records is less than 100.
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Wed, Jun 29, 2016 at 11:53 PM, Sinthuja Ragendran <
>> sinth...@wso2.com> wrote:
>>
>>> Hi Chamila,
>>>
>>> I think this is specifically for analytics dashboard right, and not
>>> for simple dashboards? In that case, we need to check how the gadgets 
>>> have
>>> been written, and because the actual data is being fetched from DAS into
>>> this gadgets, and I believe the fetched data to display in gadget is
>>> consuming more memory. Can you try to delete some gadgets from the above
>>> page and see whether there is an improvement?
>>>
>>> @Dunith/Tharik, Whether data is loaded in paginated manner (ie, not
>>> load all, only load the data which is required for the specific page)? 
>>> And
>>> do we load events with its all attributes or only with specific 
>>> attributes
>>> we required to show? I believe we have done some testing for ESB 
>>> analytics
>>> case right, didn't we hit this sort of issue in our local testing?
>>>
>>> Thanks,
>>> Sinthuja.
>>>
>>>
>>> On Thu, Jun 30, 2016 at 9:19 AM, Nipuna Chandradasa <
>>> nipu...@wso2.com> wrote:
>>>
 [Adding Udara,Sinthuja, and Tanya]

 Hi Chamila,

 This much of memory never used by shindig on gadget rendering.
 Because gadgets are pretty simple as i check them. There must be some 
 pre
 processes going on. That might cause this kind of

[Architecture] Facilitating Updating API with import/export tool in APIM

[Kaveesha Perera]

Hi All,

Current import/export tool doesn't facilitate updating a imported API. I
modified the implementation of import/export tool in APIM to update a API
once its been try to import a already imported API using APIM REST API.

When a user attempt to import a existing  API using *"*create a new API*" *REST
API [ 1.
https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APICollectionApi#apisPost]
, server gives out a error with code 409 stating a conflict. On it, then
check whether the user has set the value of query parameter
"updateIfExists" to true.(Refer the following example)

eg :-
curl -H "Authorization:Basic AbCdEfG" -F file=@
"/Desktop/MyAPIFolder/myExportedAPI.zip" -k -X POST "
https://10.100.7.40:9443/api-import-export-/import-api?
*updateIfExists=true*"

 If then, update the existing API using following REST APIs,

   - Update the existing API -
   
https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APICollectionApi#apisApiIdPut
   - Delete the existing API documents -
   
https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APIDocumentApi#apisApiIdDocumentsDocumentIdDelete
   - Add exported API documents -
   
https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APIDocumentApi#apisApiIdDocumentsPost

   - Update document contents -
   
https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APIDocumentApi#apisApiIdDocumentsDocumentIdContentPost
   - Add API thumbnail by calling to the end point
   http://localhost:9763/api/am/publisher/v0.9//apis/{apiId}/thumbnail
   

   with corresponding image file.

else, If the value of query parameter "updateIfExists" is false, importing
action ends up giving a appropriate error message stating API trying to
create already exists.
If there are any feedback on this procedure please reply.

Regards,

-- 
Kaveesha Perera
Intern - Software Engineering

mobile: 0716130471
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Improvements for API import/export base on APIM REST API

[Kaveesha Perera]

Hi All,

Current import/export tool of APIM is based on APIM internal Java API
implementations for its functionality, Which been lead to tight coupling
between the code and  the API. This make restrictions on API maintenance
across versions and code changes.

Recently I'm working on modifying import/export tool to use APIM REST API
implementations to perform it's functionalities.This will add more dynamic
nature to APIs irrespective to the changes in code bases.

I'm completed with the first phase of the above by exporting a API using
REST APIs.

Invoking a REST API require access token.Before that need to obtain the
consumer key/secret key pairs. To obtain consumer key/secrete pairs and
access tokens implemented a Java client to call dynamic client registration
endpoint to as in 1)
https://docs.wso2.com/display/AM1100/apidocs/publisher/index.html#guide.

I changed the current implementations of import/export to retrieve the
information related to a particular API using REST API. Following REST APIs
are used over that. These need access token with scope *apim:api_view*.


   - Get details of an API-
   
https://docs.wso2.com/display/AM1100/apidocs/publisher/index.html#!/operations#APICollectionApi#apisApiIdGet
   - Get API documentations -
1)https://docs.wso2.com/display/AM1100/apidocs/publisher/index.html#!/operations#APIDocumentApi#apisApiIdDocumentsGet

   -2)
   
https://docs.wso2.com/display/AM1100/apidocs/publisher/index.html#!/operations#APIDocumentApi#apisApiIdDocumentsDocumentIdContentGet
   - Get thumbnail image -  retrieve by calling endpoint
   http://localhost:9763/api/am/publisher/v0.9/apis/{apiId}/thumbnail
   - Information on the swagger included withing the retrieved API
   definition.

All the information of the existing API, retrieved from above are written
in to a directory which can be export as a .zip archive. This exporting ZIP
file contains the following structure:


​
If any feedback please reply.

Regards,

-- 
Kaveesha Perera
Intern - Software Engineering

mobile: 0716130471
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] ESB Analytics Dashboard Memory Usage

[Sinthuja Ragendran]

Hi,

When i further analyze this issue, it looks like it's coming from charting
library. Basically I commented out chart.insert(data); and then I don't see
the memory growth. So I doubt there is some sort of memory leak from the
charting library.

@Tharik,
Can you please check further in this issue?

Thanks,
Sinthuja.


On Thu, Jul 14, 2016 at 1:53 PM, Sinthuja Ragendran 
wrote:

> Hi,
>
> I tried this scenario with DAS 3.1.0 beta pack, and this is only
> observable for the gadgets created by the gadget generation wizard. And I
> could see a fast growth of the memory usage when the refresh interval for
> the gadget is reduced. I think the data is getting accumulated in the
> gadget without getting properly cleaned up. I'll check it further and
> update.
>
> Thanks,
> Sinthuja.
>
> On Thu, Jul 14, 2016 at 10:28 AM, Chamila De Alwis 
> wrote:
>
>> Hi Udara,
>>
>> I've seen this behavior both in Windows and in Ubuntu (and in Ubuntu
>> Firefox as well). I even saw memory usage values of more than 2GB for a
>> window which was kept open for some time. Could you try with the steps
>> mentioned in [1]?
>>
>> [1] - https://wso2.org/jira/browse/DAS-465
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Wed, Jul 13, 2016 at 11:53 PM, Udara Rathnayake 
>> wrote:
>>
>>> Hi Chamila,
>>>
>>> I did some profiling for dashboard view with few sample gadgets (using
>>> chrome dev tools) sometime back and haven't noticed any memory issues.
>>> Noticed memory growth with the time and then gc ran as expects, observed
>>> this behavior continuously. Let us try the same in the latest portal app
>>> and update you.
>>>
>>>
>>>
>>> On Thu, Jul 14, 2016 at 6:50 AM, Chamila De Alwis 
>>> wrote:
>>>
 I'm seeing this behavior in Ubuntu 16.04 Google Chrome as well (for a
 newly created dashboard with 4 generated gadgets in one page). The amount
 of memory consumed seems to be increasing gradually as the window is kept
 open. Sometimes the memory usage goes well beyond 1GB.

 IMO we should do a profiling to see what causes this much of memory to
 be used.

 [image: Inline image 1]


 Regards,
 Chamila de Alwis
 Committer and PMC Member - Apache Stratos
 Software Engineer | WSO2 | +94772207163
 Blog: code.chamiladealwis.com



 On Thu, Jun 30, 2016 at 11:19 AM, Chamila De Alwis 
 wrote:

> Hi Sinthuja,
>
> I'm seeing around 500MB of memory usage in the DAS 3.1.0-SNAPSHOT
> "Generate Gadget" page as well, specially when the gadget is being
> previewed. At that moment, there is only one gadget in play, and the 
> number
> of records is less than 100.
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Wed, Jun 29, 2016 at 11:53 PM, Sinthuja Ragendran <
> sinth...@wso2.com> wrote:
>
>> Hi Chamila,
>>
>> I think this is specifically for analytics dashboard right, and not
>> for simple dashboards? In that case, we need to check how the gadgets 
>> have
>> been written, and because the actual data is being fetched from DAS into
>> this gadgets, and I believe the fetched data to display in gadget is
>> consuming more memory. Can you try to delete some gadgets from the above
>> page and see whether there is an improvement?
>>
>> @Dunith/Tharik, Whether data is loaded in paginated manner (ie, not
>> load all, only load the data which is required for the specific page)? 
>> And
>> do we load events with its all attributes or only with specific 
>> attributes
>> we required to show? I believe we have done some testing for ESB 
>> analytics
>> case right, didn't we hit this sort of issue in our local testing?
>>
>> Thanks,
>> Sinthuja.
>>
>>
>> On Thu, Jun 30, 2016 at 9:19 AM, Nipuna Chandradasa > > wrote:
>>
>>> [Adding Udara,Sinthuja, and Tanya]
>>>
>>> Hi Chamila,
>>>
>>> This much of memory never used by shindig on gadget rendering.
>>> Because gadgets are pretty simple as i check them. There must be some 
>>> pre
>>> processes going on. That might cause this kind of memory usage.
>>>
>>> Thank you,
>>>
>>> On Thu, Jun 30, 2016 at 1:46 AM, Chamila De Alwis >> > wrote:
>>>
 Hi,

 ESB 5.0.0 beta analytics dashboard seems to be taking a
 considerable amount of memory to operate. I noticed the following in
 Chrome 51.0.2704.103 m (64-bit) in Windows.


 [image: Inline image 2]

 Next to Gmail Inbox, ESB Dashboard takes about average 400MB to
 operate. This can sometimes go up to more than 700MB when browsing 
>>

Re: [Architecture] Supporting OpenIDConnect Scope Parameters

[Hasanthi Purnima Dissanayake]

Hi Isura,

Yes when we mark 'all' in the xml for scope 'openid' it behaves as the
previous way. We need to rethink whether it is the correct behavior as it
is sending all the claims without considering other scopes. So other scopes
become useless. How ever yes, we are using 'openid' scope to  behave it as
the previous way.

Thanks,

Hasanthi Dissanayake

Software Engineer | WSO2

E: hasan...@wso2.com
M :0718407133| http://wso2.com 

On Thu, Jul 14, 2016 at 2:28 PM, Isura Karunaratne  wrote:

> Hi Hasanthi,
>
> What is the default behaviour of claims of the openid scope? I think it
> should be "all".
>
> Thank
> Isura.
>
> On Thu, Jul 14, 2016 at 11:08 AM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> I'm implementing the $subject and the plan is as below.
>>
>> 1. The scopes and supported claims will be defined in identity.xml as
>> below.
>> 
>> 
>> 
>> sub
>> 
>> 
>> email,email_preferred
>> 
>> 
>> name, family_name, given_name, middle_name, nickname,
>> preferred_username, profile, picture, website, gender, birthdate, zoneinfo,
>> locale, updated_at
>> 
>> 
>> phone_number, phone_number_verified
>> 
>> 
>> address,street
>> 
>> 
>> 
>>
>>
>> 2. If there are any requested claims, the requested claims will be issued
>> ignoring the scope when the claims of the openid scope has been configured
>> as *all* in identity.xml. The requested claims will be issued
>> considering the scopes when the claims of the openid scope has been
>> configured as *sub* in identity.xml
>>
>> 3. If there are no requested claims, according to the above
>> configurations the matching claims will be issued from the user info
>> endpoint according to the scope.
>> eg1: If the user requested openid email scope the claims will be
>> sub,email,email_preferred (When the claims of the openid scope has been
>> configured as *sub* in identity.xml).
>> eg2. If the user requested openid email scope the claims will be {all the
>> mapped attributes},email,email_preferred (When the claims of the openid
>> scope has been configured as *all* in identity.xml).
>>
>> Any suggestions will be highly appreciated.
>>
>> Thanks,
>>
>> Hasanthi Dissanayake
>>
>> Software Engineer | WSO2
>>
>> E: hasan...@wso2.com
>> M :0718407133| http://wso2.com 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Isura Dilhara Karunaratne*
> Senior Software Engineer | WSO2
> Email: is...@wso2.com
> Mob : +94 772 254 810
> Blog : http://isurad.blogspot.com/
>
> 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Supporting OpenIDConnect Scope Parameters

[Isura Karunaratne]

Hi Hasanthi,

What is the default behaviour of claims of the openid scope? I think it
should be "all".

Thank
Isura.

On Thu, Jul 14, 2016 at 11:08 AM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> I'm implementing the $subject and the plan is as below.
>
> 1. The scopes and supported claims will be defined in identity.xml as
> below.
> 
> 
> 
> sub
> 
> 
> email,email_preferred
> 
> 
> name, family_name, given_name, middle_name, nickname,
> preferred_username, profile, picture, website, gender, birthdate, zoneinfo,
> locale, updated_at
> 
> 
> phone_number, phone_number_verified
> 
> 
> address,street
> 
> 
> 
>
>
> 2. If there are any requested claims, the requested claims will be issued
> ignoring the scope when the claims of the openid scope has been configured
> as *all* in identity.xml. The requested claims will be issued considering
> the scopes when the claims of the openid scope has been configured as
> *sub* in identity.xml
>
> 3. If there are no requested claims, according to the above configurations
> the matching claims will be issued from the user info endpoint according to
> the scope.
> eg1: If the user requested openid email scope the claims will be
> sub,email,email_preferred (When the claims of the openid scope has been
> configured as *sub* in identity.xml).
> eg2. If the user requested openid email scope the claims will be {all the
> mapped attributes},email,email_preferred (When the claims of the openid
> scope has been configured as *all* in identity.xml).
>
> Any suggestions will be highly appreciated.
>
> Thanks,
>
> Hasanthi Dissanayake
>
> Software Engineer | WSO2
>
> E: hasan...@wso2.com
> M :0718407133| http://wso2.com 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] ESB Analytics Dashboard Memory Usage

[Sinthuja Ragendran]

Hi,

I tried this scenario with DAS 3.1.0 beta pack, and this is only observable
for the gadgets created by the gadget generation wizard. And I could see a
fast growth of the memory usage when the refresh interval for the gadget is
reduced. I think the data is getting accumulated in the gadget without
getting properly cleaned up. I'll check it further and update.

Thanks,
Sinthuja.

On Thu, Jul 14, 2016 at 10:28 AM, Chamila De Alwis 
wrote:

> Hi Udara,
>
> I've seen this behavior both in Windows and in Ubuntu (and in Ubuntu
> Firefox as well). I even saw memory usage values of more than 2GB for a
> window which was kept open for some time. Could you try with the steps
> mentioned in [1]?
>
> [1] - https://wso2.org/jira/browse/DAS-465
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Wed, Jul 13, 2016 at 11:53 PM, Udara Rathnayake 
> wrote:
>
>> Hi Chamila,
>>
>> I did some profiling for dashboard view with few sample gadgets (using
>> chrome dev tools) sometime back and haven't noticed any memory issues.
>> Noticed memory growth with the time and then gc ran as expects, observed
>> this behavior continuously. Let us try the same in the latest portal app
>> and update you.
>>
>>
>>
>> On Thu, Jul 14, 2016 at 6:50 AM, Chamila De Alwis 
>> wrote:
>>
>>> I'm seeing this behavior in Ubuntu 16.04 Google Chrome as well (for a
>>> newly created dashboard with 4 generated gadgets in one page). The amount
>>> of memory consumed seems to be increasing gradually as the window is kept
>>> open. Sometimes the memory usage goes well beyond 1GB.
>>>
>>> IMO we should do a profiling to see what causes this much of memory to
>>> be used.
>>>
>>> [image: Inline image 1]
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Thu, Jun 30, 2016 at 11:19 AM, Chamila De Alwis 
>>> wrote:
>>>
 Hi Sinthuja,

 I'm seeing around 500MB of memory usage in the DAS 3.1.0-SNAPSHOT
 "Generate Gadget" page as well, specially when the gadget is being
 previewed. At that moment, there is only one gadget in play, and the number
 of records is less than 100.


 Regards,
 Chamila de Alwis
 Committer and PMC Member - Apache Stratos
 Software Engineer | WSO2 | +94772207163
 Blog: code.chamiladealwis.com



 On Wed, Jun 29, 2016 at 11:53 PM, Sinthuja Ragendran >>> > wrote:

> Hi Chamila,
>
> I think this is specifically for analytics dashboard right, and not
> for simple dashboards? In that case, we need to check how the gadgets have
> been written, and because the actual data is being fetched from DAS into
> this gadgets, and I believe the fetched data to display in gadget is
> consuming more memory. Can you try to delete some gadgets from the above
> page and see whether there is an improvement?
>
> @Dunith/Tharik, Whether data is loaded in paginated manner (ie, not
> load all, only load the data which is required for the specific page)? And
> do we load events with its all attributes or only with specific attributes
> we required to show? I believe we have done some testing for ESB analytics
> case right, didn't we hit this sort of issue in our local testing?
>
> Thanks,
> Sinthuja.
>
>
> On Thu, Jun 30, 2016 at 9:19 AM, Nipuna Chandradasa 
> wrote:
>
>> [Adding Udara,Sinthuja, and Tanya]
>>
>> Hi Chamila,
>>
>> This much of memory never used by shindig on gadget rendering.
>> Because gadgets are pretty simple as i check them. There must be some pre
>> processes going on. That might cause this kind of memory usage.
>>
>> Thank you,
>>
>> On Thu, Jun 30, 2016 at 1:46 AM, Chamila De Alwis 
>> wrote:
>>
>>> Hi,
>>>
>>> ESB 5.0.0 beta analytics dashboard seems to be taking a considerable
>>> amount of memory to operate. I noticed the following in
>>> Chrome 51.0.2704.103 m (64-bit) in Windows.
>>>
>>>
>>> [image: Inline image 2]
>>>
>>> Next to Gmail Inbox, ESB Dashboard takes about average 400MB to
>>> operate. This can sometimes go up to more than 700MB when browsing 
>>> through
>>> pages.
>>>
>>> I compared the memory usage against Grafana demo, Grafana Playground
>>> [1] and a Kibana4 demo[2], which takes average 150MB and 200MB of memory
>>> respectively.
>>>
>>> IMO there's room for this memory usage to be reduced. Since
>>> dashboards would likely be used frequently, reducing the memory 
>>> footprint
>>> would add a considerable amount of value to the user experience.
>>>
>>> [1] - http://play.grafana.org/
>>> [2] -
>>> https://kibana.logit.io/app/kibana#/dashboard/Demo-IIS-Dashboard
>>>