Re: [Architecture] PPaaS Artifact Migration Tool

[Imesh Gunaratne]

Hi Malmee,

It would be better if you can draw a component architecture diagram to
illustrate how this tool works.

This might help us to understand how much load it can handle if the
existing Private PaaS 4.0.0 environment has considerable amount of
artifacts and subscriptions and how those can be processed efficiently.

Thanks

On Tue, Dec 15, 2015 at 10:39 PM, Malmee Weerasinghe 
wrote:

> Hi All,
> We are developing a tool to convert PPaaS 4.0.0 artifact JSON files to
> PPaaS 4.1.x. [1]
>
> There are changes in the artifacts deployment process in PPaaS 4.0.0
> compared to 4.1.0. So this tool is developed for those who need to migrate
> from PPaaS 4.0.0 to 4.1.0.
>
> We take the artifacts JSONs of PPaaS 4.0.0 through REST API endpoints,
> convert them using the bean classes of PPaaS 4.0.0 and 4.1.0 which are
> accessed via a dependency and generate output artifacts to to be compatible
> with PPaaS 4.1.x. In this process, we use default values for the additional
> artifacts.
>
> These are the conversions we have implemented already.
>  - auto scale policy artifacts
>  - network partition list artifacts
>  - deployment policy artifacts
>  - cartridge artifacts
>  - application artifacts
>  - application sign ups - convert the cartridge subscription artifacts
> JSONs output from Subscription Manager [2]
>  - domain mappings
>
> Would appreciate it if you could give your suggestions and comments on
> this.
> [1]
> https://github.com/nishadi/product-private-paas/tree/master/tools/migration/ppaas-artifact-converter
> 
> [2]
> https://github.com/wso2/product-private-paas/tree/master/tools/migration/subscription-manager/4.0.0
> 
>
> --
> Malmee Weerasinghe
> WSO2 Intern
> mobile : (+94)* 71 7601905* |   email :   
> mal...@wso2.com
>



-- 
*Imesh Gunaratne*
Senior Technical Lead
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: http://imesh.gunaratne.org
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] PPaaS Artifact Migration Tool

[Malmee Weerasinghe]

Hi All,
We are developing a tool to convert PPaaS 4.0.0 artifact JSON files to
PPaaS 4.1.x. [1]

There are changes in the artifacts deployment process in PPaaS 4.0.0
compared to 4.1.0. So this tool is developed for those who need to migrate
from PPaaS 4.0.0 to 4.1.0.

We take the artifacts JSONs of PPaaS 4.0.0 through REST API endpoints,
convert them using the bean classes of PPaaS 4.0.0 and 4.1.0 which are
accessed via a dependency and generate output artifacts to to be compatible
with PPaaS 4.1.x. In this process, we use default values for the additional
artifacts.

These are the conversions we have implemented already.
 - auto scale policy artifacts
 - network partition list artifacts
 - deployment policy artifacts
 - cartridge artifacts
 - application artifacts
 - application sign ups - convert the cartridge subscription artifacts
JSONs output from Subscription Manager [2]
 - domain mappings

Would appreciate it if you could give your suggestions and comments on this.
[1]
https://github.com/nishadi/product-private-paas/tree/master/tools/migration/ppaas-artifact-converter

[2]
https://github.com/wso2/product-private-paas/tree/master/tools/migration/subscription-manager/4.0.0


-- 
Malmee Weerasinghe
WSO2 Intern
mobile : (+94)* 71 7601905* |   email :   
mal...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Implementing a WSO2 PaaS with Kubernetes

[Imesh Gunaratne]

Great! Thanks Chamila!

I have now moved Kubernetes membership scheme from [1] to the same
repository [2]:
Next I will be moving the ESB Kubernetes artifacts [3], then will be
creating the Dockerfile to generate a pre-configured Docker image with
Puppet + Hiera.

[1] https://github.com/imesh/carbon-membership-schemes
[2]
https://github.com/wso2-incubator/kubernetes-artifacts/tree/master/common/kubernetes-membership-scheme
[3]
https://github.com/imesh/kubernetes-carbon-samples/tree/master/wso2esb/4.8.1

Thanks

On Mon, Dec 14, 2015 at 5:57 PM, Chamila De Alwis  wrote:

> Hi Imesh,
>
> On Wed, Dec 9, 2015 at 6:20 PM, Imesh Gunaratne  wrote:
>
>>
>>1. Deploy Kubernetes arfifacts (services, replication controllers,
>>etc) of the product. This would start the Carbon server cluster on
>>Kubernetes.
>>
>> I've started working on creating Kubernetes artifacts for the WSO2
> Products. I will update as the work progresses. The artifacts will be
> pushed to [1].
>
> [1] - https://github.com/wso2-incubator/kubernetes-artifacts
>
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Imesh Gunaratne*
Senior Technical Lead
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: http://imesh.gunaratne.org
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Carbon Feature Plugin 2.0.0 Released!

[Dinusha Boteju]

*WSO2 Carbon Feature plugin 2.0.0 Released!*

We are pleased to inform you that the carbon feature plugin 2.0.0 is now
available to use. Source for this release is available here.


Documentation for WSO2 carbon feature plugin 2.0.0 is now available in WSO2
wiki and can be found from here
.

*Reporting issues*

Please feel free to report bugs you come across, documentation faults and
feature requests through the public issue tracking system
.

Thanks,
WSO2 Carbon Team

-- 
*Dinusha Boteju*
*WSO2, Inc. http://wso2.com  *
*lean.enterprise.middleware.*

email: dinus...@wso2.com 
phone:(+94) 776640275 <%28%2B94%29%2039736>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Web Application Statistics Monitoring for Application Server 6.0.0

[Nuwan Pallewela]

[Moving to Architecture group]

On Tue, Dec 15, 2015 at 3:31 PM, Nuwan Pallewela  wrote:

> [Moving thread to Architecture group]
>
> Hi Nathasha,
>
> Is statistics information get update per minute?
> Do we have the capability to update the statistics using a refresh button
> or some other way without waiting for one minute?
>
> It will be great if you could provide a simple diagram which  describes
> the design.
>
> Thanks,
> Nuwan
>
>
> On Tue, Dec 15, 2015 at 11:29 AM, Nathasha Naranpanawa 
> wrote:
>
>> Hi all,
>>
>> I'm currently working on adding web application statistics monitoring
>> feature to the upcoming Application Server 6.0.0. This was done in two
>> iterations as following;
>>
>>- Adding a custom Valve to the tomcat server in order to collect data
>>from the server.
>>- Creating necessary CApp packages in order to define means of
>>publishing data from tomcat server to DAS, receiving and storing the data.
>>
>> The custom tomcat Valve behaves as an Event Publisher and publishes data
>> to DAS through Thrift data agent. For each request from the server, an
>> Event is created including metadata and payload data and is published to
>> the DAS by a DataPublisher.
>>
>> A CApp was created by including the definitions for an Event Stream,
>> Event Receiver and Event Store to receive data from the publisher valve and
>> store them. This is deployed in the
>> wso2das-3.0.0/repository/deployment/server/carbonapps folder.
>>
>> A Spark script is also added to the CApp in order to query the data
>> received by DAS. The script presents a summary of the requests received by
>> DAS per minute. The summary includes the following information;
>>
>>- average request count
>>- average response time
>>- HTTP request success count
>>- HTTP request error count
>>
>> Any suggestions and feedback are highly appreciated.
>>
>> Thanks,
>>
>>
>> --
>> Nathasha Naranpanawa
>> Software Engineering Intern
>> WSO2 Inc.
>>
>> Email: natha...@wso2.com
>> Mobile: +94775496142
>> LinkedIn: https://lk.linkedin.com/in/nathashanaranpanawa
>>
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> --
>
> *Nuwan Chamara Pallewela*
>
>
> *Software Engineer*
>
> *WSO2, Inc. *http://wso2.com
> *lean . enterprise . middleware*
>
> Email   *nuw...@wso2.com *
> Mobile  *+94719079739 <%2B94719079739>@*
>
>
>


