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

[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 is not happy with the updates which makes to the
> Published API ? (Assume that the changes are some technical information and
> not merely a bug fix).
>
>
> Because subscriber is not knowing what will be the change that will happen
> to the API.
> Adding to what Sajith has pointed out,
> I also think there should be a proper notification mechanism and *also*
> there should be a way of handling this user experience issue as well.
>
>
>
> Thanks,
> Chamalee
>
>
>
> On Fri, Mar 31, 2017 at 10:10 AM, Rajkumar Rajaratnam 
> wrote:
>
> 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 letting customer know that there is a bug. Publishing a minor version
> with a minor backward compatible fix and asking customers to update their
> app to call latest minor version is not an option for these kind of
> industries.
>
> Another example, what if we want to make some minor changes in API
> documentation? New API release for this kind of scenario is an over kill.
>
> Thanks.
>
> On Fri, Mar 31, 2017 at 12:04 AM Nuwan Dias  wrote:
>
> 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 "MAINTENANCE", what's the difference
> between bringing an API to "MAINTENANCE" vs "CREATED"? If we bring an API
> to "MAINTENANCE", does it mean that there is a copy of the API left which
> is in "PUBLISHED" state?
>
> @Fazlan, in theory it is true that updating a published API is wrong. But
> in practice it sometimes happens because not everyone adheres to the best
> practices 100% always. Users may opt to make backwards compatible changes
> on the same minor version and some users don't even use minor versions at
> all. So forcing to create a new version of the API and forcing their
> clients to move to the newer version always is a bit too restrictive IMO
>
>
Yes this is what my idea as well. +1 for the notification mecanism too. But
I have a doubt about how we garntee that doing a change will not affect the
existing API functionality?

Thanks
Prasanna

> .
>
> Thanks,
> NuwanD.
>
> On Fri, Mar 31, 2017 at 8:41 AM, Rukshan Premathunga 
> wrote:
>
> 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 +1 for additional state.
>
> Thanks and Regards
>
> On Mar 31, 2017 8:10 AM, "Malintha Amarasinghe" 
> wrote:
>
> 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 seeing the API on the store
> until republished.
>
> I have thought about introducing a new LC state as well. But that only
> doesn't solve this issue. We need to build a mechanism to make a copy of
> the API and store the developer's changes elsewhere until a publisher
> approves the changes. Building that whole workflow is non trivial and
> leaves a lot more to think about as well. Besides, the above usecase is not
> standard practice since its not a good idea to make technical changes to
> published APIs. But the reality is that the real world needs it and hence
> we need to support it.
>
> If we are allowing this, I also feel a need of a new lifecycle state.
> Because, in usual CREATED state, we do not allow the API to reside in
> Gateway. But in *this* CREATED state, we are allowing the API to reside in
> Gateway (which is the API with previous details).
>
> Let me summerise the complete flow, just to double check my understanding.
>
> 1. An API is in Published state.
> 2. A Developer wants to make some technical changes to the API.
> 3. Publisher makes the API Created state (or some new state).
>
> Now the API is not visible on Store, but existing subscriptions are still
> valid.
>
> The previous API is available on GW, so existing invocations are working
> without any issue. (This, we did not allow in CREATED 

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

[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 technical information and
not merely a bug fix).


Because subscriber is not knowing what will be the change that will happen
to the API.
Adding to what Sajith has pointed out,
I also think there should be a proper notification mechanism and *also*
there should be a way of handling this user experience issue as well.



Thanks,
Chamalee



On Fri, Mar 31, 2017 at 10:10 AM, Rajkumar Rajaratnam 
wrote:

> 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 letting customer know that there is a bug. Publishing a minor version
> with a minor backward compatible fix and asking customers to update their
> app to call latest minor version is not an option for these kind of
> industries.
>
> Another example, what if we want to make some minor changes in API
> documentation? New API release for this kind of scenario is an over kill.
>
> Thanks.
>
> On Fri, Mar 31, 2017 at 12:04 AM Nuwan Dias  wrote:
>
>> 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 "MAINTENANCE", what's the difference
>> between bringing an API to "MAINTENANCE" vs "CREATED"? If we bring an API
>> to "MAINTENANCE", does it mean that there is a copy of the API left which
>> is in "PUBLISHED" state?
>>
>> @Fazlan, in theory it is true that updating a published API is wrong. But
>> in practice it sometimes happens because not everyone adheres to the best
>> practices 100% always. Users may opt to make backwards compatible changes
>> on the same minor version and some users don't even use minor versions at
>> all. So forcing to create a new version of the API and forcing their
>> clients to move to the newer version always is a bit too restrictive IMO.
>>
>> Thanks,
>> NuwanD.
>>
>> On Fri, Mar 31, 2017 at 8:41 AM, Rukshan Premathunga 
>> wrote:
>>
>> 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 +1 for additional state.
>>
>> Thanks and Regards
>>
>> On Mar 31, 2017 8:10 AM, "Malintha Amarasinghe" 
>> wrote:
>>
>> 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 seeing the API on the store
>> until republished.
>>
>> I have thought about introducing a new LC state as well. But that only
>> doesn't solve this issue. We need to build a mechanism to make a copy of
>> the API and store the developer's changes elsewhere until a publisher
>> approves the changes. Building that whole workflow is non trivial and
>> leaves a lot more to think about as well. Besides, the above usecase is not
>> standard practice since its not a good idea to make technical changes to
>> published APIs. But the reality is that the real world needs it and hence
>> we need to support it.
>>
>> If we are allowing this, I also feel a need of a new lifecycle state.
>> Because, in usual CREATED state, we do not allow the API to reside in
>> Gateway. But in *this* CREATED state, we are allowing the API to reside in
>> Gateway (which is the API with previous details).
>>
>> Let me summerise the complete flow, just to double check my understanding.
>>
>> 1. An API is in Published state.
>> 2. A Developer wants to make some technical changes to the API.
>> 3. Publisher makes the API Created state (or some new state).
>>
>> Now the API is not visible on Store, but existing subscriptions are still
>> valid.
>>
>> The previous API is available on GW, so existing invocations are working
>> without any issue. (This, we did not allow in CREATED state in C4)
>>
>> 4. Developer makes changes to the API
>> 5. Publisher accepts the changes (which means the API's lifecycle is
>> changed to Published)
>> 6. New changes are updated on the GW.
>>
>>
>> Thanks!
>> Malintha
>>
>>
>> Thanks,
>> NuwanD.
>>
>> On 

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

[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 letting customer know that there is a bug. Publishing a minor version
with a minor backward compatible fix and asking customers to update their
app to call latest minor version is not an option for these kind of
industries.

Another example, what if we want to make some minor changes in API
documentation? New API release for this kind of scenario is an over kill.

Thanks.

On Fri, Mar 31, 2017 at 12:04 AM Nuwan Dias  wrote:

> 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 "MAINTENANCE", what's the difference
> between bringing an API to "MAINTENANCE" vs "CREATED"? If we bring an API
> to "MAINTENANCE", does it mean that there is a copy of the API left which
> is in "PUBLISHED" state?
>
> @Fazlan, in theory it is true that updating a published API is wrong. But
> in practice it sometimes happens because not everyone adheres to the best
> practices 100% always. Users may opt to make backwards compatible changes
> on the same minor version and some users don't even use minor versions at
> all. So forcing to create a new version of the API and forcing their
> clients to move to the newer version always is a bit too restrictive IMO.
>
> Thanks,
> NuwanD.
>
> On Fri, Mar 31, 2017 at 8:41 AM, Rukshan Premathunga 
> wrote:
>
> 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 +1 for additional state.
>
> Thanks and Regards
>
> On Mar 31, 2017 8:10 AM, "Malintha Amarasinghe" 
> wrote:
>
> 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 seeing the API on the store
> until republished.
>
> I have thought about introducing a new LC state as well. But that only
> doesn't solve this issue. We need to build a mechanism to make a copy of
> the API and store the developer's changes elsewhere until a publisher
> approves the changes. Building that whole workflow is non trivial and
> leaves a lot more to think about as well. Besides, the above usecase is not
> standard practice since its not a good idea to make technical changes to
> published APIs. But the reality is that the real world needs it and hence
> we need to support it.
>
> If we are allowing this, I also feel a need of a new lifecycle state.
> Because, in usual CREATED state, we do not allow the API to reside in
> Gateway. But in *this* CREATED state, we are allowing the API to reside in
> Gateway (which is the API with previous details).
>
> Let me summerise the complete flow, just to double check my understanding.
>
> 1. An API is in Published state.
> 2. A Developer wants to make some technical changes to the API.
> 3. Publisher makes the API Created state (or some new state).
>
> Now the API is not visible on Store, but existing subscriptions are still
> valid.
>
> The previous API is available on GW, so existing invocations are working
> without any issue. (This, we did not allow in CREATED state in C4)
>
> 4. Developer makes changes to the API
> 5. Publisher accepts the changes (which means the API's lifecycle is
> changed to Published)
> 6. New changes are updated on the GW.
>
>
> Thanks!
> Malintha
>
>
> Thanks,
> NuwanD.
>
> On Thu, Mar 30, 2017 at 11:52 PM, Pubudu Gunatilaka 
> wrote:
>
> 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 API is the best solution if it is
> already serving requests.
>
> What if we introduce another life cycle state and transfer the API to that
> state until API publisher re-publishes the API. In this way, there is no
> effect to the existing API.
>
> Thank you!
>
> On Thu, Mar 30, 2017 at 11:41 PM, Rukshan Premathunga 
> wrote:
>
> Hi Nuwan,
>
> If we demote API back to create, state how we are going to handle
> subscription already 

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

[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 De Silva 
wrote:

> Hi,
>
> 1. I have a micro service registered in a uuf app via component.yaml
>
> apis:
>   - className: 
> "org.wso2.is.portal.user.client.api.micro.PasswordUtilityMicroService"
> uri: "/passwordUtil-micro-service/"
>
> Now, the url for the micorservice is in the form of
>
> /admin-portal/root/apis/passwordUtil-micro-service/validatePassword
>
> 2. Inside the microservice I call an OSGI service.
>
> BundleContext bundleContext = 
> FrameworkUtil.getBundle(PasswordValidationService.class).getBundleContext();
>
>
> 3.When writing a test case with 'MicroServicesRunner' since it is a
> non-osgi environment, my OSGI service is not fetched.
>
> 4.Then we tried to write as an osgi test. Then it says it cannot find
> 'admin-portal' app
>
>
> Is there a way we can deploy the uuf app when running the tests?(We are on
> kernel 5.1.0)
>
>
> Thanks
> --
> Denuwanthi De Silva
> Senior Software Engineer;
> WSO2 Inc.; http://wso2.com,
> Email: denuwan...@wso2.com
> Blog: https://denuwanthi.wordpress.com/
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 


*Niranjan Karunanandham*
Associate Technical Lead - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[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 "MAINTENANCE", what's the difference
between bringing an API to "MAINTENANCE" vs "CREATED"? If we bring an API
to "MAINTENANCE", does it mean that there is a copy of the API left which
is in "PUBLISHED" state?

@Fazlan, in theory it is true that updating a published API is wrong. But
in practice it sometimes happens because not everyone adheres to the best
practices 100% always. Users may opt to make backwards compatible changes
on the same minor version and some users don't even use minor versions at
all. So forcing to create a new version of the API and forcing their
clients to move to the newer version always is a bit too restrictive IMO.

Thanks,
NuwanD.

On Fri, Mar 31, 2017 at 8:41 AM, Rukshan Premathunga 
wrote:

> 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 +1 for additional state.
>
> Thanks and Regards
>
> On Mar 31, 2017 8:10 AM, "Malintha Amarasinghe" 
> wrote:
>
>> 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 seeing the API on the store
>>> until republished.
>>>
>>> I have thought about introducing a new LC state as well. But that only
>>> doesn't solve this issue. We need to build a mechanism to make a copy of
>>> the API and store the developer's changes elsewhere until a publisher
>>> approves the changes. Building that whole workflow is non trivial and
>>> leaves a lot more to think about as well. Besides, the above usecase is not
>>> standard practice since its not a good idea to make technical changes to
>>> published APIs. But the reality is that the real world needs it and hence
>>> we need to support it.
>>>
>> If we are allowing this, I also feel a need of a new lifecycle state.
>> Because, in usual CREATED state, we do not allow the API to reside in
>> Gateway. But in *this* CREATED state, we are allowing the API to reside in
>> Gateway (which is the API with previous details).
>>
>> Let me summerise the complete flow, just to double check my understanding.
>>
>> 1. An API is in Published state.
>> 2. A Developer wants to make some technical changes to the API.
>> 3. Publisher makes the API Created state (or some new state).
>>
>> Now the API is not visible on Store, but existing subscriptions are still
>> valid.
>>
>> The previous API is available on GW, so existing invocations are working
>> without any issue. (This, we did not allow in CREATED state in C4)
>>
>> 4. Developer makes changes to the API
>> 5. Publisher accepts the changes (which means the API's lifecycle is
>> changed to Published)
>> 6. New changes are updated on the GW.
>>
>>
>> Thanks!
>> Malintha
>>
>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Thu, Mar 30, 2017 at 11:52 PM, Pubudu Gunatilaka 
>>> wrote:
>>>
 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 API is the best solution if it
 is already serving requests.

 What if we introduce another life cycle state and transfer the API to
 that state until API publisher re-publishes the API. In this way, there is
 no effect to the existing API.

 Thank you!

 On Thu, Mar 30, 2017 at 11:41 PM, Rukshan Premathunga  wrote:

> 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 publish it again
> with the changes. Because in if we demote to create state, we cannot have
> subscription information right?
>
> Thanks and Regards
>
> On Thu, Mar 30, 2017 at 11:15 PM, Nuwan Dias  wrote:
>
>> 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 

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

[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 password and access files. Roles can be specified with either
> readOnly or readWrite privileges [2].
>
>- *readOnly* does not allow to change values or to invoke operations
>but can monitor
>- *readWrite *gives the total control over the server which allows to
>change values and invoke operations
>
> Great work Asma!
​Will you be able to share the sample application that you implemented for
verifying this functionality?

Thanks
Imesh


> - Both password and access files are properties based text files for
> specifying username/password pairs and username/access pairs respectively.
>
> - The password and access files could reside anywhere in the server and
> should be provided upon server startup.
>
> - SSL is enabled by default for remote monitoring and thus the SSL should
> be configured properly after setting up a digital certificate. System
> properties for keystore and truststore should be set in the server.
>
> [1] https://github.com/wso2/carbon-kernel/issues/1247
> [2] http://docs.oracle.com/javase/7/docs/technotes/guides/
> management/agent.html
> 
>
>
> Thanks.
>
> Regards,
> Asma
> --
> Asma Zinneera Jabir
> Software Engineer
> WSO2 Inc: http://wso2.com/
> Contact No: +94 77 332 4752 <+94%2077%20332%204752>
>
>
>


-- 
*Imesh Gunaratne*
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: https://medium.com/@imesh TW: @imesh
lean. enterprise. middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[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 +1 for additional state.

Thanks and Regards

On Mar 31, 2017 8:10 AM, "Malintha Amarasinghe"  wrote:

> 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 seeing the API on the store
>> until republished.
>>
>> I have thought about introducing a new LC state as well. But that only
>> doesn't solve this issue. We need to build a mechanism to make a copy of
>> the API and store the developer's changes elsewhere until a publisher
>> approves the changes. Building that whole workflow is non trivial and
>> leaves a lot more to think about as well. Besides, the above usecase is not
>> standard practice since its not a good idea to make technical changes to
>> published APIs. But the reality is that the real world needs it and hence
>> we need to support it.
>>
> If we are allowing this, I also feel a need of a new lifecycle state.
> Because, in usual CREATED state, we do not allow the API to reside in
> Gateway. But in *this* CREATED state, we are allowing the API to reside in
> Gateway (which is the API with previous details).
>
> Let me summerise the complete flow, just to double check my understanding.
>
> 1. An API is in Published state.
> 2. A Developer wants to make some technical changes to the API.
> 3. Publisher makes the API Created state (or some new state).
>
> Now the API is not visible on Store, but existing subscriptions are still
> valid.
>
> The previous API is available on GW, so existing invocations are working
> without any issue. (This, we did not allow in CREATED state in C4)
>
> 4. Developer makes changes to the API
> 5. Publisher accepts the changes (which means the API's lifecycle is
> changed to Published)
> 6. New changes are updated on the GW.
>
>
> Thanks!
> Malintha
>
>
>> Thanks,
>> NuwanD.
>>
>> On Thu, Mar 30, 2017 at 11:52 PM, Pubudu Gunatilaka 
>> wrote:
>>
>>> 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 API is the best solution if it is
>>> already serving requests.
>>>
>>> What if we introduce another life cycle state and transfer the API to
>>> that state until API publisher re-publishes the API. In this way, there is
>>> no effect to the existing API.
>>>
>>> Thank you!
>>>
>>> On Thu, Mar 30, 2017 at 11:41 PM, Rukshan Premathunga 
>>> wrote:
>>>
 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 publish it again
 with the changes. Because in if we demote to create state, we cannot have
 subscription information right?

 Thanks and Regards

 On Thu, Mar 30, 2017 at 11:15 PM, Nuwan Dias  wrote:

> 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 and Gateway. This kind of beats the purpose of preventing API
> Developers from publishing APIs to the Store and Gateway directly.
>
> For API Manager 3.0.0, I suggest that we prevent the API being updated
> by API Developers after the API has gone beyond the "CREATED" state. API
> Publishers should still be allowed to make updates to the fields they are
> eligible for (non technical information). If someone badly needs to update
> technical information of a published API, they should first bring the API
> to the "CREATED" state, which will make the API disappear temporarily and
> bring it back to "PUBLISHED" once the changes are saved.
>
> Thanks,
> NuwanD.
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>



 --
 Rukshan Chathuranga.
 Software Engineer.
 

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

[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 Kubernetes artifacts for
> those profile as well.
>

What you need to take into cosideration is, that the pack (e.g : ESB 4.9.0)
is going to change, we are planning to use this to Test packs released with
WUM (WSO2 Update Manager) as well. WUM gives a new distribution pack with
the latest fixes. So we need to cater this as well.


>
> regards,
> Thilina
>
> On Mon, Mar 27, 2017 at 8:49 AM, Yasassri Ratnayake 
> wrote:
>
>> Hi Thilina,
>>
>> On Sun, Mar 26, 2017 at 4:07 AM, Thilina Manamgoda > > wrote:
>>
>>> Hi Yasassri,
>>>
>>> Please find my comments inline.
>>>
>>> On Wed, Mar 22, 2017 at 8:12 PM, Yasassri Ratnayake 
>>> wrote:
>>>
 Hi Thilina,

 We have missed some requirements. Please consider the following as well.

 1. We need a Tomcat instance to host the Backends(Weapps) which are
 required by the Test Scripts. So we need another instance spawned with
 Tomcat. After spawning the instance you can deploy the prerequisite web
 apps. (These web apps will be available in the Test-Repo under resources)

>>>
>>>  Yes of course we can archieve this as well.
>>>
>>> 2. Also when deploying Jmeter we need to copy 3rd party Jars to Jmeter.
 (These are also available in the repository)

>>>
>>>
 This can be done by copying these files to docker image in Jmeter
 docker image building stage.

>>>
>>>
 Also answering your question about the Deployment profiles. We have
 identified several components to make the scope manageable.

 *Products*
 ESB | V4.9 & V5.0
 APIM | V1.9 & V2.0

 *JDK*
 JAVA | V1.7 & V1.8

 *DataBase*
 MySQL

 *Third Party Servers*
 Brokers | ActiveMQ 5.10 | WSO2 MB 3.1 (Only applicable when ESB is used)

 So a Sample Profile would be, *ESB 4.9 + JAVA 1.7 + MYSQL + ActiveMQ*.
 For now, you can concentrate on the above components when determining a
 deployment profile. But your solution should be scalable.

 Is this a profile described here:https://docs.wso2.com/dis
>>> play/KA100/Clustered+Deployment+of+WSO2+Products+on+Kubernetes . If it
>>> is, then do I need to configure the product with third party servers or
>>> it's already done and I only have to deploy selected profile's servers into
>>> kubernetes cluster. For example let's take the above profile, in order to
>>> run this delpoyment ESB should be configured with MYSQL and Active MQ API
>>> endpoints. Do i need to change the configuration files of ESB or it's
>>> already taken care of and deployment is done once i deploy Kubernetes
>>> artifacts under the selected profile.
>>>
>>
>> Existing scripts doesn't allow us to configure thirdparty dependencies
>> like Message Brokers. So yes we need to change ESB configurations depending
>> on the Broker, you can refer [1
>> ] for
>> ActiveMQ configurations.
>>
>>
>>>
>>> Is this a profile of ESB : https://github.com/wso2/kube
>>> rnetes-artifacts/tree/master/wso2esb ?
>>>
>>
>> Yes this script supports two profiles, default ESB profile and worker
>> manager profile, but as mentioned we neeed to tweek these scripts to
>> support mesage brokers as well.
>>
>>
>>> Also can't we have a private docker registry to hold our deplyment's
>>> images instead of building docker images via the web app ?.
>>>


>> We can use a private registry to store the docker images but you need to
>> comeup with some scripts to Auomate the process in that case.
>>
>>
>> [1] - https://docs.wso2.com/display/ESB490/Configure+with+ActiveMQ
>> --
>> Yasassri Ratnayake
>> Senior Software Engineer - QA
>> WSO2 Inc ; http://wso2.com
>> lean.enterprise.middleware
>> *Mobile : +94715933168 <+94%2071%20593%203168>*
>> *Blogs : http://yasassriratnayake.blogspot.com
>> *
>> *http://wso2logs.blogspot.com *
>>
>
>


-- 
Yasassri Ratnayake
Senior Software Engineer - QA
WSO2 Inc ; http://wso2.com
lean.enterprise.middleware
*Mobile : +94715933168 <+94%2071%20593%203168>*
*Blogs : http://yasassriratnayake.blogspot.com
*
*http://wso2logs.blogspot.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[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 seeing the API on the store
> until republished.
>
> I have thought about introducing a new LC state as well. But that only
> doesn't solve this issue. We need to build a mechanism to make a copy of
> the API and store the developer's changes elsewhere until a publisher
> approves the changes. Building that whole workflow is non trivial and
> leaves a lot more to think about as well. Besides, the above usecase is not
> standard practice since its not a good idea to make technical changes to
> published APIs. But the reality is that the real world needs it and hence
> we need to support it.
>
If we are allowing this, I also feel a need of a new lifecycle state.
Because, in usual CREATED state, we do not allow the API to reside in
Gateway. But in *this* CREATED state, we are allowing the API to reside in
Gateway (which is the API with previous details).

Let me summerise the complete flow, just to double check my understanding.

1. An API is in Published state.
2. A Developer wants to make some technical changes to the API.
3. Publisher makes the API Created state (or some new state).

Now the API is not visible on Store, but existing subscriptions are still
valid.

The previous API is available on GW, so existing invocations are working
without any issue. (This, we did not allow in CREATED state in C4)

4. Developer makes changes to the API
5. Publisher accepts the changes (which means the API's lifecycle is
changed to Published)
6. New changes are updated on the GW.


Thanks!
Malintha


> Thanks,
> NuwanD.
>
> On Thu, Mar 30, 2017 at 11:52 PM, Pubudu Gunatilaka 
> wrote:
>
>> 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 API is the best solution if it is
>> already serving requests.
>>
>> What if we introduce another life cycle state and transfer the API to
>> that state until API publisher re-publishes the API. In this way, there is
>> no effect to the existing API.
>>
>> Thank you!
>>
>> On Thu, Mar 30, 2017 at 11:41 PM, Rukshan Premathunga 
>> wrote:
>>
>>> 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 publish it again
>>> with the changes. Because in if we demote to create state, we cannot have
>>> subscription information right?
>>>
>>> Thanks and Regards
>>>
>>> On Thu, Mar 30, 2017 at 11:15 PM, Nuwan Dias  wrote:
>>>
 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 and Gateway. This kind of beats the purpose of preventing API
 Developers from publishing APIs to the Store and Gateway directly.

 For API Manager 3.0.0, I suggest that we prevent the API being updated
 by API Developers after the API has gone beyond the "CREATED" state. API
 Publishers should still be allowed to make updates to the fields they are
 eligible for (non technical information). If someone badly needs to update
 technical information of a published API, they should first bring the API
 to the "CREATED" state, which will make the API disappear temporarily and
 bring it back to "PUBLISHED" once the changes are saved.

 Thanks,
 NuwanD.

 --
 Nuwan Dias

 Software Architect - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729 <+94%2077%20777%205729>

>>>
>>>
>>>
>>> --
>>> Rukshan Chathuranga.
>>> Software Engineer.
>>> WSO2, Inc.
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Pubudu Gunatilaka*
>> Committer and PMC Member - Apache Stratos
>> Software Engineer
>> WSO2, Inc.: http://wso2.com
>> mobile : +94774078049 <%2B94772207163>
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>
> ___
> Dev mailing list
> 

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

[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 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 consuming this API.
>
> What if we enforce by design, that any update to an already published API
> should be a new version of the same API. This way the updated API will go
> through the same API lifecycle and we do not have the original problem
> raised here.
>
>
> In this approach what will happend to the existing subscriptions for the
> new API version? Let say we the change needs to go to all the subscribers
> and when we create a new API version we have to create all subscriptions
> that exists for the previous API. Correct me if I'm wrong.
>

Since this will be a new version of the API, previous subscribers shouldn't
be subscribed to the new version automatically. Subscribers would need to
subcribe to the new version separately if they need to. In other words this
will act as a completely new API with the same name but a different version.

IMHO i think we should not support the usecase you mentioned. I.e changing
an api which already has subscribers. Subscribers subscribed to the
original API and not for the updated one. But this is open for discussion.



> 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 seeing the API on the store
> until republished.
>
> I have thought about introducing a new LC state as well. But that only
> doesn't solve this issue. We need to build a mechanism to make a copy of
> the API and store the developer's changes elsewhere until a publisher
> approves the changes. Building that whole workflow is non trivial and
> leaves a lot more to think about as well. Besides, the above usecase is not
> standard practice since its not a good idea to make technical changes to
> published APIs. But the reality is that the real world needs it and hence
> we need to support it.
>
> Thanks,
> NuwanD.
>
> On Thu, Mar 30, 2017 at 11:52 PM, Pubudu Gunatilaka 
> wrote:
>
> 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 API is the best solution if it is
> already serving requests.
>
> What if we introduce another life cycle state and transfer the API to that
> state until API publisher re-publishes the API. In this way, there is no
> effect to the existing API.
>
> Thank you!
>
> On Thu, Mar 30, 2017 at 11:41 PM, Rukshan Premathunga 
> wrote:
>
> 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 publish it again
> with the changes. Because in if we demote to create state, we cannot have
> subscription information right?
>
> Thanks and Regards
>
> On Thu, Mar 30, 2017 at 11:15 PM, Nuwan Dias  wrote:
>
> 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
> and Gateway. This kind of beats the purpose of preventing API Developers
> from publishing APIs to the Store and Gateway directly.
>
> For API Manager 3.0.0, I suggest that we prevent the API being updated by
> API Developers after the API has gone beyond the "CREATED" state. API
> Publishers should still be allowed to make updates to the fields they are
> eligible for (non technical information). If someone badly needs to update
> technical information of a published API, they should first bring the API
> to the "CREATED" state, which will make the API disappear temporarily and
> bring it back to "PUBLISHED" once the changes are saved.
>
> Thanks,
> NuwanD.
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>
>
>
>
> --
> Rukshan Chathuranga.
> Software Engineer.
> WSO2, Inc.
>
> ___
> 

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

[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 let them know about the deprecation plan, and when will be
the new version available, so that they can smoothly switch to the new
version.

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 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 consuming this API.
>>
>> What if we enforce by design, that any update to an already published API
>> should be a new version of the same API. This way the updated API will go
>> through the same API lifecycle and we do not have the original problem
>> raised here.
>>
>
> In this approach what will happend to the existing subscriptions for the
> new API version? Let say we the change needs to go to all the subscribers
> and when we create a new API version we have to create all subscriptions
> that exists for the previous API. Correct me if I'm wrong.
>
>>
>> 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 seeing the API on the store
>> until republished.
>>
>> I have thought about introducing a new LC state as well. But that only
>> doesn't solve this issue. We need to build a mechanism to make a copy of
>> the API and store the developer's changes elsewhere until a publisher
>> approves the changes. Building that whole workflow is non trivial and
>> leaves a lot more to think about as well. Besides, the above usecase is not
>> standard practice since its not a good idea to make technical changes to
>> published APIs. But the reality is that the real world needs it and hence
>> we need to support it.
>>
>> Thanks,
>> NuwanD.
>>
>> On Thu, Mar 30, 2017 at 11:52 PM, Pubudu Gunatilaka 
>> wrote:
>>
>> 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 API is the best solution if it is
>> already serving requests.
>>
>> What if we introduce another life cycle state and transfer the API to
>> that state until API publisher re-publishes the API. In this way, there is
>> no effect to the existing API.
>>
>> Thank you!
>>
>> On Thu, Mar 30, 2017 at 11:41 PM, Rukshan Premathunga 
>> wrote:
>>
>> 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 publish it again
>> with the changes. Because in if we demote to create state, we cannot have
>> subscription information right?
>>
>> Thanks and Regards
>>
>> On Thu, Mar 30, 2017 at 11:15 PM, Nuwan Dias  wrote:
>>
>> 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
>> and Gateway. This kind of beats the purpose of preventing API Developers
>> from publishing APIs to the Store and Gateway directly.
>>
>> For API Manager 3.0.0, I suggest that we prevent the API being updated by
>> API Developers after the API has gone beyond the "CREATED" state. API
>> Publishers should still be allowed to make updates to the fields they are
>> eligible for (non technical information). If someone badly needs to update
>> technical information of a published API, they should first bring the API
>> to the "CREATED" state, which will make the API disappear temporarily and
>> bring it back to "PUBLISHED" once the changes are saved.
>>
>> Thanks,
>> NuwanD.
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>
>>
>>
>>
>> --
>> Rukshan Chathuranga.
>> Software Engineer.
>> WSO2, Inc.
>>
>> 

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

[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 was
> published previously. Some of the changes could break the clients who are
> already consuming this API.
>
> What if we enforce by design, that any update to an already published API
> should be a new version of the same API. This way the updated API will go
> through the same API lifecycle and we do not have the original problem
> raised here.
>

In this approach what will happend to the existing subscriptions for the
new API version? Let say we the change needs to go to all the subscribers
and when we create a new API version we have to create all subscriptions
that exists for the previous API. Correct me if I'm wrong.

>
> 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 seeing the API on the store
> until republished.
>
> I have thought about introducing a new LC state as well. But that only
> doesn't solve this issue. We need to build a mechanism to make a copy of
> the API and store the developer's changes elsewhere until a publisher
> approves the changes. Building that whole workflow is non trivial and
> leaves a lot more to think about as well. Besides, the above usecase is not
> standard practice since its not a good idea to make technical changes to
> published APIs. But the reality is that the real world needs it and hence
> we need to support it.
>
> Thanks,
> NuwanD.
>
> On Thu, Mar 30, 2017 at 11:52 PM, Pubudu Gunatilaka 
> wrote:
>
> 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 API is the best solution if it is
> already serving requests.
>
> What if we introduce another life cycle state and transfer the API to that
> state until API publisher re-publishes the API. In this way, there is no
> effect to the existing API.
>
> Thank you!
>
> On Thu, Mar 30, 2017 at 11:41 PM, Rukshan Premathunga 
> wrote:
>
> 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 publish it again
> with the changes. Because in if we demote to create state, we cannot have
> subscription information right?
>
> Thanks and Regards
>
> On Thu, Mar 30, 2017 at 11:15 PM, Nuwan Dias  wrote:
>
> 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
> and Gateway. This kind of beats the purpose of preventing API Developers
> from publishing APIs to the Store and Gateway directly.
>
> For API Manager 3.0.0, I suggest that we prevent the API being updated by
> API Developers after the API has gone beyond the "CREATED" state. API
> Publishers should still be allowed to make updates to the fields they are
> eligible for (non technical information). If someone badly needs to update
> technical information of a published API, they should first bring the API
> to the "CREATED" state, which will make the API disappear temporarily and
> bring it back to "PUBLISHED" once the changes are saved.
>
> Thanks,
> NuwanD.
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>
>
>
>
> --
> Rukshan Chathuranga.
> Software Engineer.
> WSO2, Inc.
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
>
>
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
>
>
> --
> Thanks & Regards,
>
> Fazlan Nazeem
>
> *Software Engineer*
>
> *WSO2 Inc*
> 

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

[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 consuming this API.

What if we enforce by design, that any update to an already published API
should be a new version of the same API. This way the updated API will go
through the same API lifecycle and we do not have the original problem
raised here.

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 seeing the API on the store
> until republished.
>
> I have thought about introducing a new LC state as well. But that only
> doesn't solve this issue. We need to build a mechanism to make a copy of
> the API and store the developer's changes elsewhere until a publisher
> approves the changes. Building that whole workflow is non trivial and
> leaves a lot more to think about as well. Besides, the above usecase is not
> standard practice since its not a good idea to make technical changes to
> published APIs. But the reality is that the real world needs it and hence
> we need to support it.
>
> Thanks,
> NuwanD.
>
> On Thu, Mar 30, 2017 at 11:52 PM, Pubudu Gunatilaka 
> wrote:
>
>> 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 API is the best solution if it is
>> already serving requests.
>>
>> What if we introduce another life cycle state and transfer the API to
>> that state until API publisher re-publishes the API. In this way, there is
>> no effect to the existing API.
>>
>> Thank you!
>>
>> On Thu, Mar 30, 2017 at 11:41 PM, Rukshan Premathunga 
>> wrote:
>>
>>> 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 publish it again
>>> with the changes. Because in if we demote to create state, we cannot have
>>> subscription information right?
>>>
>>> Thanks and Regards
>>>
>>> On Thu, Mar 30, 2017 at 11:15 PM, Nuwan Dias  wrote:
>>>
 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 and Gateway. This kind of beats the purpose of preventing API
 Developers from publishing APIs to the Store and Gateway directly.

 For API Manager 3.0.0, I suggest that we prevent the API being updated
 by API Developers after the API has gone beyond the "CREATED" state. API
 Publishers should still be allowed to make updates to the fields they are
 eligible for (non technical information). If someone badly needs to update
 technical information of a published API, they should first bring the API
 to the "CREATED" state, which will make the API disappear temporarily and
 bring it back to "PUBLISHED" once the changes are saved.

 Thanks,
 NuwanD.

 --
 Nuwan Dias

 Software Architect - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729 <+94%2077%20777%205729>

>>>
>>>
>>>
>>> --
>>> Rukshan Chathuranga.
>>> Software Engineer.
>>> WSO2, Inc.
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Pubudu Gunatilaka*
>> Committer and PMC Member - Apache Stratos
>> Software Engineer
>> WSO2, Inc.: http://wso2.com
>> mobile : +94774078049 <%2B94772207163>
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Thanks & Regards,

Fazlan Nazeem

*Software Engineer*

*WSO2 Inc*
Mobile : +94772338839
<%2B94%20%280%29%20773%20451194>
fazl...@wso2.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[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 state as well. But that only
doesn't solve this issue. We need to build a mechanism to make a copy of
the API and store the developer's changes elsewhere until a publisher
approves the changes. Building that whole workflow is non trivial and
leaves a lot more to think about as well. Besides, the above usecase is not
standard practice since its not a good idea to make technical changes to
published APIs. But the reality is that the real world needs it and hence
we need to support it.

Thanks,
NuwanD.

On Thu, Mar 30, 2017 at 11:52 PM, Pubudu Gunatilaka 
wrote:

> 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 API is the best solution if it is
> already serving requests.
>
> What if we introduce another life cycle state and transfer the API to that
> state until API publisher re-publishes the API. In this way, there is no
> effect to the existing API.
>
> Thank you!
>
> On Thu, Mar 30, 2017 at 11:41 PM, Rukshan Premathunga 
> wrote:
>
>> 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 publish it again
>> with the changes. Because in if we demote to create state, we cannot have
>> subscription information right?
>>
>> Thanks and Regards
>>
>> On Thu, Mar 30, 2017 at 11:15 PM, Nuwan Dias  wrote:
>>
>>> 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
>>> and Gateway. This kind of beats the purpose of preventing API Developers
>>> from publishing APIs to the Store and Gateway directly.
>>>
>>> For API Manager 3.0.0, I suggest that we prevent the API being updated
>>> by API Developers after the API has gone beyond the "CREATED" state. API
>>> Publishers should still be allowed to make updates to the fields they are
>>> eligible for (non technical information). If someone badly needs to update
>>> technical information of a published API, they should first bring the API
>>> to the "CREATED" state, which will make the API disappear temporarily and
>>> bring it back to "PUBLISHED" once the changes are saved.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Software Architect - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>
>>
>>
>>
>> --
>> Rukshan Chathuranga.
>> Software Engineer.
>> WSO2, Inc.
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>


-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[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 API is the best solution if it is
already serving requests.

What if we introduce another life cycle state and transfer the API to that
state until API publisher re-publishes the API. In this way, there is no
effect to the existing API.

Thank you!

On Thu, Mar 30, 2017 at 11:41 PM, Rukshan Premathunga 
wrote:

> 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 publish it again
> with the changes. Because in if we demote to create state, we cannot have
> subscription information right?
>
> Thanks and Regards
>
> On Thu, Mar 30, 2017 at 11:15 PM, Nuwan Dias  wrote:
>
>> 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
>> and Gateway. This kind of beats the purpose of preventing API Developers
>> from publishing APIs to the Store and Gateway directly.
>>
>> For API Manager 3.0.0, I suggest that we prevent the API being updated by
>> API Developers after the API has gone beyond the "CREATED" state. API
>> Publishers should still be allowed to make updates to the fields they are
>> eligible for (non technical information). If someone badly needs to update
>> technical information of a published API, they should first bring the API
>> to the "CREATED" state, which will make the API disappear temporarily and
>> bring it back to "PUBLISHED" once the changes are saved.
>>
>> Thanks,
>> NuwanD.
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>
>
>
>
> --
> Rukshan Chathuranga.
> Software Engineer.
> WSO2, Inc.
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Pubudu Gunatilaka*
Committer and PMC Member - Apache Stratos
Software Engineer
WSO2, Inc.: http://wso2.com
mobile : +94774078049 <%2B94772207163>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[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 PM, Rukshan Premathunga 
wrote:

> 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 publish it again
> with the changes. Because in if we demote to create state, we cannot have
> subscription information right?
>
> Thanks and Regards
>
> On Thu, Mar 30, 2017 at 11:15 PM, Nuwan Dias  wrote:
>
>> 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
>> and Gateway. This kind of beats the purpose of preventing API Developers
>> from publishing APIs to the Store and Gateway directly.
>>
>> For API Manager 3.0.0, I suggest that we prevent the API being updated by
>> API Developers after the API has gone beyond the "CREATED" state. API
>> Publishers should still be allowed to make updates to the fields they are
>> eligible for (non technical information). If someone badly needs to update
>> technical information of a published API, they should first bring the API
>> to the "CREATED" state, which will make the API disappear temporarily and
>> bring it back to "PUBLISHED" once the changes are saved.
>>
>> Thanks,
>> NuwanD.
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>
>
>
>
> --
> Rukshan Chathuranga.
> Software Engineer.
> WSO2, Inc.
>



-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[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 publish it again
with the changes. Because in if we demote to create state, we cannot have
subscription information right?

Thanks and Regards

On Thu, Mar 30, 2017 at 11:15 PM, Nuwan Dias  wrote:

> 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
> and Gateway. This kind of beats the purpose of preventing API Developers
> from publishing APIs to the Store and Gateway directly.
>
> For API Manager 3.0.0, I suggest that we prevent the API being updated by
> API Developers after the API has gone beyond the "CREATED" state. API
> Publishers should still be allowed to make updates to the fields they are
> eligible for (non technical information). If someone badly needs to update
> technical information of a published API, they should first bring the API
> to the "CREATED" state, which will make the API disappear temporarily and
> bring it back to "PUBLISHED" once the changes are saved.
>
> Thanks,
> NuwanD.
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>



-- 
Rukshan Chathuranga.
Software Engineer.
WSO2, Inc.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[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
and Gateway. This kind of beats the purpose of preventing API Developers
from publishing APIs to the Store and Gateway directly.

For API Manager 3.0.0, I suggest that we prevent the API being updated by
API Developers after the API has gone beyond the "CREATED" state. API
Publishers should still be allowed to make updates to the fields they are
eligible for (non technical information). If someone badly needs to update
technical information of a published API, they should first bring the API
to the "CREATED" state, which will make the API disappear temporarily and
bring it back to "PUBLISHED" once the changes are saved.

Thanks,
NuwanD.

-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[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
/ServiceProviderConfigs and /Schemas endpoints. As WSO2 SCIM 1.1 support [3] is
not covering the mentioned two endpoints, tests are failing when run.

However in order to get an idea on how the result representation had been
done in SCIM 1.1 compliance test suit, I mocked the /ServiceProviderConfigs
endpoint [4] and was able to get the following output.


​

Due to the complexity of mocking the /Schemas endpoint and also as the test
on one endpoint ( /ServiceProviderConfigs) could give the nature of the
result representation as seen above, I did not try to mock /Schemas
endpoint and run the test suit again. However I tried by mocking the
endpoint with 501 NOT IMPLEMENTED [5] as the output, but that was not
accepted by the test suit as a valid return object.

However, in my opinion, the SCIM test suit should be flexible in nature to
skip any test which was given the input from the SCIM server as 501 NOT
IMPLEMENTED [5]. I encourage such kind of implementation to be adopted in
the proposed SCIM 2.0 compliance test suit as in that way the test suit
acknowledges the SP's inability to provide those endpoints while making
sure such kind of inability does not compromise the ability to run the test
suit on other endpoints.

[1] - http://www.simplecloud.info/#complianceTest
[2] - https://aws.amazon.com/
[3] - https://github.com/wso2/charon/tree/release-2.0.7
[4] -
https://github.com/Vindulamj/mocked-identity-inbound-provisioning-scim/tree/master/identity-inbound-provisioning-scim-master
[5] - http://www.simplecloud.info/specs/draft-scim-api-01.html#anchor6

*Vindula Jayawardana*
Computer Science and Engineering Dept.
University of Moratuwa
mobile : +713462554
Email : vindul...@gmail.com






*“Respect is how to treat everyone, not just those you want to impress. "*


*-Richard Branson-*



On 10 March 2017 at 16:42, Vindula Jayawardana 
wrote:

> Hi,
>
> Thank you very much for the prompt replies. I will look into the points
> you have mentioned and will keep you updated here.
>
> Thank you.
>
> *Vindula Jayawardana*
> Computer Science and Engineering Dept.
> University of Moratuwa
> mobile : +713462554
> Email : vindul...@gmail.com
>
> 
> 
> 
> 
>
> *“Respect is how to treat everyone, not just those you want to impress. "*
>
>
> *-Richard Branson-*
>
>
>
> On 9 March 2017 at 21:22, Omindu Rathnaweera  wrote:
>
>> Hi Vindula,
>>
>> If we can run the existing 1.1 test on IS and see the generated output,
>> that will be a good point to start. However we'll need to host an IS
>> instance publicly to run the tests on it.
>>
>> Regards,
>> Omindu.
>>
>>
>>
>> On Thu, Mar 9, 2017 at 8:52 PM, Gayan Gunawardana  wrote:
>>
>>> Hi Vindula,
>>>
>>> Thanks for your interest in this project.
>>> Since you have good knowledge about SCIM 2.0 specifications, could you
>>> please look at SCIM 1.1 compliance test and source code [1]. SCIM 2.0
>>> compliance test doesn't need to be same as SCIM 1.1 just get an idea from
>>> SCIM 1.1 compliance test. Further you can extract test scenarios from [2]
>>> as well.
>>>
>>> [1]https://github.com/erdtman/simplecloud.info
>>> 
>>> [2]https://github.com/wso2-extensions/identity-inbound-provi
>>> sioning-scim2/tree/master/tests
>>>
>>> Thanks,
>>> Gayan
>>>
>>> On Thu, Mar 9, 2017 at 7:51 PM, Vindula Jayawardana <
>>> vindula...@cse.mrt.ac.lk> wrote:
>>>
 Hi,

 I am Vindula Jayawardana, a final year undergraduate of Computer
 Science and Engineering Department of University of Moratuwa. I am
 interested in applying for the "Proposal 21: [IS] SCIM 2.0 compliance
 test suite" which you have offered for the GSoC project idea pool.

 I have a good understanding on SCIM core and protocol specifications
 for both SCIM 1.1 and SCIM 2.0. Based on my knowledge I have written few
 blog posts specifically catering on SCIM [1] and the use cases of SCIM [2].
 Also I have tried SCIM 1.1 and 2.0 APIs of wso2 IS. I went though the
 references provided and would like to know more on the scope of the
 coverage report and detailed analysis view need to be generated as a
 deliverable. Could you kindly guide me on 

[Dev] Display only Production Services in Governance Registry Store

[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 readily available to 
the general public until it reaches the Production state.

Is there a configuration file or files that would allow this functionality to 
happen?

Thanks,
Ed Denson | IT Information & Integration | API Management
Pacific Gas and Electric Company | Office 8.415.6485 or 925.415.6485 | Cell 
408.316.5315
Email ed.den...@pge.com

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

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

[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 feedback on this.
>
>
> Thanks & Regards,
> Gobinath
>
> On Wed, Mar 15, 2017 at 1:30 PM, Sriskandarajah Suhothayan 
> wrote:
>
>> Thanks for the GSoC idea, I hope this will be a good way to improve the
>> Siddhi language and make it more powerfull.
>> If time permits we can also add other use-cases of patterns & sequences
>> and improve it further.
>>
>> Since you are still not a commuter I hope these contributions will help
>> you be a committer to Siddhi as well :)
>> I'll make this as a formal idea, do work on a proposal as well.
>>
>> Regards
>> Suho
>>
>>
>> On Wed, Mar 15, 2017 at 6:09 PM, Gobinath  wrote:
>>
>>> Hi team,
>>>
>>> This is Gobinath a former software engineer at WSO2 currently doing
>>> masters at Western University. This time I plan to do GSoC with WSO2 and
>>> this is the basic idea of what I have discussed with Suho.
>>> Based on Suho's suggestion, I come up with a proposal to implement
>>> detecting non-occurring events using Siddhi patterns. The current Siddhi
>>> patterns allow identifying the patterns that present.
>>>
>>> See an example:
>>> from every e1=Stream1[price>20] -> e2=Stream2[price>e1.price] within 1
>>> sec
>>> select e1.symbol as symbol1, e2.symbol as symbol2
>>> insert into OutputStream;
>>>
>>> Detecting the absence of a pattern is not natively supported by Siddhi
>>> patterns for the moment. In other words, identifying event_a not followed
>>> by event_b within 2 minutes is not possible using the current patterns
>>> implementation (Note that a time frame is required otherwise we have to
>>> wait for infinite time to say event_b has not arrived). The current
>>> workaround [1] to detect non-delivered items is shown below:
>>>
>>> from arrivals_stream#window.time(2 minutes)
>>> select *
>>> insert expired events into overdue_deliveries_stream;
>>>
>>> from every arrivalEvent = arrivals_stream ->
>>> deliveryEvent = deliveries_stream[arrivalEvent.trackingId == trackingId]
>>> or overdue_delivery = overdue_deliveries_stream[arrivalEvent.trackingId
>>> == trackingId]
>>> select arrivalEvent.trackingId as trackingId, arrivalEvent.customerName
>>> as customerName, arrivalEvent.telephoneNo as telephoneNo,
>>> deliveryEvent.trackingId as deliveryId
>>> insert into filter_stream;
>>>
>>> from filter_stream [ (deliveryId is null)]
>>> select trackingId, customerName, telephoneNo
>>> insert into alert_stream;
>>>
>>> This solution requires a time window and it is inefficient if we are
>>> interested only on one occurrence of such a pattern (In other words same
>>> query without every keyword). Further, the query is more complex and not
>>> user-friendly.
>>>
>>> If we provide patterns to detect absence of patterns, the above query
>>> can be rewritten as below:
>>>
>>> from every arrivalEvent = arrivals_stream ->  (not
>>> deliveries_stream[arrivalEvent.trackingId == trackingId] within 2 min )
>>> select arrivalEvent.trackingId as trackingId, arrivalEvent.customerName
>>> as customerName, arrivalEvent.telephoneNo as telephoneNo
>>> insert into alert_stream;
>>>
>>> As you can see, we can use the existing language components like not &
>>> within. This can be achieved by extending the existing
>>> StreamPreStateProcessors and StreamPostStateProcessors with an internal
>>> timer so that they can expire their internal list of events based on the
>>> time limit. It is somewhat similar to time windows but the processor can
>>> turn off the timer and ignore the events if it is a one time pattern
>>> detection.
>>>
>>> I hope it gives the basic idea and I am waiting for your suggestions and
>>> feedback.
>>>
>>> [1] https://docs.wso2.com/display/CEP400/Sample+0111+-+Detec
>>> ting+non-occurrences+with+Patterns
>>>
>>>
>>> Thanks & Regards,
>>> Gobinath
>>> --
>>> *Gobinath** Loganathan*
>>> Graduate Student,
>>> Electrical and Computer Engineering,
>>> Western University.
>>> Email  : slgobin...@gmail.com
>>> Mobile : (+1) 416-895-0721
>>> Blog: javahelps.com 
>>>
>>>
>>
>>
>>
>> --
>>
>> *S. Suhothayan*
>> Associate Director / Architect & Team Lead of WSO2 Complex Event
>> Processor
>> *WSO2 Inc. *http://wso2.com
>> * *
>> lean . enterprise . middleware
>>
>>
>> *cell: (+94) 779 756 757 <077%20975%206757> | blog:
>> http://suhothayan.blogspot.com/ twitter:
>> http://twitter.com/suhothayan  | linked-in:
>> http://lk.linkedin.com/in/suhothayan *
>>
>
>
>
> --
> *Gobinath** Loganathan*
> Graduate Student,
> Electrical and Computer Engineering,
> Western University.
> Email  : slgobin...@gmail.com
> 

Re: [Dev] about GSOC

[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 asked you questions related to GSOC 2017.
> You said, "Since you are also familiar in this space, we can also bring
> your suggestions as projects if you have any."
> I've been running the WSO2 tutorial and looking at the code for siddhi.
> I have seen Siddhi's paser acting as Antlr, and I would like to talk to
> Manto about my ideas on this part.
> I also know that you are in charge of the siddhi language. I am interested
> in the optimize side, and do you have a document that allows you to use
> siddhi smartly?
>
> My previous email address was tmxhsf...@naver.com.
>
>
>


-- 

*S. Suhothayan*
Associate Director / Architect
*WSO2 Inc. *http://wso2.com
* *
lean . enterprise . middleware


*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
twitter: http://twitter.com/suhothayan
 | linked-in:
http://lk.linkedin.com/in/suhothayan *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[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 
wrote:

> Hi All,
>
> As per the offline discussion with Azeez, it was suggested that the
> deployment folder should be per runtime.
>
> Regards,
> Nira
>
> On Mon, Mar 6, 2017 at 10:47 AM, Imesh Gunaratne  wrote:
>
>> Thanks for the quick response Niranjan!
>>
>> On Mon, Mar 6, 2017 at 9:40 AM, Niranjan Karunanandham > > wrote:
>>
>>
>>> Would we have deployment artifacts which can are required by all the
>>> runtime? In which case should the artifact be in each runtime as in [1] or
>>> will we be having it [2] which deploys for all  runtime?
>>>
>>
>> ​+1 Yes, it would be better to place common deployable artifacts at the
>> root level to avoid duplication. Otherwise, users would need to update the
>> same set of files at multiple locations when working with this distribution.
>>
>>>
>>> In , we have bin (which should contain the script to start
>>> all runtime), dbscript, resources which contain the keystores (JKS) and
>>> logs (IMO the logs should be per runtime).
>>>
>>
>> ​It make sense! Anything common to multiple runtimes can reside at the
>> root level.​
>>
>> As we discussed offline, I think it might be better to ship separate
>> distributions for runtimes together with the all-in-one distribution.
>> Otherwise users would need to create separate distributions for runtimes
>> when those need to be deployed separately. This would be necessary when
>> creating container images, container cluster manager artifacts (Docker
>> Swarm, K8S, DC/OS, etc), configuration management modules (Chef, Puppet,
>> etc), etc as those would map one to one to each process.
>>
>> Thanks
>> Imesh
>>
>>>
>>>
>>>

 Thanks


> Regards,
> Nira
>
> --
>
>
> *Niranjan Karunanandham*
> Associate Technical Lead - WSO2 Inc.
> WSO2 Inc.: http://www.wso2.com
>
>


 --
 *Imesh Gunaratne*
 Software Architect
 WSO2 Inc: http://wso2.com
 T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
 W: https://medium.com/@imesh TW: @imesh
 lean. enterprise. middleware


>>> Regards,
>>> Nira
>>>
>>> --
>>>
>>>
>>> *Niranjan Karunanandham*
>>> Associate Technical Lead - WSO2 Inc.
>>> WSO2 Inc.: http://www.wso2.com
>>>
>>>
>>
>>
>> --
>> *Imesh Gunaratne*
>> Software Architect
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
>> W: https://medium.com/@imesh TW: @imesh
>> lean. enterprise. middleware
>>
>>
>
>
> --
>
>
> *Niranjan Karunanandham*
> Associate Technical Lead - WSO2 Inc.
> WSO2 Inc.: http://www.wso2.com
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Thusitha Dayaratne
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

Mobile  +94712756809
Blog  alokayasoya.blogspot.com
Abouthttp://about.me/thusithathilina

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

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

[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 AM, Yasassri Ratnayake 
wrote:

> Hi Thilina,
>
> On Sun, Mar 26, 2017 at 4:07 AM, Thilina Manamgoda 
> wrote:
>
>> Hi Yasassri,
>>
>> Please find my comments inline.
>>
>> On Wed, Mar 22, 2017 at 8:12 PM, Yasassri Ratnayake 
>> wrote:
>>
>>> Hi Thilina,
>>>
>>> We have missed some requirements. Please consider the following as well.
>>>
>>> 1. We need a Tomcat instance to host the Backends(Weapps) which are
>>> required by the Test Scripts. So we need another instance spawned with
>>> Tomcat. After spawning the instance you can deploy the prerequisite web
>>> apps. (These web apps will be available in the Test-Repo under resources)
>>>
>>
>>  Yes of course we can archieve this as well.
>>
>> 2. Also when deploying Jmeter we need to copy 3rd party Jars to Jmeter.
>>> (These are also available in the repository)
>>>
>>
>>
>>> This can be done by copying these files to docker image in Jmeter docker
>>> image building stage.
>>>
>>
>>
>>> Also answering your question about the Deployment profiles. We have
>>> identified several components to make the scope manageable.
>>>
>>> *Products*
>>> ESB | V4.9 & V5.0
>>> APIM | V1.9 & V2.0
>>>
>>> *JDK*
>>> JAVA | V1.7 & V1.8
>>>
>>> *DataBase*
>>> MySQL
>>>
>>> *Third Party Servers*
>>> Brokers | ActiveMQ 5.10 | WSO2 MB 3.1 (Only applicable when ESB is used)
>>>
>>> So a Sample Profile would be, *ESB 4.9 + JAVA 1.7 + MYSQL + ActiveMQ*.
>>> For now, you can concentrate on the above components when determining a
>>> deployment profile. But your solution should be scalable.
>>>
>>> Is this a profile described here:https://docs.wso2.com/dis
>> play/KA100/Clustered+Deployment+of+WSO2+Products+on+Kubernetes . If it
>> is, then do I need to configure the product with third party servers or
>> it's already done and I only have to deploy selected profile's servers into
>> kubernetes cluster. For example let's take the above profile, in order to
>> run this delpoyment ESB should be configured with MYSQL and Active MQ API
>> endpoints. Do i need to change the configuration files of ESB or it's
>> already taken care of and deployment is done once i deploy Kubernetes
>> artifacts under the selected profile.
>>
>
> Existing scripts doesn't allow us to configure thirdparty dependencies
> like Message Brokers. So yes we need to change ESB configurations depending
> on the Broker, you can refer [1
> ] for
> ActiveMQ configurations.
>
>
>>
>> Is this a profile of ESB : https://github.com/wso2/kube
>> rnetes-artifacts/tree/master/wso2esb ?
>>
>
> Yes this script supports two profiles, default ESB profile and worker
> manager profile, but as mentioned we neeed to tweek these scripts to
> support mesage brokers as well.
>
>
>> Also can't we have a private docker registry to hold our deplyment's
>> images instead of building docker images via the web app ?.
>>
>>>
>>>
> We can use a private registry to store the docker images but you need to
> comeup with some scripts to Auomate the process in that case.
>
>
> [1] - https://docs.wso2.com/display/ESB490/Configure+with+ActiveMQ
> --
> Yasassri Ratnayake
> Senior Software Engineer - QA
> WSO2 Inc ; http://wso2.com
> lean.enterprise.middleware
> *Mobile : +94715933168 <+94%2071%20593%203168>*
> *Blogs : http://yasassriratnayake.blogspot.com
> *
> *http://wso2logs.blogspot.com *
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Build failure in Product-EI

[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 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.
>
> [1]. https://github.com/wso2/carbon-mediation
>
> Thanks,
>
> On Thu, Mar 30, 2017 at 3:35 PM, Sinthuja Ragendran 
> wrote:
>
>> 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-profil
>> e/ei-profile/pom.xml#L113
>> [2] https://github.com/wso2/product-ei/blob/master/pom.xml#L1241
>>
>> Thanks,
>> Sinthuja.
>>
>> On Thu, Mar 30, 2017 at 3:27 PM, Madhawa Gunasekara 
>> wrote:
>>
>>> 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 
>>> wrote:
>>>
 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, phase=org.eclipse.equinox.inte
 rnal.p2.engine.phases.Configure, operand=null -->
 [R]org.wso2.carbon.das.messageflow.data.publisher.feature.group
 4.6.19.SNAPSHOT, action=org.eclipse.equinox.int
 ernal.p2.touchpoint.natives.actions.MkdirAction).
  Could not create directory /Users/sinthu/wso2/sources/dev
 /git/product-ei/p2-profile/ei-profile/target/wso2carbon-core
 -4.4.15/wso2/components/default/../../deployment/server/even
 tpublishers/.
 Application failed, log file location: /private/tmp/.m2/org/eclipse/t
 ycho/tycho-p2-runtime/0.13.0/eclipse/configuration/1490865270860.log

 Can anyone from EI team check this?

 Thanks,
 Sinthuja.

 --
 *Sinthuja Rajendran*
 Technical Lead
 WSO2, Inc.:http://wso2.com

 Blog: http://sinthu-rajan.blogspot.com/
 Mobile: +94774273955 <+94%2077%20427%203955>



>>>
>>>
>>> --
>>> *Madhawa Gunasekara*
>>> Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: +94 719411002 <+94+719411002>
>>> blog: *http://madhawa-gunasekara.blogspot.com
>>> *
>>> linkedin: *http://lk.linkedin.com/in/mgunasekara
>>> *
>>>
>>
>>
>>
>> --
>> *Sinthuja Rajendran*
>> Technical Lead
>> WSO2, Inc.:http://wso2.com
>>
>> Blog: http://sinthu-rajan.blogspot.com/
>> Mobile: +94774273955 <+94%2077%20427%203955>
>>
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Eranda Rajapakshe*
> Software Engineer
> WSO2 Inc.
> Mobile : +94784822608
>



-- 
*Sinthuja Rajendran*
Technical Lead
WSO2, Inc.:http://wso2.com

Blog: http://sinthu-rajan.blogspot.com/
Mobile: +94774273955
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Build failure in Product-EI

[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.

[1]. https://github.com/wso2/carbon-mediation

Thanks,

On Thu, Mar 30, 2017 at 3:35 PM, Sinthuja Ragendran 
wrote:

> 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 Thu, Mar 30, 2017 at 3:27 PM, Madhawa Gunasekara 
> wrote:
>
>> 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 
>> wrote:
>>
>>> 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, phase=org.eclipse.equinox.inte
>>> rnal.p2.engine.phases.Configure, operand=null -->
>>> [R]org.wso2.carbon.das.messageflow.data.publisher.feature.group
>>> 4.6.19.SNAPSHOT, action=org.eclipse.equinox.int
>>> ernal.p2.touchpoint.natives.actions.MkdirAction).
>>>  Could not create directory /Users/sinthu/wso2/sources/dev
>>> /git/product-ei/p2-profile/ei-profile/target/wso2carbon-core
>>> -4.4.15/wso2/components/default/../../deployment/server/even
>>> tpublishers/.
>>> Application failed, log file location: /private/tmp/.m2/org/eclipse/t
>>> ycho/tycho-p2-runtime/0.13.0/eclipse/configuration/1490865270860.log
>>>
>>> Can anyone from EI team check this?
>>>
>>> Thanks,
>>> Sinthuja.
>>>
>>> --
>>> *Sinthuja Rajendran*
>>> Technical Lead
>>> WSO2, Inc.:http://wso2.com
>>>
>>> Blog: http://sinthu-rajan.blogspot.com/
>>> Mobile: +94774273955 <+94%2077%20427%203955>
>>>
>>>
>>>
>>
>>
>> --
>> *Madhawa Gunasekara*
>> Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 719411002 <+94+719411002>
>> blog: *http://madhawa-gunasekara.blogspot.com
>> *
>> linkedin: *http://lk.linkedin.com/in/mgunasekara
>> *
>>
>
>
>
> --
> *Sinthuja Rajendran*
> Technical Lead
> WSO2, Inc.:http://wso2.com
>
> Blog: http://sinthu-rajan.blogspot.com/
> Mobile: +94774273955 <+94%2077%20427%203955>
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Eranda Rajapakshe*
Software Engineer
WSO2 Inc.
Mobile : +94784822608
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Build failure in Product-EI

[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 Thu, Mar 30, 2017 at 3:27 PM, Madhawa Gunasekara 
wrote:

> 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 
> wrote:
>
>> 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, phase=org.eclipse.equinox.inte
>> rnal.p2.engine.phases.Configure, operand=null -->
>> [R]org.wso2.carbon.das.messageflow.data.publisher.feature.group
>> 4.6.19.SNAPSHOT, action=org.eclipse.equinox.int
>> ernal.p2.touchpoint.natives.actions.MkdirAction).
>>  Could not create directory /Users/sinthu/wso2/sources/dev
>> /git/product-ei/p2-profile/ei-profile/target/wso2carbon-core
>> -4.4.15/wso2/components/default/../../deployment/server/eventpublishers/.
>> Application failed, log file location: /private/tmp/.m2/org/eclipse/t
>> ycho/tycho-p2-runtime/0.13.0/eclipse/configuration/1490865270860.log
>>
>> Can anyone from EI team check this?
>>
>> Thanks,
>> Sinthuja.
>>
>> --
>> *Sinthuja Rajendran*
>> Technical Lead
>> WSO2, Inc.:http://wso2.com
>>
>> Blog: http://sinthu-rajan.blogspot.com/
>> Mobile: +94774273955 <+94%2077%20427%203955>
>>
>>
>>
>
>
> --
> *Madhawa Gunasekara*
> Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 719411002 <+94+719411002>
> blog: *http://madhawa-gunasekara.blogspot.com
> *
> linkedin: *http://lk.linkedin.com/in/mgunasekara
> *
>



-- 
*Sinthuja Rajendran*
Technical Lead
WSO2, Inc.:http://wso2.com

Blog: http://sinthu-rajan.blogspot.com/
Mobile: +94774273955
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Build failure in Product-EI

[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 
wrote:

> 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, phase=org.eclipse.equinox.inte
> rnal.p2.engine.phases.Configure, operand=null -->
> [R]org.wso2.carbon.das.messageflow.data.publisher.feature.group
> 4.6.19.SNAPSHOT, action=org.eclipse.equinox.int
> ernal.p2.touchpoint.natives.actions.MkdirAction).
>  Could not create directory /Users/sinthu/wso2/sources/dev
> /git/product-ei/p2-profile/ei-profile/target/wso2carbon-core
> -4.4.15/wso2/components/default/../../deployment/server/eventpublishers/.
> Application failed, log file location: /private/tmp/.m2/org/eclipse/t
> ycho/tycho-p2-runtime/0.13.0/eclipse/configuration/1490865270860.log
>
> Can anyone from EI team check this?
>
> Thanks,
> Sinthuja.
>
> --
> *Sinthuja Rajendran*
> Technical Lead
> WSO2, Inc.:http://wso2.com
>
> Blog: http://sinthu-rajan.blogspot.com/
> Mobile: +94774273955 <+94%2077%20427%203955>
>
>
>


-- 
*Madhawa Gunasekara*
Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 719411002 <+94+719411002>
blog: *http://madhawa-gunasekara.blogspot.com
*
linkedin: *http://lk.linkedin.com/in/mgunasekara
*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Build failure in Product-EI

[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,
phase=org.eclipse.equinox.internal.p2.engine.phases.Configure, operand=null
--> [R]org.wso2.carbon.das.messageflow.data.publisher.feature.group
4.6.19.SNAPSHOT,
action=org.eclipse.equinox.internal.p2.touchpoint.natives.actions.MkdirAction).
 Could not create directory
/Users/sinthu/wso2/sources/dev/git/product-ei/p2-profile/ei-profile/target/wso2carbon-core-4.4.15/wso2/components/default/../../deployment/server/eventpublishers/.
Application failed, log file location:
/private/tmp/.m2/org/eclipse/tycho/tycho-p2-runtime/0.13.0/eclipse/configuration/1490865270860.log

Can anyone from EI team check this?

Thanks,
Sinthuja.

-- 
*Sinthuja Rajendran*
Technical Lead
WSO2, Inc.:http://wso2.com

Blog: http://sinthu-rajan.blogspot.com/
Mobile: +94774273955
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[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 privileges [2].

   - *readOnly* does not allow to change values or to invoke operations but
   can monitor
   - *readWrite *gives the total control over the server which allows to
   change values and invoke operations

- Both password and access files are properties based text files for
specifying username/password pairs and username/access pairs respectively.

- The password and access files could reside anywhere in the server and
should be provided upon server startup.

- SSL is enabled by default for remote monitoring and thus the SSL should
be configured properly after setting up a digital certificate. System
properties for keystore and truststore should be set in the server.

[1] https://github.com/wso2/carbon-kernel/issues/1247
[2] http://docs.oracle.com/javase/7/docs/technotes/
guides/management/agent.html



Thanks.

Regards,
Asma
-- 
Asma Zinneera Jabir
Software Engineer
WSO2 Inc: http://wso2.com/
Contact No: +94 77 332 4752 <+94%2077%20332%204752>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[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.
>
> I have changed the proposal according to the our last discussion. Please
> check if the diagrams represent those details correctly.
>
> Thank you.
> --
> Best regards,
> *Nadheesh Jihan*
> Undergraduate | Department of Computer Science and Engineering
> Faculty of Engineering
> University of Moratuwa
>



-- 

*S. Suhothayan*
Associate Director / Architect
*WSO2 Inc. *http://wso2.com
* *
lean . enterprise . middleware


*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
twitter: http://twitter.com/suhothayan
 | linked-in:
http://lk.linkedin.com/in/suhothayan *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

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

[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 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-shouldnt-replace-your-for-loops-by-stream-foreach/
[2] -
https://jaxenter.com/java-performance-tutorial-how-fast-are-the-java-8-streams-118830.html

Thanks!
Rajith

-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-72-642-8350 <%2B94-71-554-8430>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev