Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Prasanna Dangalla
Hi All, On Fri, Mar 31, 2017 at 7:00 AM Chamalee De Silva wrote: > Hi, > Agree with Raj and Nuwan. > > But considering the user PoV, > In a situation where we change state of an Published API to maintenance > state, make the change and published back, > what if the subscriber

Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Chamalee De Silva
Hi, Agree with Raj and Nuwan. But considering the user PoV, In a situation where we change state of an Published API to maintenance state, make the change and published back, what if the subscriber is not happy with the updates which makes to the Published API ? (Assume that the changes are some

Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Rajkumar Rajaratnam
I completely agree with Nuwan. We should support updating published API without increasing the version. Think about a banking industry. If there is a critical bug in the mediation logic (lets say a masking logic), they should be able to fix the issue in the same version transparently without even

Re: [Dev] How to write test cases for microservices registered via uuf app

2017-03-30 Thread Niranjan Karunanandham
Hi Denuwanthi, In C 5.2.0-m3, we have introduced pax exam container level testing [1]. Did you check if we can test it via it? [1] - https://github.com/wso2/carbon-kernel/blob/master/docs/DeveloperTools/UsingIn-ContainerOSGiTesting.md Regards, Nira On Tue, Mar 28, 2017 at 11:05 PM, Denuwanthi

Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Nuwan Dias
Hi Malintha, Yes, the workflow you have mentioned is the same one I'm proposing too. My only concern is on a new state, because implementing that is a bit complicated and this particular use case is not very common and therefore there's little ROI :). Let's say we call this new state

Re: [Dev] [Findings] JMX access control : readOnly and readWrite access

2017-03-30 Thread Imesh Gunaratne
On Thu, Mar 30, 2017 at 3:02 PM, Asma Jabir wrote: > Hi > > I have been looking into the $subject issue in the github c5 repo [1] and > following is the summary of the findings till date. > > - There is a simple inbuilt authentication and authorization mechanism in > JMX using

Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Rukshan Premathunga
Hi malintha, in c5 we decided to keep in the gateway even in the create state for purpose of creator's testing. so this will be fine. but keeping additional info in the create state not something good. because create state is the state very first state when an api is create. because of that I'm

Re: [Dev] GSoC 2017 - JMeter Test Manager for Distributed Deployments of WSO2 Servers

2017-03-30 Thread Yasassri Ratnayake
On Thu, Mar 30, 2017 at 6:19 PM, Thilina Manamgoda wrote: > Hi Yasassri, > > I think if we can build docker files for each profile and kept in a > private registry it would be easy. If this is possible no need to build > Docker images in web app. Also we need to build

Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Malintha Amarasinghe
Hi Nuwan, On Fri, Mar 31, 2017 at 12:12 AM, Nuwan Dias wrote: > Hi Pubudu, > > The API will reside on the Gateway irrespective of its state. So this > action doesn't interrupt existing subscribers or existing consumers of the > API. It only prevents any new subscribers from

Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Fazlan Nazeem
Hi Prasanna, On Fri, Mar 31, 2017 at 1:14 AM Prasanna Dangalla wrote: > Hi Fazlan, > > On Thu, Mar 30, 2017 at 9:12 PM Fazlan Nazeem wrote: > > I don't think we should allow anyone to do changes to an already published > API regardless of whether he/she is

Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Sajith Kariyawasam
Updating a technical information of a published API would result in incompatibility issues in clients who already consumes this API and as Fazlan pointed out I also think that any change should result in a new version. If such a change is required, can't we alert / send an email to subscribers and

Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Prasanna Dangalla
Hi Fazlan, On Thu, Mar 30, 2017 at 9:12 PM Fazlan Nazeem wrote: > I don't think we should allow anyone to do changes to an already published > API regardless of whether he/she is a creator or publisher. > Any change done to an already published API is not the same API which

Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Fazlan Nazeem
I don't think we should allow anyone to do changes to an already published API regardless of whether he/she is a creator or publisher. Any change done to an already published API is not the same API which was published previously. Some of the changes could break the clients who are already

Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Nuwan Dias
Hi Pubudu, The API will reside on the Gateway irrespective of its state. So this action doesn't interrupt existing subscribers or existing consumers of the API. It only prevents any new subscribers from seeing the API on the store until republished. I have thought about introducing a new LC

Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Pubudu Gunatilaka
Hi Nuwan, AFAIU, in this case, we are not addressing the original issue. Original issue here is changes made by API developers should not be reflected in Store and Gateway unless the API publisher publishes the API again. Please correct me if I am wrong. I don't think temporarily removing the

Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Nuwan Dias
Hi Rukshan, Since the API still exists in the database the subscriptions will be preserved. Existing subscribers to the API will still see the API (under subscriptions) as well. It will only be unavailable for new subscriptions until re-published. Thanks, NuwanD. On Thu, Mar 30, 2017 at 11:41