-- 
--

*Nuwan Chamara Pallewela*


*Software Engineer*

*WSO2, Inc. *http://wso2.com
*lean . enterprise . middleware*

Email   *nuw...@wso2.com *
Mobile  *+94719079739 <%2B94719079739>@*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] App Factory Tier Implementation

[Manjula Rathnayake]

Hi Dakshika,

On Mon, Dec 14, 2015 at 11:52 AM, Dakshika Jayathilaka 
wrote:

> Hi,
>
> I have few questions on above user stories,
>
> 1. How* "setup Eng"* define base currency for this? (USD, LKR)
>
 Billing should be handled by a different application and we need to remove
cost per hour field from above tables.

> 2. Do we have any plan on specifying regions?
>
+1.

> 3. Are we planning to provide any REST APIs for this? (AFAIK we are not
> planning to have any payment modules in AF side. so probably we need to
> have API for integrate with another app (ex: cloud Mgt App)  )
>
Yes, REST API will be provided for billing and subscription plan
applications.

+1 for adding description, display name fields too.

thank you.

>
> Thank you,.
>
> Regards,
>
> *Dakshika Jayathilaka*
> PMC Member & Committer of Apache Stratos
> Senior Software Engineer
> WSO2, Inc.
> lean.enterprise.middleware
> 0771100911
>
> On Mon, Dec 14, 2015 at 9:37 AM, Nadeeshani Pathirennehelage <
> nadeesha...@wso2.com> wrote:
>
>> Hi All,
>> We are hoping to implement the tier implementation for the AppFactory.
>> Tier is the subscription plan which is selected by the organization admin
>> for the organization.
>>
>>1.
>>
>>AF Set Up Engineer should be able to define Tiers (free/paid v1/ paid
>>v2).
>>2.
>>
>>AF Set Up Engineer should be able to define Container Specs.
>>(t2.small/ t2.medium/ m2.small )
>>3. System should display each Subscription Plans ( Free / Paid v1 /
>>paid v2) to the Organization Admin(Tenant) to choose a suitable plan for
>>the organization.
>>4.
>>
>>Organization Admin(Tenant) should be able to upgrade the subscription
>>plan for the organization.
>>5. System should display the each Container Specs Type(
>>Small/medium/large) with its features such as CPU, memory, storage to all
>>tenants.
>>6.
>>
>>Organization Admin(Tenant) should be able to choose new Container
>>Specs ( small , large , medium ) to the existing subscription plan.
>>Organization members should use those Container Spec.
>>7.
>>
>>Organization Admin(Tenant) should be able to remove Container Specs (
>>small , large , medium ) from the existing subscription plan.
>>8. System should be able to view the details such as Plan Type, list
>>of Container Specs which is running and information of each Container 
>> Spec,
>>of a given Organization.
>>
>>
>> Table structure is given below.
>>
>>
>> ​
>>
>> *These tables are filled with just reference values.*
>> The above plan table can be expanded with more columns.
>>
>> ​The above table structure will be useful for the administration to
>> develop applications for configuring the tiers. Moreover it will be useful
>> to render the subscription plan to the end users through UI.
>>
>> Would appreciate it if you could give your suggestions and comments on
>> this.
>> Thanks,
>> Nadeeshani
>>
>> --
>> Pathirennehelage Nadeeshani
>> Software Engineering Intern : WSO2 Inc
>> Mobile : +94 (0) 716 545223
>> nadeesha...@wso2.com
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>


-- 
Manjula Rathnayaka
Associate Technical Lead
WSO2, Inc.
Mobile:+94 77 743 1987
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] App Factory Tier Implementation

[Kasun De Silva]

Hi Imesh,

See my comments inline,

>
>- I can see the term "gear" is used in the tables but it's not
>described. Is this an unit of resources (CPU, memory, disk, etc)? If so how
>do we plan to control that for a cluster of containers?
>
> Yes "Gear" is an unit of resources, but  AFAIU we should not use this word
since openshift already use it.
@Nadeeshani please use "Container Spec" instead for now until we figure out
something better.

>
>- What would be the entity that a tenant admin would subscribe to? Is
>this a container cluster or a composite container deployment (which would
>have a multiple clusters) or a set of app types?
>
> Tenant would subscribe to a Plan that is the main entity. Plan consist of
a container cluster. He can use this container cluster to do his
deployments.

>
>- Are we planning to expose an API for billing integration?
>
> Yes, REST API will be provided for billing and subscription plan
applications since we are planning to have payment modules and subscription
modules separate from AF.  (Could be existing Cloudmgt app)

>
>- Do we have a plan to integrate with an existing billing solution to
>demonstrate billing capabilities?
>
> +1 for this, @AF team WDYT?

Thanks,
Kasun

-- 
*Kasun de Silva*
Software Engineer | *WSO2 Inc.*; http://wso2.com
lean.enterprise.middleware

email   : kas...@wso2.com
mobile : +94 77 794 4260
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Web Application Statistics Monitoring for Application Server 6.0.0

[Imesh Gunaratne]

> On Tue, Dec 15, 2015 at 11:29 AM, Nathasha Naranpanawa 
>> wrote:
>>
>>>
>>>- Adding a custom Valve to the tomcat server in order to collect
>>>data from the server.
>>>
>>> Can you please explain more details about this valve?

   - What would be the approach taken to publish data in asynchronous mode?
   - How do we plan to share data between the thread that accept the
   request and the thread that publish statistics?
   - How would that scale/affect if the incoming requests grow?
   - How would this valve would handle if DAS is not reachable?

Thanks

>
>>>- Creating necessary CApp packages in order to define means of
>>>publishing data from tomcat server to DAS, receiving and storing the 
>>> data.
>>>
>>> The custom tomcat Valve behaves as an Event Publisher and publishes data
>>> to DAS through Thrift data agent. For each request from the server, an
>>> Event is created including metadata and payload data and is published to
>>> the DAS by a DataPublisher.
>>>
>>> A CApp was created by including the definitions for an Event Stream,
>>> Event Receiver and Event Store to receive data from the publisher valve and
>>> store them. This is deployed in the
>>> wso2das-3.0.0/repository/deployment/server/carbonapps folder.
>>>
>>> A Spark script is also added to the CApp in order to query the data
>>> received by DAS. The script presents a summary of the requests received by
>>> DAS per minute. The summary includes the following information;
>>>
>>>- average request count
>>>- average response time
>>>- HTTP request success count
>>>- HTTP request error count
>>>
>>> Any suggestions and feedback are highly appreciated.
>>>
>>> Thanks,
>>>
>>>
>>> --
>>> Nathasha Naranpanawa
>>> Software Engineering Intern
>>> WSO2 Inc.
>>>
>>> Email: natha...@wso2.com
>>> Mobile: +94775496142
>>> LinkedIn: https://lk.linkedin.com/in/nathashanaranpanawa
>>>
>>>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> --
>>
>> *Nuwan Chamara Pallewela*
>>
>>
>> *Software Engineer*
>>
>> *WSO2, Inc. *http://wso2.com
>> *lean . enterprise . middleware*
>>
>> Email   *nuw...@wso2.com *
>> Mobile  *+94719079739 <%2B94719079739>@*
>>
>>
>>
>
>
> --
> --
>
> *Nuwan Chamara Pallewela*
>
>
> *Software Engineer*
>
> *WSO2, Inc. *http://wso2.com
> *lean . enterprise . middleware*
>
> Email   *nuw...@wso2.com *
> Mobile  *+94719079739 <%2B94719079739>@*
>
>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Imesh Gunaratne*
Senior Technical Lead
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: http://imesh.gunaratne.org
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [BPMN] Implementing correlation support for BPMN Rest API

[Firzhan Naqash]

Hi Chathura,

Shouldn't we provide messageName or signalName irrespective of the
availability of process definition key or id. Once we queried an execution,
I think we need either a message name or a signal name to trigger the
receive event. Please check with API.

We need to have the process definition id, in case there are multiple
versions of the same process definition exists with in the engine. Because
of this we are having it as an optional parameter.


Correlation variables are the ones used to query the relevant execution.
Process instance variables are used to pass in new data values with the
message. What is the purpose of the first "variables" parameter?


Sorry. I have mistakenly added the "variables" parameter. We don't need it.

Regards,
Firzhan


-- 
*Firzhan Naqash*
Senior Software Engineer - Integration Platform Team
WSO2 Inc. http://wso2.com

email: firz...@wso2.com
mobile: (+94) 77 9785674 <%28%2B94%29%2071%205247551>*|
blog: http://firzhanblogger.blogspot.com/
  *
*twitter: https://twitter.com/firzhan007  |
linked-in: **https://www.linkedin.com/in/firzhan
*

On Mon, Dec 14, 2015 at 2:25 PM, Chathura Ekanayake 
wrote:

> Hi Firzhan,
>
>
> *processDefinitionKey/processDefinitionId/messageName* (compulsory)
>>
>> Either one relevant property out of three should be specified in the
>> request.
>>
>
> Shouldn't we provide messageName or signalName irrespective of the
> availability of process definition key or id. Once we queried an execution,
> I think we need either a message name or a signal name to trigger the
> receive event. Please check with API.
>
>
>
>>
>> *activityId *(optional)
>>
>> This property is required when there are more than one receivers waiting
>> for the same message/signal in different execution flows.
>>
>>
>>
>> ​​
>> In the above process flow,  all three or two of the execution flows might
>> be waiting for the same message.
>>
>> *action *(compulsory)
>>
>> actions can be either messageEventRecieved/signalEventRecieved/signal.
>>
>> *signalName* (optional)
>>
>> If we have any signal related actions, then *signalName* has to be
>> specified.
>>
>>
>> *variables* (optional)
>>
>> This holds the task specific local variables that can be used to query
>> and filter the relevant process instances.
>>
>> *processInstanceVariables* (optional)
>>
>> All the instance variables except correlation variables can be mentioned
>> here.
>>
>>
>> *correlationVariables* (compulsory)
>>
>> All the correlation variables should be mentioned here. By default it
>> performs the equal operation of that variables.
>>
>> *variables* and *processInstanceVariables *can be used to speed up the
>> querying process and the correlation variables should be unique across the
>> process instances.
>>
>
> Correlation variables are the ones used to query the relevant execution.
> Process instance variables are used to pass in new data values with the
> message. What is the purpose of the first "variables" parameter?
>
> Regards,
> Chathura
>
>
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] App Factory Tier Implementation

[Imesh Gunaratne]

Few questions/points:

   - I can see the term "gear" is used in the tables but it's not
   described. Is this an unit of resources (CPU, memory, disk, etc)? If so how
   do we plan to control that for a cluster of containers?
   - What would be the entity that a tenant admin would subscribe to? Is
   this a container cluster or a composite container deployment (which would
   have a multiple clusters) or a set of app types?
   - Are we planning to expose an API for billing integration?
   - Do we have a plan to integrate with an existing billing solution to
   demonstrate billing capabilities?

Thanks

On Mon, Dec 14, 2015 at 9:37 AM, Nadeeshani Pathirennehelage <
nadeesha...@wso2.com> wrote:

> Hi All,
> We are hoping to implement the tier implementation for the AppFactory.
> Tier is the subscription plan which is selected by the organization admin
> for the organization.
>
>1.
>
>AF Set Up Engineer should be able to define Tiers (free/paid v1/ paid
>v2).
>2.
>
>AF Set Up Engineer should be able to define Container Specs.
>(t2.small/ t2.medium/ m2.small )
>3. System should display each Subscription Plans ( Free / Paid v1 /
>paid v2) to the Organization Admin(Tenant) to choose a suitable plan for
>the organization.
>4.
>
>Organization Admin(Tenant) should be able to upgrade the subscription
>plan for the organization.
>5. System should display the each Container Specs Type(
>Small/medium/large) with its features such as CPU, memory, storage to all
>tenants.
>6.
>
>Organization Admin(Tenant) should be able to choose new Container
>Specs ( small , large , medium ) to the existing subscription plan.
>Organization members should use those Container Spec.
>7.
>
>Organization Admin(Tenant) should be able to remove Container Specs (
>small , large , medium ) from the existing subscription plan.
>8. System should be able to view the details such as Plan Type, list
>of Container Specs which is running and information of each Container Spec,
>of a given Organization.
>
>
> Table structure is given below.
>
>
> ​
>
> *These tables are filled with just reference values.*
> The above plan table can be expanded with more columns.
>
> ​The above table structure will be useful for the administration to
> develop applications for configuring the tiers. Moreover it will be useful
> to render the subscription plan to the end users through UI.
>
> Would appreciate it if you could give your suggestions and comments on
> this.
> Thanks,
> Nadeeshani
>
> --
> Pathirennehelage Nadeeshani
> Software Engineering Intern : WSO2 Inc
> Mobile : +94 (0) 716 545223
> nadeesha...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Imesh Gunaratne*
Senior Technical Lead
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: http://imesh.gunaratne.org
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] PPaaS Artifact Migration Tool

[Malmee Weerasinghe]

Hi Imesh,

We will include a component architecture diagram of the PPaaS Artifact
Migration Tool.

Thanks.

On Tue, Dec 15, 2015 at 10:53 PM, Imesh Gunaratne  wrote:

> Hi Malmee,
>
> It would be better if you can draw a component architecture diagram to
> illustrate how this tool works.
>
> This might help us to understand how much load it can handle if the
> existing Private PaaS 4.0.0 environment has considerable amount of
> artifacts and subscriptions and how those can be processed efficiently.
>
> Thanks
>
> On Tue, Dec 15, 2015 at 10:39 PM, Malmee Weerasinghe 
> wrote:
>
>> Hi All,
>> We are developing a tool to convert PPaaS 4.0.0 artifact JSON files to
>> PPaaS 4.1.x. [1]
>>
>> There are changes in the artifacts deployment process in PPaaS 4.0.0
>> compared to 4.1.0. So this tool is developed for those who need to migrate
>> from PPaaS 4.0.0 to 4.1.0.
>>
>> We take the artifacts JSONs of PPaaS 4.0.0 through REST API endpoints,
>> convert them using the bean classes of PPaaS 4.0.0 and 4.1.0 which are
>> accessed via a dependency and generate output artifacts to to be compatible
>> with PPaaS 4.1.x. In this process, we use default values for the additional
>> artifacts.
>>
>> These are the conversions we have implemented already.
>>  - auto scale policy artifacts
>>  - network partition list artifacts
>>  - deployment policy artifacts
>>  - cartridge artifacts
>>  - application artifacts
>>  - application sign ups - convert the cartridge subscription artifacts
>> JSONs output from Subscription Manager [2]
>>  - domain mappings
>>
>> Would appreciate it if you could give your suggestions and comments on
>> this.
>> [1]
>> https://github.com/nishadi/product-private-paas/tree/master/tools/migration/ppaas-artifact-converter
>> 
>> [2]
>> https://github.com/wso2/product-private-paas/tree/master/tools/migration/subscription-manager/4.0.0
>> 
>>
>> --
>> Malmee Weerasinghe
>> WSO2 Intern
>> mobile : (+94)* 71 7601905* |   email :   
>> mal...@wso2.com
>>
>
>
>
> --
> *Imesh Gunaratne*
> Senior Technical Lead
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: http://imesh.gunaratne.org
> Lean . Enterprise . Middleware
>
>