Re: [Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Rukshan Premathunga
Hi Nuwan, If we demote API back to create, state how we are going to handle subscription already have? Are we going to disable them till the API get publish again? Also can we introduce or use the existing state to allow the API to be update without un-publishing it. once it is done we can

[Dev] Preventing API Developers from updating an API once its Published

2017-03-30 Thread Nuwan Dias
Hi, On API Manager, API Developers (!= publishers) aren't able to publish an API to the Store or Gateway. But on API Manager version 2.1.0 and before, if an API Developer makes an update to an API that is already published, the changes made by the developer are immediately reflected on the Store

Re: [Dev] [GSoC 2017][IS] SCIM 2.0 Compliance Test Suite

2017-03-30 Thread Vindula Jayawardana
Hi, As mentioned above, I looked at the SCIM 1.1 compliance test suite [1]. Due to the reason that the SCIM 1.1 test suite requires an internet facing SCIM 1.1 server to run the tests against, I setup-ed an Identity Server instance in AWS [2]. However when the test are run, it fails due to

[Dev] Display only Production Services in Governance Registry Store

2017-03-30 Thread Denson, Ed
Hello All, We are running GREG 5.3.0 and I am wondering if there is a way to limit the display of Services (REST/SOAP) to only those is a lifecycle state of Production to be displayed in the Store. I want to allow the developers to update their services using the Publisher, but not have it

Re: [Dev] [GSoC][Siddhi][CEP]: Siddhi Pattern for Absence of Events

2017-03-30 Thread Sriskandarajah Suhothayan
I have given some feedback on the gsoc site. Suho On Mon, Mar 27, 2017 at 9:03 PM, Gobinath wrote: > Hi all, > > Thanks. I have shared the draft of my proposal titled "Non-Occurrence of > Events for Siddhi Patterns" with WSO2 through GSoC dashboard and requesting > your

Re: [Dev] about GSOC

2017-03-30 Thread Sriskandarajah Suhothayan
Your idea looks good, I have given some comments on the GSoC site. Also please also send the message to d...@wso2.com in the future. Suho On Wed, Mar 29, 2017 at 6:45 AM, 정형근 wrote: > Hello, I am a graduate student at Chungnam National University in Korea. > Last time I

Re: [Dev] [C5] Deployment folder specific to runtime or to server?

2017-03-30 Thread Thusitha Thilina Dayaratne
We will be using both ServerHome/deployment and ServerHome/wso2/{runtime}/deployment directories. Please refer to architecture mailing list[1] [1] - [Architecture] Multiple runtime support for C5 based products Thanks Thusitha On Wed, Mar 8, 2017 at 5:49 PM, Niranjan Karunanandham

Re: [Dev] GSoC 2017 - JMeter Test Manager for Distributed Deployments of WSO2 Servers

2017-03-30 Thread Thilina Manamgoda
Hi Yasassri, I think if we can build docker files for each profile and kept in a private registry it would be easy. If this is possible no need to build Docker images in web app. Also we need to build Kubernetes artifacts for those profile as well. regards, Thilina On Mon, Mar 27, 2017 at 8:49

Re: [Dev] Build failure in Product-EI

2017-03-30 Thread Sinthuja Ragendran
Hi Eranda, Unfortunately, the problem still exists though I have build locally carbon-mediation. :( Thanks, Sinthuja, On Thu, Mar 30, 2017 at 4:04 PM, Eranda Rajapakshe wrote: > Hi, > > We did a clean repo build a few hours ago, and it passed without an issue. > And we have

Re: [Dev] Build failure in Product-EI

2017-03-30 Thread Eranda Rajapakshe
Hi, We did a clean repo build a few hours ago, and it passed without an issue. And we have just triggered another one, in order to check if its a dependency issue. Can you please build cabon-mediation[1] repo locally and try to build product-ei. It might be able to solve the issue from your end.

Re: [Dev] Build failure in Product-EI

2017-03-30 Thread Sinthuja Ragendran
Hi Madhawa, The error comes from [1], and it's using the carbon.mediation.version, and it's referring to SNAPSHOT [2]. [1] https://github.com/wso2/product-ei/blob/master/p2-profile/ei-profile/pom.xml#L113 [2] https://github.com/wso2/product-ei/blob/master/pom.xml#L1241 Thanks, Sinthuja. On

Re: [Dev] Build failure in Product-EI

2017-03-30 Thread Madhawa Gunasekara
Hi Sinthuja, Did you build the master branch? because we don't have referred analytics version as 4.6.19.SNAPSHOT. Can you try building the master branch? 5.1.3 [1] https://github.com/wso2/product-ei/blob/master/pom.xml#L1271 Thanks, Madhawa On Thu, Mar 30, 2017 at 3:19 PM, Sinthuja Ragendran

[Dev] Build failure in Product-EI

2017-03-30 Thread Sinthuja Ragendran
Hi, I'm getting the below error when building the product-ei master. Please note, I have tried building with java 1.7 and 1.8. Also with clean m2, but no luck. An error occurred while configuring the installed items session context was:(profile=default,

[Dev] [Findings] JMX access control : readOnly and readWrite access

2017-03-30 Thread Asma Jabir
Hi I have been looking into the $subject issue in the github c5 repo [1] and following is the summary of the findings till date. - There is a simple inbuilt authentication and authorization mechanism in JMX using password and access files. Roles can be specified with either readOnly or readWrite

Re: [Dev] [GSoC] Proposal 24 : Real-Time Machine Learning Toolkit for Siddhi

2017-03-30 Thread Sriskandarajah Suhothayan
@Upul can you go through this. On Wed, Mar 29, 2017 at 8:38 PM, Nadheesh Jihan wrote: > Hi, > > I have shared the draft proposal for the GSoC proposal - 24 via the GSoC > web portal. Please review it and let me know if there are any changes > required in the proposal. > >

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

2017-03-30 Thread Rajith Roshan
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