-- 
Malmee Weerasinghe
WSO2 Intern
mobile : (+94)* 71 7601905* |   email :   
mal...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10

[Kasun Indrasiri]

@Kathees : Can we verify NTLM use cases with Call mediator + blocking
behavior? I guess it should work out of box as we also reuse the same
blocking sender code?

For DB* mediators, I guess we can clearly mention in the docs that these
mediators can be only used for very limited kind of DB operations but not
for any complex DB integrations we must use DSS. And we won't any such
features to DB* mediators.

POJO/Spring mediators seems to need more attention :) and we should enhance
them with proper use case docs.

WDYT?

On Fri, Dec 11, 2015 at 1:28 AM, Dulitha Wijewantha 
wrote:

>
>
> On Thu, Dec 10, 2015 at 1:26 AM, Vidura Gamini Abhaya 
> wrote:
>
>> Hi Isuru,
>>
>> I've used it in a mediation sequence where I use a POJO to generate a
>> unique customer id given a couple of parameters and there's a checksum
>> added to the end. I already had written this code and it was quite simple
>> and straightforward to reuse it with a POJOCommand mediator. I feel the
>> simplicity of it is a welcome feature, where reading and setting values in
>> MessageContext is automatically handled for me.
>>
>> I don't know whether a single usage case is enough to make the case to
>> keep it. However, if we decide to keep it though, I suggest that we improve
>> the documentation on it. I had to dig around to find out how the what the
>> different actions mean. It wasn't clear to me in the docs (I believe most
>> of the content is carried forward from Syanpse).
>>
>
> +1 for deprecating POJO Mediator. ​The problem I find with the above
> approach is that - there is an alternative way of doing it (using class
> mediators). Not having multiple options (to do the same thing) in a
> configurational language makes it easier for development, maintenance,
> training etc. An example will be - POJOMediator can use expressions where
> Class mediators you can't (making things confusing). It's better to push
> the point home saying - the way to write custom code in the ESB (if you
> have to) is using a class mediator and the message context api.
>
> Apart from that - I believe in the POJO mediator we create multiple
> objects in the heap? Where as in the class mediator we just create once
> instance. Am I correct on this observation?
>
> I am -1 for deprecating Db mediators. Like Malaka said, they are very
> useful in scenarios where people want to connect to databases (also can be
> used in conjunction with cache mediator for performance).
>
>
>>
>> Thanks and Regards,
>>
>> Vidura
>>
>>
>>
>> On 10 December 2015 at 10:57, Isuru Udana  wrote:
>>
>>> Hi Kathees,
>>>
>>> I think we should do a comparison once more to make sure that we have
>>> covered everything before removing Callout. NTLM one which Harshana pointed
>>> out may be due to absence of initClientOptions configuration option.
>>>
>>> Hi Vidura,
>>> Point you raised on the POJOCommand mediator is really interesting. We
>>> haven't seen any usage of that over years. But now we found at least one
>>> user who has found it useful. Thanks for pointing that out. So we should
>>> reconsider how useful it is.
>>>
>>> Thanks.
>>>
>>>
>>>
>>> On Thu, Dec 10, 2015 at 10:39 AM, Kathees Rajendram 
>>> wrote:
>>>
 +1 to deprecate Callout mediator since we have the Callout mediator
 functionalities in Call mediator.

 On Thu, Dec 10, 2015 at 1:18 AM, Vidura Gamini Abhaya 
 wrote:

> I've found DBReport / DBLookup to be quite useful for simple DB
> operations as they are easy to do OOTB. While DB Lookup mediator maybe
> limited in it's ability to only being able to return a single row of data,
> DB Report mediator is still quite useful in writing to a database,
> especially when we use a DB as part of the mediation sequences.
>
> I also feel it is worth continuing with POJOCommand, as it is the most
> simplest way of executing some custom code as part of a sequence. Although
> it is possible to do the same with a Class mediator, one doesn't have to
> worry about adding the proper jars, working with MessageContext etc. with
> the POJOCommand. I think we should retain it for the sake of simplicity of
> use.
>
> I'm +1 to deprecate the rest of the mediators.
>
> Thanks,
>
> Vidura
>
>
>
> On 9 December 2015 at 12:11, Kasun Indrasiri  wrote:
>
>> Shall we deprecate following mediators in 4.10 release.
>>
>> *- Callout mediator :*
>>  All the callout functionality is supported with 'call' mediator with
>> blocking=true. Having two similar mediators will be create a bit of a
>> confusion.
>>
>> *- DBReport/DBLookup mediator*
>> These mediators offer very limited functionality and we always
>> recommend to integrate with databases with the use of DSS (using a 
>> separate
>> DSS or using DSS features inside ESB)
>>
>> *- Bean, 

Re: [Architecture] App Factory Tier Implementation

[Imesh Gunaratne]

Thanks for the clarifications Kasun!

On Tue, Dec 15, 2015 at 5:41 PM, Kasun De Silva  wrote:

> Hi Imesh,
>
> See my comments inline,
>
>>
>>- I can see the term "gear" is used in the tables but it's not
>>described. Is this an unit of resources (CPU, memory, disk, etc)? If so 
>> how
>>do we plan to control that for a cluster of containers?
>>
>> Yes "Gear" is an unit of resources, but  AFAIU we should not use this
> word since openshift already use it.
> @Nadeeshani please use "Container Spec" instead for now until we figure
> out something better.
>
>>
>>- What would be the entity that a tenant admin would subscribe to? Is
>>this a container cluster or a composite container deployment (which would
>>have a multiple clusters) or a set of app types?
>>
>> Tenant would subscribe to a Plan that is the main entity. Plan consist of
> a container cluster. He can use this container cluster to do his
> deployments.
>
>>
>>- Are we planning to expose an API for billing integration?
>>
>> Yes, REST API will be provided for billing and subscription plan
> applications since we are planning to have payment modules and subscription
> modules separate from AF.  (Could be existing Cloudmgt app)
>
>>
>>- Do we have a plan to integrate with an existing billing solution to
>>demonstrate billing capabilities?
>>
>> +1 for this, @AF team WDYT?
>
> Thanks,
> Kasun
>
> --
> *Kasun de Silva*
> Software Engineer | *WSO2 Inc.*; http://wso2.com
> lean.enterprise.middleware
>
> email   : kas...@wso2.com
> mobile : +94 77 794 4260
>
>


-- 
*Imesh Gunaratne*
Senior Technical Lead
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: http://imesh.gunaratne.org
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [BPMN] Implementing correlation support for BPMN Rest API

[Chathura Ekanayake]

>
>
> We need to have the process definition id, in case there are multiple
> versions of the same process definition exists with in the engine. Because
> of this we are having it as an optional parameter.
>

I agree with that. But can we make message name optional? We use process
definition id, activiti id, correlation variables, etc to locate the
execution. Once an execution is located, I think we need to provide the
message name when triggering the message event.


>
>
>
> On Mon, Dec 14, 2015 at 2:25 PM, Chathura Ekanayake 
> wrote:
>
>> Hi Firzhan,
>>
>>
>> *processDefinitionKey/processDefinitionId/messageName* (compulsory)
>>>
>>> Either one relevant property out of three should be specified in the
>>> request.
>>>
>>
>> Shouldn't we provide messageName or signalName irrespective of the
>> availability of process definition key or id. Once we queried an execution,
>> I think we need either a message name or a signal name to trigger the
>> receive event. Please check with API.
>>
>>
>>
>>>
>>> *activityId *(optional)
>>>
>>> This property is required when there are more than one receivers waiting
>>> for the same message/signal in different execution flows.
>>>
>>>
>>>
>>> ​​
>>> In the above process flow,  all three or two of the execution flows
>>> might be waiting for the same message.
>>>
>>> *action *(compulsory)
>>>
>>> actions can be either messageEventRecieved/signalEventRecieved/signal.
>>>
>>> *signalName* (optional)
>>>
>>> If we have any signal related actions, then *signalName* has to be
>>> specified.
>>>
>>>
>>> *variables* (optional)
>>>
>>> This holds the task specific local variables that can be used to query
>>> and filter the relevant process instances.
>>>
>>> *processInstanceVariables* (optional)
>>>
>>> All the instance variables except correlation variables can be mentioned
>>> here.
>>>
>>>
>>> *correlationVariables* (compulsory)
>>>
>>> All the correlation variables should be mentioned here. By default it
>>> performs the equal operation of that variables.
>>>
>>> *variables* and *processInstanceVariables *can be used to speed up the
>>> querying process and the correlation variables should be unique across the
>>> process instances.
>>>
>>
>> Correlation variables are the ones used to query the relevant execution.
>> Process instance variables are used to pass in new data values with the
>> message. What is the purpose of the first "variables" parameter?
>>
>> Regards,
>> Chathura
>>
>>
>>
>>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] App Factory Tier Implementation

[Nadeeshani Pathirennehelage]

Hi All,

*​Further clarification of Tier User Stories.*

Appfactoery set up engineer will define the container_specs. As an example
t2.small with the features CPU 1, memory 2 and memeory 4GB.
He will also be defining the subscription plans.

Then organizations(Tenants) can subscribe to the plans. Then that tenant
would get assigned to the free tier. Free tier will allow to choose the
containers of t2.small, t2.medium, t2.large with maximum of 6 containers
where the Appfactory controls the maximum number of containers.

So if a container is chosen, the containers that can be selected would
reduce by one.
If want tenant can upgrade their plan to paid tier.

Kubernetes Quotas will control the container specs' Resources.

Updated table structure is given below.


​
​Thanks,

Nadeeshani.

On Wed, Dec 16, 2015 at 6:41 AM, Imesh Gunaratne  wrote:

> Thanks for the clarifications Kasun!
>
> On Tue, Dec 15, 2015 at 5:41 PM, Kasun De Silva  wrote:
>
>> Hi Imesh,
>>
>> See my comments inline,
>>
>>>
>>>- I can see the term "gear" is used in the tables but it's not
>>>described. Is this an unit of resources (CPU, memory, disk, etc)? If so 
>>> how
>>>do we plan to control that for a cluster of containers?
>>>
>>> Yes "Gear" is an unit of resources, but  AFAIU we should not use this
>> word since openshift already use it.
>> @Nadeeshani please use "Container Spec" instead for now until we figure
>> out something better.
>>
>>>
>>>- What would be the entity that a tenant admin would subscribe to?
>>>Is this a container cluster or a composite container deployment (which
>>>would have a multiple clusters) or a set of app types?
>>>
>>> Tenant would subscribe to a Plan that is the main entity. Plan consist
>> of a container cluster. He can use this container cluster to do his
>> deployments.
>>
>>>
>>>- Are we planning to expose an API for billing integration?
>>>
>>> Yes, REST API will be provided for billing and subscription plan
>> applications since we are planning to have payment modules and subscription
>> modules separate from AF.  (Could be existing Cloudmgt app)
>>
>>>
>>>- Do we have a plan to integrate with an existing billing solution
>>>to demonstrate billing capabilities?
>>>
>>> +1 for this, @AF team WDYT?
>>
>> Thanks,
>> Kasun
>>
>> --
>> *Kasun de Silva*
>> Software Engineer | *WSO2 Inc.*; http://wso2.com
>> lean.enterprise.middleware
>>
>> email   : kas...@wso2.com
>> mobile : +94 77 794 4260
>>
>>
>
>
> --
> *Imesh Gunaratne*
> Senior Technical Lead
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: http://imesh.gunaratne.org
> Lean . Enterprise . Middleware
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Pathirennehelage Nadeeshani
Software Engineering Intern : WSO2 Inc
Mobile : +94 (0) 716 545223
nadeesha...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [MSS] Return javax.ws.rs.core.Response while running OSGi mode

[Sagara Gunathunga]

On Wed, Dec 2, 2015 at 4:49 PM, Aruna Karunarathna  wrote:

>
>
> On Mon, Nov 30, 2015 at 12:50 PM, Aruna Karunarathna 
> wrote:
>
>>
>>
>> On Mon, Nov 30, 2015 at 11:59 AM, Sameera Jayasoma 
>> wrote:
>>
>>> I guess this a bug. You can fix this and contribute back to Aries.
>>>
>>
>> Actually I have filed a bug regarding this for Aries project [1]
>> Seems like it is in in-progress state.
>>
>> [1]. https://issues.apache.org/jira/browse/ARIES-1461
>>
>
> The SPI-fly guys have provided a possible fix. I tested with the fragment
> bundle for the javax.ws.rs-api_2.0.0.jar and seems it's working perfectly.
>
> We should be able to use that once it's released.
>

 Have we fixed this issue in trunk ? Can I use Response as return type now
?

Thanks !


>
> Regards,
> Aruna
>
>>
>>> On Thu, Nov 26, 2015 at 12:11 PM, Aruna Karunarathna 
>>> wrote:
>>>


 On Tue, Nov 24, 2015 at 10:02 PM, Sagara Gunathunga 
 wrote:

>
>
> On Mon, Nov 23, 2015 at 2:15 PM, Aruna Karunarathna 
> wrote:
>
>>
>>
>> On Mon, Nov 16, 2015 at 12:39 PM, Samiyuru Senarathne <
>> samiy...@wso2.com> wrote:
>>
>>> Hi Sagara,
>>>
>>> This issue is about loading our implementation
>>> of javax.ws.rs.core.Response [1] in OSGi mode using
>>> java java.util.ServiceLoader [2] by the relevant bundle. This issue is 
>>> yet
>>> to be fixed and according to the discussions we had, the solution is to 
>>> use
>>> SPI Fly [3] to fix the ServiceLoader issue.
>>>
>>
>> I tried using SPI-fly approach to overcome this problem. Seems like
>> we cant use SPI Fly approach directly, since in the javax.ws.rs-api they
>> are loading the implementation class using the class.forName().
>> We have to investigate the possibilities of loading the
>> implementation class using a fragment bundle approach, and load the class
>> using the
>> ServiceLoader.load().
>>
>
> One quick suggestion, shall we change JAX-RS API sepc implementation
> from Oracle to Geronimo and check with SPI-fly ? BTW I haven't check how
> Geronimo spec load Response class.
>
>
 Hi Sagara,

 Was able to make it working using the SPI-Fly. But we need the
 following attributes in the respective bundles.

 *javax.ws.rs.ext.RuntimeDelegate* in
 the org.wso2.carbon.mss_1.0.0.SNAPSHOT.jar


 *javax.ws.rs.ext.RuntimeDelegate#findDelegate*
 in the javax.ws.rs-api_2.0.0.jar

 I had to tested this by creating a orbit bundle from
 the javax.ws.rs-api_2.0.0.jar.

 @Sameera
 I tried to create a fragment bundle for the javax.ws.rs-api_2.0.0.jar
 to add the  SPI-Consumer entry. Seems like spi-fly not picking up the entry
 is for the javax.ws.rs-api_2.0.0.jar

 I guess we have to create an orbit. Any thoughts?

 Regards,
 Aruna
 --

 *Aruna Sujith Karunarathna *| Software Engineer
 WSO2, Inc | lean. enterprise. middleware.
 #20, Palm Grove, Colombo 03, Sri Lanka
 Mobile: +94 71 9040362 | Work: +94 112145345
 Email: ar...@wso2.com | Web: www.wso2.com


>>>
>>>
>>>
>>> --
>>> Sameera Jayasoma,
>>> Software Architect,
>>>
>>> WSO2, Inc. (http://wso2.com)
>>> email: same...@wso2.com
>>> blog: http://blog.sameera.org
>>> twitter: https://twitter.com/sameerajayasoma
>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
>>> Mobile: 0094776364456
>>>
>>> Lean . Enterprise . Middleware
>>>
>>>
>>
>>
>> --
>>
>> *Aruna Sujith Karunarathna *| Software Engineer
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 71 9040362 | Work: +94 112145345
>> Email: ar...@wso2.com | Web: www.wso2.com
>>
>>
>
>
>
> --
>
> *Aruna Sujith Karunarathna *| Software Engineer
> WSO2, Inc | lean. enterprise. middleware.
> #20, Palm Grove, Colombo 03, Sri Lanka
> Mobile: +94 71 9040362 | Work: +94 112145345
> Email: ar...@wso2.com | Web: www.wso2.com
>
>



-- 
Sagara Gunathunga

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

Re: [Architecture] [MSS] Return javax.ws.rs.core.Response while running OSGi mode

[Afkham Azeez]

Yes it is working. I have tested it with both OSGi bundle mode & deployable
jar mode in the MSS server runtime.

On Wed, Dec 16, 2015 at 11:53 AM, Sagara Gunathunga  wrote:

>
>
> On Wed, Dec 2, 2015 at 4:49 PM, Aruna Karunarathna  wrote:
>
>>
>>
>> On Mon, Nov 30, 2015 at 12:50 PM, Aruna Karunarathna 
>> wrote:
>>
>>>
>>>
>>> On Mon, Nov 30, 2015 at 11:59 AM, Sameera Jayasoma 
>>> wrote:
>>>
 I guess this a bug. You can fix this and contribute back to Aries.

>>>
>>> Actually I have filed a bug regarding this for Aries project [1]
>>> Seems like it is in in-progress state.
>>>
>>> [1]. https://issues.apache.org/jira/browse/ARIES-1461
>>>
>>
>> The SPI-fly guys have provided a possible fix. I tested with the fragment
>> bundle for the javax.ws.rs-api_2.0.0.jar and seems it's working
>> perfectly.
>>
>> We should be able to use that once it's released.
>>
>
>  Have we fixed this issue in trunk ? Can I use Response as return type now
> ?
>
> Thanks !
>
>
>>
>> Regards,
>> Aruna
>>
>>>
 On Thu, Nov 26, 2015 at 12:11 PM, Aruna Karunarathna 
 wrote:

>
>
> On Tue, Nov 24, 2015 at 10:02 PM, Sagara Gunathunga 
> wrote:
>
>>
>>
>> On Mon, Nov 23, 2015 at 2:15 PM, Aruna Karunarathna 
>> wrote:
>>
>>>
>>>
>>> On Mon, Nov 16, 2015 at 12:39 PM, Samiyuru Senarathne <
>>> samiy...@wso2.com> wrote:
>>>
 Hi Sagara,

 This issue is about loading our implementation
 of javax.ws.rs.core.Response [1] in OSGi mode using
 java java.util.ServiceLoader [2] by the relevant bundle. This issue is 
 yet
 to be fixed and according to the discussions we had, the solution is 
 to use
 SPI Fly [3] to fix the ServiceLoader issue.

>>>
>>> I tried using SPI-fly approach to overcome this problem. Seems like
>>> we cant use SPI Fly approach directly, since in the javax.ws.rs-api they
>>> are loading the implementation class using the class.forName().
>>> We have to investigate the possibilities of loading the
>>> implementation class using a fragment bundle approach, and load the 
>>> class
>>> using the
>>> ServiceLoader.load().
>>>
>>
>> One quick suggestion, shall we change JAX-RS API sepc implementation
>> from Oracle to Geronimo and check with SPI-fly ? BTW I haven't check how
>> Geronimo spec load Response class.
>>
>>
> Hi Sagara,
>
> Was able to make it working using the SPI-Fly. But we need the
> following attributes in the respective bundles.
>
> *javax.ws.rs.ext.RuntimeDelegate* in
> the org.wso2.carbon.mss_1.0.0.SNAPSHOT.jar
>
>
> *javax.ws.rs.ext.RuntimeDelegate#findDelegate*
> in the javax.ws.rs-api_2.0.0.jar
>
> I had to tested this by creating a orbit bundle from
> the javax.ws.rs-api_2.0.0.jar.
>
> @Sameera
> I tried to create a fragment bundle for the javax.ws.rs-api_2.0.0.jar
> to add the  SPI-Consumer entry. Seems like spi-fly not picking up the 
> entry
> is for the javax.ws.rs-api_2.0.0.jar
>
> I guess we have to create an orbit. Any thoughts?
>
> Regards,
> Aruna
> --
>
> *Aruna Sujith Karunarathna *| Software Engineer
> WSO2, Inc | lean. enterprise. middleware.
> #20, Palm Grove, Colombo 03, Sri Lanka
> Mobile: +94 71 9040362 | Work: +94 112145345
> Email: ar...@wso2.com | Web: www.wso2.com
>
>



 --
 Sameera Jayasoma,
 Software Architect,

 WSO2, Inc. (http://wso2.com)
 email: same...@wso2.com
 blog: http://blog.sameera.org
 twitter: https://twitter.com/sameerajayasoma
 flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
 Mobile: 0094776364456

 Lean . Enterprise . Middleware


>>>
>>>
>>> --
>>>
>>> *Aruna Sujith Karunarathna *| Software Engineer
>>> WSO2, Inc | lean. enterprise. middleware.
>>> #20, Palm Grove, Colombo 03, Sri Lanka
>>> Mobile: +94 71 9040362 | Work: +94 112145345
>>> Email: ar...@wso2.com | Web: www.wso2.com
>>>
>>>
>>
>>
>>
>> --
>>
>> *Aruna Sujith Karunarathna *| Software Engineer
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 71 9040362 | Work: +94 112145345
>> Email: ar...@wso2.com | Web: www.wso2.com
>>
>>
>
>
>
> --
> Sagara Gunathunga
>
> Architect; WSO2, Inc.;  http://wso2.com
> V.P Apache Web Services;http://ws.apache.org/
> Linkedin; http://www.linkedin.com/in/ssagara
> Blog ;  http://ssagara.blogspot.com
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* *
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*

Re: [Architecture] [MSS] Return javax.ws.rs.core.Response while running OSGi mode

[Sagara Gunathunga]

On Wed, Dec 16, 2015 at 11:55 AM, Afkham Azeez  wrote:

> Yes it is working. I have tested it with both OSGi bundle mode &
> deployable jar mode in the MSS server runtime.
>
Great !

Thanks !

>
> On Wed, Dec 16, 2015 at 11:53 AM, Sagara Gunathunga 
> wrote:
>
>>
>>
>> On Wed, Dec 2, 2015 at 4:49 PM, Aruna Karunarathna 
>> wrote:
>>
>>>
>>>
>>> On Mon, Nov 30, 2015 at 12:50 PM, Aruna Karunarathna 
>>> wrote:
>>>


 On Mon, Nov 30, 2015 at 11:59 AM, Sameera Jayasoma 
 wrote:

> I guess this a bug. You can fix this and contribute back to Aries.
>

 Actually I have filed a bug regarding this for Aries project [1]
 Seems like it is in in-progress state.

 [1]. https://issues.apache.org/jira/browse/ARIES-1461

>>>
>>> The SPI-fly guys have provided a possible fix. I tested with the
>>> fragment bundle for the javax.ws.rs-api_2.0.0.jar and seems it's
>>> working perfectly.
>>>
>>> We should be able to use that once it's released.
>>>
>>
>>  Have we fixed this issue in trunk ? Can I use Response as return type
>> now ?
>>
>> Thanks !
>>
>>
>>>
>>> Regards,
>>> Aruna
>>>

> On Thu, Nov 26, 2015 at 12:11 PM, Aruna Karunarathna 
> wrote:
>
>>
>>
>> On Tue, Nov 24, 2015 at 10:02 PM, Sagara Gunathunga 
>> wrote:
>>
>>>
>>>
>>> On Mon, Nov 23, 2015 at 2:15 PM, Aruna Karunarathna 
>>> wrote:
>>>


 On Mon, Nov 16, 2015 at 12:39 PM, Samiyuru Senarathne <
 samiy...@wso2.com> wrote:

> Hi Sagara,
>
> This issue is about loading our implementation
> of javax.ws.rs.core.Response [1] in OSGi mode using
> java java.util.ServiceLoader [2] by the relevant bundle. This issue 
> is yet
> to be fixed and according to the discussions we had, the solution is 
> to use
> SPI Fly [3] to fix the ServiceLoader issue.
>

 I tried using SPI-fly approach to overcome this problem. Seems like
 we cant use SPI Fly approach directly, since in the javax.ws.rs-api 
 they
 are loading the implementation class using the class.forName().
 We have to investigate the possibilities of loading the
 implementation class using a fragment bundle approach, and load the 
 class
 using the
 ServiceLoader.load().

>>>
>>> One quick suggestion, shall we change JAX-RS API sepc implementation
>>> from Oracle to Geronimo and check with SPI-fly ? BTW I haven't check how
>>> Geronimo spec load Response class.
>>>
>>>
>> Hi Sagara,
>>
>> Was able to make it working using the SPI-Fly. But we need the
>> following attributes in the respective bundles.
>>
>> *javax.ws.rs.ext.RuntimeDelegate* in
>> the org.wso2.carbon.mss_1.0.0.SNAPSHOT.jar
>>
>>
>> *javax.ws.rs.ext.RuntimeDelegate#findDelegate*
>> in the javax.ws.rs-api_2.0.0.jar
>>
>> I had to tested this by creating a orbit bundle from
>> the javax.ws.rs-api_2.0.0.jar.
>>
>> @Sameera
>> I tried to create a fragment bundle for the javax.ws.rs-api_2.0.0.jar
>> to add the  SPI-Consumer entry. Seems like spi-fly not picking up the 
>> entry
>> is for the javax.ws.rs-api_2.0.0.jar
>>
>> I guess we have to create an orbit. Any thoughts?
>>
>> Regards,
>> Aruna
>> --
>>
>> *Aruna Sujith Karunarathna *| Software Engineer
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 71 9040362 | Work: +94 112145345
>> Email: ar...@wso2.com | Web: www.wso2.com
>>
>>
>
>
>
> --
> Sameera Jayasoma,
> Software Architect,
>
> WSO2, Inc. (http://wso2.com)
> email: same...@wso2.com
> blog: http://blog.sameera.org
> twitter: https://twitter.com/sameerajayasoma
> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
> Mobile: 0094776364456
>
> Lean . Enterprise . Middleware
>
>


 --

 *Aruna Sujith Karunarathna *| Software Engineer
 WSO2, Inc | lean. enterprise. middleware.
 #20, Palm Grove, Colombo 03, Sri Lanka
 Mobile: +94 71 9040362 | Work: +94 112145345
 Email: ar...@wso2.com | Web: www.wso2.com


>>>
>>>
>>>
>>> --
>>>
>>> *Aruna Sujith Karunarathna *| Software Engineer
>>> WSO2, Inc | lean. enterprise. middleware.
>>> #20, Palm Grove, Colombo 03, Sri Lanka
>>> Mobile: +94 71 9040362 | Work: +94 112145345
>>> Email: ar...@wso2.com | Web: www.wso2.com
>>>
>>>
>>
>>
>>
>> --
>> Sagara Gunathunga
>>
>> Architect; WSO2, Inc.;  http://wso2.com
>> V.P Apache Web Services;http://ws.apache.org/
>> Linkedin; http://www.linkedin.com/in/ssagara
>> Blog ;  

Re: [Architecture] Issue when you start up MSS in server mode

[Sagara Gunathunga]

On Thu, Dec 10, 2015 at 2:15 PM, Afkham Azeez  wrote:

> The deployment engine should call the deployer only for valid artifact
> types. So yes, it looks like the fixes have to be done in the kernel.
>

In addition to *.txt  files I'm getting same exception for .DS_Store file
created by the OS as well.

In C5 how we define (identify) artifact types for deployment ?

We used to identify artifact types based on file extension such as .arr,
.jar etc. If we still use same approach it would be better and much
efficient to pass a FilenameFilter[1] object into the listFiles() call  on
RepositoryScanner#findArtifactsToDeploy() method instead of iterating all
the files in the directory.

[1] - https://docs.oracle.com/javase/8/docs/api/java/io/FilenameFilter.html


Thanks !

>
> On Thu, Dec 10, 2015 at 1:47 PM, Samiyuru Senarathne 
> wrote:
>
>> First part of this issue is trying to deploy invalid files. The second
>> part of the issue is deployment engine tries to deploy the artifact again
>> and again even though an exception is thrown for that particular artifact
>> by the deployer. Because of this the exception is thrown again and again.
>>
>> The second part of the problem will be solved with the kernel GA since
>> the GA's deployment engine records the faulty artifacts.
>>
>> IMO the first part of issue also should be fixed in deployment engine.
>> The reason for that is as follows.
>>
>> *org.wso2.carbon.mss.internal.deployer.MSSDeployer* implements
>> *org.wso2.carbon.kernel.deployment.Deployer* interface that is provided
>> by the deployment engine of carbon kernel.
>>
>> org.wso2.carbon.kernel.deployment.Deployer interface has the following
>> functions.
>>
>>- Object deploy(Artifact var1) throws CarbonDeploymentException;
>>- void undeploy(Object var1) throws CarbonDeploymentException;
>>- Object update(Artifact var1) throws CarbonDeploymentException;
>>- URL getLocation();
>>- ArtifactType getArtifactType();
>>
>> Here deploy(Artifact var1) function is called with a
>> *org.wso2.carbon.kernel.deployment.Artifact* parameter by the kernel's
>> deployment engine whenever a new artifact is found. So, deploy() function
>> is called with both valid and invalid artifact types.
>>
>> Here, getArtifactType() is meant to get the artifact type that is
>> supported by a particular deployer implementation. IMO since this function
>> is there to identify the supported artifact types of a Deployer, deployment
>> engine should filter the found artifacts using the ArtifactType before
>> calling the deploy() function of a Deployer implementation. Then, the
>> deployment engine will call deploy() function only with valid artifacts for
>> that specific deployer. Therefore, each deployer implementation will not
>> have to do duplicate implementations to filt the artifact types they
>> support. IMO unless getting an ArtifactType from the deployer
>> implementation is less useful.
>>
>> WDYT?
>>
>> Best Regards,
>> Samiyuru
>>
>> On Thu, Dec 10, 2015 at 11:35 AM, Afkham Azeez  wrote:
>>
>>> [2015-12-10 11:34:09,012]  INFO
>>> {org.wso2.carbon.mss.internal.deployer.MSSDeployer} - Deploying artifact:
>>> /Users/azeez/projects/github/wso2/product-mss/product/target/wso2mss-1.0.0-SNAPSHOT/repository/deployment/server/mss/README.txt
>>>
>>> [2015-12-10 11:34:09,013] ERROR
>>> {org.wso2.carbon.kernel.internal.deployment.DeploymentEngine} - Error while
>>> deploying artifacts
>>> org.wso2.carbon.kernel.deployment.exception.CarbonDeploymentException:
>>> Error while processing the artifact:
>>> /Users/azeez/projects/github/wso2/product-mss/product/target/wso2mss-1.0.0-SNAPSHOT/repository/deployment/server/mss/README.txt
>>>
>>> at
>>> org.wso2.carbon.mss.internal.deployer.MSSDeployer.deploy(MSSDeployer.java:78)
>>>
>>> at
>>> org.wso2.carbon.kernel.internal.deployment.DeploymentEngine.lambda$deployArtifacts$18(DeploymentEngine.java:229)
>>>
>>> at
>>> org.wso2.carbon.kernel.internal.deployment.DeploymentEngine$$Lambda$45/1996363093.accept(Unknown
>>> Source)
>>>
>>> at java.util.ArrayList.forEach(ArrayList.java:1249)
>>>
>>> at
>>> org.wso2.carbon.kernel.internal.deployment.DeploymentEngine.deployArtifacts(DeploymentEngine.java:225)
>>>
>>> at
>>> org.wso2.carbon.kernel.internal.deployment.RepositoryScanner.sweep(RepositoryScanner.java:110)
>>>
>>> at
>>> org.wso2.carbon.kernel.internal.deployment.RepositoryScanner.scan(RepositoryScanner.java:68)
>>>
>>> at
>>> org.wso2.carbon.kernel.internal.deployment.SchedulerTask.run(SchedulerTask.java:43)
>>>
>>> at
>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>>
>>> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
>>>
>>> at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>>>
>>> at
>>> 

[Architecture] Have we considered using pre-compiled handlebars?

[Prabath Abeysekera]

Hi Manu/SameeraM,

$Subject? I'm just wondering if we've already got some mechanism/model to
use pre-compiled [1] handlebars in applications developed with Jaggery +
handlebars.

[1] http://handlebarsjs.com/precompilation.html

Cheers,
Prabath
-- 
Prabath Abeysekara
Technical Lead
WSO2 Inc.
Email: praba...@wso2.com
Mobile: +94774171471
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10

[Cyril Rognon]

Hi

DB mediator can be handy as you said but it is a bad  practice to query the
DB right from the Esb. It is against the low coupling principles that makes
integration  layer agile and   thin and scalable etc.

DSS is setup in two  minutes and can fulfill your needs   out of the box.

Maybe we should provide a migration tool to turn  DBMediator usage into
Daraservices operation  call.  One could even  generate the dbs Dataservice
definition from the DBMediator.

+1 for deprecating these  mediators.  Setup some tool or complete
documentation to migrate existing usage.

Thanks,
Cyril
Le 9 déc. 2015 13:55, "Malaka Silva"  a écrit :

> In my experience using ​DB mediator we can cover some of the use cases
> using ESB out of the box, which I find very handy.
>
> Also use case of integrating with stored procs can easily covered with
> this.
>
> However there are limits like batch update or getting multiple rows.
>
> ​I guess we can argue both ways. IMO we should keep these mediators since
> it'll become handy for some use cases :)
>
> On Wed, Dec 9, 2015 at 4:58 PM, Kasun Indrasiri  wrote:
>
>>
>>
>> On Wed, Dec 9, 2015 at 3:32 PM, Malaka Silva  wrote:
>>
>>> +1 except  DBReport/DBLookup mediators
>>>
>>> DBReport and DBLookup only offer a very limited set of capabilities.
>> IMO, for any real integration scenario, we can't use them.  :).
>>
>>> On Wed, Dec 9, 2015 at 2:00 PM, Yumani Ranaweera 
>>> wrote:
>>>
 Is it possible to provide sufficient documentation to help the
 customers who would be migrating in future.

 Thanks,
 Yumani


 On Wed, Dec 9, 2015 at 1:45 PM, Chanaka Fernando 
 wrote:

> *- Callout mediator :*
>  All the callout functionality is supported with 'call' mediator with
> blocking=true. Having two similar mediators will be create a bit of a
> confusion.
>
> It will make a lot of confusion when we have more than one mediators
> to do the same thing. Therefore, better to deprecate this mediator.
>
> *- DBReport/DBLookup mediator*
> These mediators offer very limited functionality and we always
> recommend to integrate with databases with the use of DSS (using a 
> separate
> DSS or using DSS features inside ESB)
>
> Even though this mediator has been used by some customers, they are
> using that for very limited functionality and we always suggest them to 
> use
> DSS as Kasun mentioned. If users really want to connect to a database, 
> they
> can easily write a simple class mediator.
>
> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
> development happens on these.
> *- Router* : Same as filter mediator, so no use of having this.
> *- In, Out * : Rarely used and often not required with the new
> call/respond mediator approach.
>
> +1 for deprecating these mediators.
>
> With the new DAS integration, we can deprecate BAM mediator since we
> have the PublishEvent mediator.
>
> On Wed, Dec 9, 2015 at 6:41 AM, Kasun Indrasiri 
> wrote:
>
>> Shall we deprecate following mediators in 4.10 release.
>>
>> *- Callout mediator :*
>>  All the callout functionality is supported with 'call' mediator with
>> blocking=true. Having two similar mediators will be create a bit of a
>> confusion.
>>
>> *- DBReport/DBLookup mediator*
>> These mediators offer very limited functionality and we always
>> recommend to integrate with databases with the use of DSS (using a 
>> separate
>> DSS or using DSS features inside ESB)
>>
>> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
>> development happens on these.
>> *- Router* : Same as filter mediator, so no use of having this.
>> *- In, Out * : Rarely used and often not required with the new
>> call/respond mediator approach.
>>
>> Any comments  on these or any other features that we should deprecate
>> from 4.10 release?
>>
>> Thanks,
>> Kasun.
>>
>> --
>> Kasun Indrasiri
>> Software Architect
>> WSO2, Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> cell: +94 77 556 5206
>> Blog : http://kasunpanorama.blogspot.com/
>>
>
>
>
> --
> Thank you and Best Regards,
> Chanaka Fernando
> Senior Technical Lead
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 773337238
> Blog : http://soatutorials.blogspot.com
> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
> Twitter:https://twitter.com/chanakaudaya
>
>
>
>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --

[Architecture] Implementing Latency Metrics Calculation Feature in GW

[Isuru Ranawaka]

Hi all ,

We can include feature for  Latency measurement of GW requests and other
relevant parameters related to connections. I have came up with a initial
architecture diagram of the module as below


​

   - Each message going through GW should be able to store timestamps
   related to transport , message building, message formatting , mediation ..
   etc.
   - Finally after finishing the writing  of   response  to the client
   those values need to be publish to the Data Receiver of the statistics
   component.
   - Data receiver needs to be Asynchronously collect the data without
   blocking GW threads.
   - Latency Calculation Engine should be configurable (such as  per
   request updating or time based updating)
   - Scheduler is for  notify the Engine to calculate latency values timely
   based.
   - There should be extension point to add event formatters in order to
   publish events in different formatters when needed.
   - As a default values are published through JMX via m beans.


thanks

IsuruR
-- 
Best Regards
Isuru Ranawaka
M: +94714629880
Blog : http://isurur.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture