Re: [Architecture] Replacing current JS engine used in script mediator with new rhino and nashorn script engines

[Sanjiva Weerawarana]

Kasun we should move to Nashorn - we're already doing that in UUF and
that's the future.

On Wed, Apr 13, 2016 at 1:58 AM, Manuranga Perera  wrote:

> I assume the current script engine use evaluate method. We can support
> evaluating once and invoking per request. This will add significant
> per-request performance improvements.
>
> Also when switching to nashorn we may be able to support IDEA debugging
> like we have done for new UI framework.
>
> On Mon, Apr 11, 2016 at 1:47 PM, Kasun Indrasiri  wrote:
>
>> I think for a major release such as 5.0, its quite important to get this
>> kind of major limitations fixed (this has been raised in several occasions
>> AFAIR)
>>
>> Lets spend sometime and evaluate the effort involves with this.
>> For Connectors, if this introduce any issues, we have to fix them and
>> re-release connectors. Here we are talking about a major release and we
>> simply can't halt such enhancements because of the down stream
>> components/features.
>>
>> On Mon, Apr 11, 2016 at 2:04 PM, Maheeka Jayasuriya 
>> wrote:
>>
>>> Hi all,
>>>
>>> Current script mediator implementation depends on apache-commons-bsf-3.0
>>> to get the script engines for Rhino, Ruby, Groovy and Jython [1][2].
>>> However, moving forward if we are to support newer Rhino and Nashorn (for
>>> Java 8) we can directly use these engines or any other implementation of
>>> our own by extending javax.script.ScriptEngine and
>>> javax.script.ScriptEngineFactory respectively. We only need to register
>>> these with the javax.script.ScriptEngineManager. We can for the moment
>>> support newer version of Rhino and Nashorn as new script engines (by
>>> defining a new parameter value to select the engine) so as to not break the
>>> existing stories.
>>>
>>> Are we aware of all the limitations of Rhino at the moment? Is it only
>>> the 64KB limitation that we are focusing on?
>>>
>>> [1] http://commons.apache.org/proper/commons-bsf/
>>> [2]
>>> https://github.com/wso2/wso2-synapse/blob/master/modules/extensions/src/main/java/org/apache/synapse/mediators/bsf/ScriptMediator.java
>>> : initScriptEngine() method
>>>
>>> Thanks,
>>> Maheeka
>>>
>>>
>>> Maheeka Jayasuriya
>>> Software Engineer
>>> Mobile : +9450661
>>>
>>> On Mon, Apr 11, 2016 at 12:55 PM, Prabath Ariyarathna <
>>> prabat...@wso2.com> wrote:
>>>
 @PrabathAR - Can you give us more details on this please?

 Inside Rhino engine, we can set optimization levels[1] which change the
 behavior of the engine. Default level is 0 and no optimizations are
 performed, but we can set this level in between -1 and 9 for the different
 optimizations. We can set this level to  -1 which Rhino switch into the
 interpreted mode, which means that it goes down to a different path for
 executing the code than it does in compiled mode. Interpreted mode is, of
 course, slower than compiled mode but improvement from the memory usage
 side[2].
 If we can give the optimization level in a configurable way we can
 overcome this issue.

 But +1 for adding new Rhino version if issue already fixed it in the
 later version. However we can check the possibility of adding configurable
 optimization levels.

 [1]
 https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/Optimization
 [2]
 http://stackoverflow.com/questions/14538541/performance-of-the-compiled-vs-interpreted-javascript-in-java7-rhino

 Thanks.

 On Mon, Apr 11, 2016 at 12:34 PM, Vanjikumaran Sivajothy <
 va...@wso2.com> wrote:

> With JDK 8, there is an in-build JS engine called Nashorn. Isn't that
> worth to leverage the JS support by using native implementation to JDK 8?
>
>
> [1]
> http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html
>
> On Sun, Apr 10, 2016 at 11:57 PM, Malaka Silva 
> wrote:
>
>> PrabathAR has already found a way to support this using existing
>> rhino version. There is a configuration to optimize the execution.
>>
>> @PrabathAR - Can you give us more details on this please?
>>
>> On Mon, Apr 11, 2016 at 12:22 PM, Nuwan Pallewela 
>> wrote:
>>
>>> Hi All,
>>>
>>> There is a limitation in wso2 script mediator when we try to
>>> manipulate payloads with JavaScript as the scripting language, when the
>>> Payload size is larger than 64KB, ESB throws an exception. Cause for 
>>> this
>>> is Rhino version which is used by the script mediator has a limitation 
>>> of
>>> handling JavaScript objects of size 64KB or more. But rhino have fixed 
>>> it
>>> in the later versions. So we can include new rhino and nashorn engines 
>>> as
>>> the script engine for JS in script mediator and avoid the limitation of
>>> handling larger payloads.
>>> Can we do this improvement to ESB 

Re: [Architecture] [C5] Artifact deployment coordination support for C5

[Susankha Nirmala]

Why we can't copy new artifacts (or updated  artifacts) to the deployment
directory of the carbon servers, running on the containers?

Thanks.
/Susankha.


On Thu, Apr 14, 2016 at 10:24 AM, Manuranga Perera  wrote:

>  K8S will only know about the container image that was used for the
>> deployment
>
> Ok, But form the image, don't we know what are the artifacts (since
> immutable servers)?
>
> On Thu, Apr 14, 2016 at 1:18 PM, Frank Leymann  wrote:
>
>> Sorry for jumping in so late in the thread:  is technology like HEAT/HOT
>> (OpenStack) or TOSCA (OASIS) too encompassing? I am happy to provide on
>> overview of their features...
>>
>> I am not suggesting to use the corresponding implementations (they have
>> their pros/cons) but we may learn from the concepts behind them.
>>
>>
>> Best regards,
>> Frank
>>
>> 2016-04-14 12:06 GMT+02:00 Imesh Gunaratne :
>>
>>>
>>>
>>> On Thu, Apr 14, 2016 at 1:35 AM, Manuranga Perera  wrote:
>>>
 If an existing artifact needs to be updated or new artifacts needs to
> be added a new container image needs to be created.

 In this case, why can't we ask from Kub how many pods with new artifact
 has been spun up? Why does this have to be updated at carbon kernel level
 via JMS?

>>>
>>> Carbon may not handle the rollout but it will need to inform an external
>>> entity the status of the deployed artifacts. K8S will only know about the
>>> container image that was used for the deployment, it will have no
>>> information on the artifacts deployed in the Carbon server.
>>>


 On Thu, Apr 7, 2016 at 2:38 PM, Imesh Gunaratne  wrote:

>
>
> On Thu, Apr 7, 2016 at 11:53 PM, Imesh Gunaratne 
> wrote:
>
>>
>> Hi Ruwan,
>>
>> On Thu, Mar 31, 2016 at 3:07 PM, Ruwan Abeykoon 
>> wrote:
>>
>>> Hi All,
>>> Do we really want artifact deployment coordination in C5?
>>> What is preventing us to build the new image with the new version of
>>> artifacts and let the k8s take care of deployment?
>>>
>>
>> You are absolutely correct! We may not do artifact synchronization in
>> C5 rather artifacts will get packaged into the containers.
>>
>
> I'm sorry C5 will also support none containerized deployments (VM,
> physical machines), still artifact synchronization will not be handled by
> Carbon.
>
> On Wed, Apr 6, 2016 at 8:03 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>>
>>
>> I've few concerns regarding artifact deployment coordination
>>  - Artifact versioning support. This is important to ensure
>> consistency across a cluster
>>
>
> Indded, but it may not relate to this feature I guess.
>
>
>>  - REST API to query the status. I'd rather go ahead with a REST API
>> before a JMS based implementation. IMO it's much simpler and easy to use.
>>
>
> A REST API might be needed in a different context, may be in a central
> monitoring server. In this context the design is to let servers publish
> their status to a central server. Otherwise it might not be feasible for a
> client to talk to each and every server and prepare the aggregated view.
>
>
>>  - Why don't we provide a REST API to deploy artifacts rather than
>> copying files (whenever applicable)? We can immediately notify the client
>> (via HTTP response status) whether artifact deployment was successful.
>>
>
> Might not be needed for container based deployments.
>
> Thanks
>
>
>> This feature is for monitoring the deployment status of the
>> artifacts. If an existing artifact needs to be updated or new artifacts
>> needs to be added a new container image needs to be created. Then a 
>> rollout
>> should be triggerred (depending on the container cluster management 
>> system
>> used).
>>
>> Thanks
>>
>>>
>>> Cheers,
>>> Ruwan
>>>
>>> On Wed, Mar 30, 2016 at 2:54 PM, Isuru Haththotuwa 
>>> wrote:
>>>
 Hi Kasun,

 On Wed, Mar 23, 2016 at 10:45 AM, KasunG Gajasinghe <
 kas...@wso2.com> wrote:

> Hi,
>
> Given several issues we discovered with automatic artifact
> synchronization with DepSync in C4, we have discussed how to approach 
> this
> problem in C5.
>
> We are thinking of not doing the automated artifact
> synchronization in C5. Rather, users should use their own mechanism to
> synchronize the artifacts across a cluster. Common approaches are 
> RSync as
> a cron job and shell scripts.
>
> But, it is vital to know the artifact deployment status of the
> nodes in the entire cluster from a central place. For 

[Architecture] WSO2 Identity Server 5.2.0 Beta Released

[Pushpalanka Jayawardhana]

WSO2 Identity Server 5.2.0 Beta Released !!!Date: 14th April 2016The WSO2
Identity Server team is pleased to announce the release of WSO2 Identity
Server 5.2.0 Beta. You can download this distribution from
https://github.com/wso2/product-is/releases/tag/v5.2.0-beta

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

~ The WSO2 Identity Server Team ~

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


Bugs

   - IDENTITY-4505 
   TenantDataManager string comparison error
   - IDENTITY-4502  Bug when
   SAMLSSOProviderServlet.sendResponse and
   SAMLSSOProviderServlet.sendRequestToFramework
   - IDENTITY-4490  Passive STS
   not working after opensaml upgrade
   - IDENTITY-4489  Conflict of
   commons-code versions in playground sample
   - IDENTITY-4487  Trying to
   select attributes during Policy creation leads to a blank page
   - IDENTITY-4484  A user can
   retrieve the authorization code even when plain challenge method is not
   supported
   - IDENTITY-4480  Need to
   upgrade neethi version from 2.0.4.wso2v4 to 2.0.4.wso2v5
   - IDENTITY-4479  PKCE code
   challenge is not generated when shifting between the challenge methods
   - IDENTITY-4478  Cannot
   retrieve the access token when PKCE is enabled
   - IDENTITY-4475 
   org.wso2.carbon.identity.workflow.mgt.bps.stub is missing in new extensions
   repo structure
   - IDENTITY-4474  Migration
   scripts for 5.2.0
   - IDENTITY-4472  Workflow
   Component should not rely on System properties for Mutual SSL Communication
   - IDENTITY-4466  Exception
   is logged in wso2carbon.log when the sts service is invoked.
   - IDENTITY-4465  Can't
   install "org.wso2.carbon.identity.provisioning.connector.salesforce.server"
   feature
   - IDENTITY-4462  A secondary
   user store is not listed under the Count Users domain
   - IDENTITY-4458  IWA carbon
   authenticator does not check disabled property in authenticators.xml
   - IDENTITY-4457  Cannot
   retrieve the count for matching filters - User Store Count functionality
   - IDENTITY-4448  Multiple
   roles are not returned in the SAML response - when service provider and the
   user are from different tenants
   - IDENTITY-4445  Remove
   dependency to org.wso2.carbon.identity.authenticator.saml2.sso from
   org.wso2.carbon.identity.sso.saml
   - IDENTITY-4439  Add remote
   user store feature into identity-userstore-remote repo
   - IDENTITY-4438 
   IDENTITY-3729 Add git revision to jar manifests
   - IDENTITY-4416  User info
   missing in id_token for implicit grant when requested claims are added
   - IDENTITY-4414  Add IDP UI
   not working
   - IDENTITY-4405  The default
   challenge questions are not displayed in account recovery page for tenant
   domain.
   - IDENTITY-4402  Updates
   done to a disabled user account are not saved even though a successful
   message is displayed to the user
   - IDENTITY-4400  Email
   generated says the account is disabled by Admin when it is disabled by a
   different user
   - IDENTITY-4399  Admin's
   account can be disabled and cannot be enabled again
   - IDENTITY-4397  NPE in SAML
   SSO for service provider registerd in tenant domain
   - IDENTITY-4387  Returning
   an array in sub-Claim on ID-Token
   - IDENTITY-4383  Custom
   Response Type Validator class is not read under SupportedGrantTypes in
   Identity.xml
   - IDENTITY-4381 
   NullPointerException could happen in 

Re: [Architecture] [C5] Artifact deployment coordination support for C5

[Manuranga Perera]

>
>  K8S will only know about the container image that was used for the
> deployment

Ok, But form the image, don't we know what are the artifacts (since
immutable servers)?

On Thu, Apr 14, 2016 at 1:18 PM, Frank Leymann  wrote:

> Sorry for jumping in so late in the thread:  is technology like HEAT/HOT
> (OpenStack) or TOSCA (OASIS) too encompassing? I am happy to provide on
> overview of their features...
>
> I am not suggesting to use the corresponding implementations (they have
> their pros/cons) but we may learn from the concepts behind them.
>
>
> Best regards,
> Frank
>
> 2016-04-14 12:06 GMT+02:00 Imesh Gunaratne :
>
>>
>>
>> On Thu, Apr 14, 2016 at 1:35 AM, Manuranga Perera  wrote:
>>
>>> If an existing artifact needs to be updated or new artifacts needs to
 be added a new container image needs to be created.
>>>
>>> In this case, why can't we ask from Kub how many pods with new artifact
>>> has been spun up? Why does this have to be updated at carbon kernel level
>>> via JMS?
>>>
>>
>> Carbon may not handle the rollout but it will need to inform an external
>> entity the status of the deployed artifacts. K8S will only know about the
>> container image that was used for the deployment, it will have no
>> information on the artifacts deployed in the Carbon server.
>>
>>>
>>>
>>> On Thu, Apr 7, 2016 at 2:38 PM, Imesh Gunaratne  wrote:
>>>


 On Thu, Apr 7, 2016 at 11:53 PM, Imesh Gunaratne 
 wrote:

>
> Hi Ruwan,
>
> On Thu, Mar 31, 2016 at 3:07 PM, Ruwan Abeykoon 
> wrote:
>
>> Hi All,
>> Do we really want artifact deployment coordination in C5?
>> What is preventing us to build the new image with the new version of
>> artifacts and let the k8s take care of deployment?
>>
>
> You are absolutely correct! We may not do artifact synchronization in
> C5 rather artifacts will get packaged into the containers.
>

 I'm sorry C5 will also support none containerized deployments (VM,
 physical machines), still artifact synchronization will not be handled by
 Carbon.

 On Wed, Apr 6, 2016 at 8:03 PM, Akila Ravihansa Perera <
 raviha...@wso2.com> wrote:
>
>
> I've few concerns regarding artifact deployment coordination
>  - Artifact versioning support. This is important to ensure
> consistency across a cluster
>

 Indded, but it may not relate to this feature I guess.


>  - REST API to query the status. I'd rather go ahead with a REST API
> before a JMS based implementation. IMO it's much simpler and easy to use.
>

 A REST API might be needed in a different context, may be in a central
 monitoring server. In this context the design is to let servers publish
 their status to a central server. Otherwise it might not be feasible for a
 client to talk to each and every server and prepare the aggregated view.


>  - Why don't we provide a REST API to deploy artifacts rather than
> copying files (whenever applicable)? We can immediately notify the client
> (via HTTP response status) whether artifact deployment was successful.
>

 Might not be needed for container based deployments.

 Thanks


> This feature is for monitoring the deployment status of the artifacts.
> If an existing artifact needs to be updated or new artifacts needs to be
> added a new container image needs to be created. Then a rollout should be
> triggerred (depending on the container cluster management system used).
>
> Thanks
>
>>
>> Cheers,
>> Ruwan
>>
>> On Wed, Mar 30, 2016 at 2:54 PM, Isuru Haththotuwa 
>> wrote:
>>
>>> Hi Kasun,
>>>
>>> On Wed, Mar 23, 2016 at 10:45 AM, KasunG Gajasinghe >> > wrote:
>>>
 Hi,

 Given several issues we discovered with automatic artifact
 synchronization with DepSync in C4, we have discussed how to approach 
 this
 problem in C5.

 We are thinking of not doing the automated artifact synchronization
 in C5. Rather, users should use their own mechanism to synchronize the
 artifacts across a cluster. Common approaches are RSync as a cron job 
 and
 shell scripts.

 But, it is vital to know the artifact deployment status of the
 nodes in the entire cluster from a central place. For that, we are
 providing this deployment coordination feature. There will be two ways 
 to
 use this.

 1. JMS based publishing - the deployment status will be published
 by each node to a jms topic/queue

 2. Log based publishing - publish the logs by using a syslog
 appender [1] or our own custom appender to a 

Re: [Architecture] [C5] Artifact deployment coordination support for C5

[Frank Leymann]

Sorry for jumping in so late in the thread:  is technology like HEAT/HOT
(OpenStack) or TOSCA (OASIS) too encompassing? I am happy to provide on
overview of their features...

I am not suggesting to use the corresponding implementations (they have
their pros/cons) but we may learn from the concepts behind them.


Best regards,
Frank

2016-04-14 12:06 GMT+02:00 Imesh Gunaratne :

>
>
> On Thu, Apr 14, 2016 at 1:35 AM, Manuranga Perera  wrote:
>
>> If an existing artifact needs to be updated or new artifacts needs to be
>>> added a new container image needs to be created.
>>
>> In this case, why can't we ask from Kub how many pods with new artifact
>> has been spun up? Why does this have to be updated at carbon kernel level
>> via JMS?
>>
>
> Carbon may not handle the rollout but it will need to inform an external
> entity the status of the deployed artifacts. K8S will only know about the
> container image that was used for the deployment, it will have no
> information on the artifacts deployed in the Carbon server.
>
>>
>>
>> On Thu, Apr 7, 2016 at 2:38 PM, Imesh Gunaratne  wrote:
>>
>>>
>>>
>>> On Thu, Apr 7, 2016 at 11:53 PM, Imesh Gunaratne  wrote:
>>>

 Hi Ruwan,

 On Thu, Mar 31, 2016 at 3:07 PM, Ruwan Abeykoon 
 wrote:

> Hi All,
> Do we really want artifact deployment coordination in C5?
> What is preventing us to build the new image with the new version of
> artifacts and let the k8s take care of deployment?
>

 You are absolutely correct! We may not do artifact synchronization in
 C5 rather artifacts will get packaged into the containers.

>>>
>>> I'm sorry C5 will also support none containerized deployments (VM,
>>> physical machines), still artifact synchronization will not be handled by
>>> Carbon.
>>>
>>> On Wed, Apr 6, 2016 at 8:03 PM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:


 I've few concerns regarding artifact deployment coordination
  - Artifact versioning support. This is important to ensure consistency
 across a cluster

>>>
>>> Indded, but it may not relate to this feature I guess.
>>>
>>>
  - REST API to query the status. I'd rather go ahead with a REST API
 before a JMS based implementation. IMO it's much simpler and easy to use.

>>>
>>> A REST API might be needed in a different context, may be in a central
>>> monitoring server. In this context the design is to let servers publish
>>> their status to a central server. Otherwise it might not be feasible for a
>>> client to talk to each and every server and prepare the aggregated view.
>>>
>>>
  - Why don't we provide a REST API to deploy artifacts rather than
 copying files (whenever applicable)? We can immediately notify the client
 (via HTTP response status) whether artifact deployment was successful.

>>>
>>> Might not be needed for container based deployments.
>>>
>>> Thanks
>>>
>>>
 This feature is for monitoring the deployment status of the artifacts.
 If an existing artifact needs to be updated or new artifacts needs to be
 added a new container image needs to be created. Then a rollout should be
 triggerred (depending on the container cluster management system used).

 Thanks

>
> Cheers,
> Ruwan
>
> On Wed, Mar 30, 2016 at 2:54 PM, Isuru Haththotuwa 
> wrote:
>
>> Hi Kasun,
>>
>> On Wed, Mar 23, 2016 at 10:45 AM, KasunG Gajasinghe 
>> wrote:
>>
>>> Hi,
>>>
>>> Given several issues we discovered with automatic artifact
>>> synchronization with DepSync in C4, we have discussed how to approach 
>>> this
>>> problem in C5.
>>>
>>> We are thinking of not doing the automated artifact synchronization
>>> in C5. Rather, users should use their own mechanism to synchronize the
>>> artifacts across a cluster. Common approaches are RSync as a cron job 
>>> and
>>> shell scripts.
>>>
>>> But, it is vital to know the artifact deployment status of the nodes
>>> in the entire cluster from a central place. For that, we are providing 
>>> this
>>> deployment coordination feature. There will be two ways to use this.
>>>
>>> 1. JMS based publishing - the deployment status will be published by
>>> each node to a jms topic/queue
>>>
>>> 2. Log based publishing - publish the logs by using a syslog
>>> appender [1] or our own custom appender to a central location.
>>>
>> Both are push mechanisms, IMHO we would need an API to check the
>> status of a deployed artifacts on demand, WDYT?
>>
>>>
>>> The log publishing may not be limited to just the deployment
>>> coordination. In a containerized deployment, the carbon products will 
>>> run
>>> in disposable containers. But sometimes, the logs need to be backed 

Re: [Architecture] [C5] Artifact deployment coordination support for C5

[Imesh Gunaratne]

On Thu, Apr 14, 2016 at 1:35 AM, Manuranga Perera  wrote:

> If an existing artifact needs to be updated or new artifacts needs to be
>> added a new container image needs to be created.
>
> In this case, why can't we ask from Kub how many pods with new artifact
> has been spun up? Why does this have to be updated at carbon kernel level
> via JMS?
>

Carbon may not handle the rollout but it will need to inform an external
entity the status of the deployed artifacts. K8S will only know about the
container image that was used for the deployment, it will have no
information on the artifacts deployed in the Carbon server.

>
>
> On Thu, Apr 7, 2016 at 2:38 PM, Imesh Gunaratne  wrote:
>
>>
>>
>> On Thu, Apr 7, 2016 at 11:53 PM, Imesh Gunaratne  wrote:
>>
>>>
>>> Hi Ruwan,
>>>
>>> On Thu, Mar 31, 2016 at 3:07 PM, Ruwan Abeykoon  wrote:
>>>
 Hi All,
 Do we really want artifact deployment coordination in C5?
 What is preventing us to build the new image with the new version of
 artifacts and let the k8s take care of deployment?

>>>
>>> You are absolutely correct! We may not do artifact synchronization in C5
>>> rather artifacts will get packaged into the containers.
>>>
>>
>> I'm sorry C5 will also support none containerized deployments (VM,
>> physical machines), still artifact synchronization will not be handled by
>> Carbon.
>>
>> On Wed, Apr 6, 2016 at 8:03 PM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>>
>>>
>>> I've few concerns regarding artifact deployment coordination
>>>  - Artifact versioning support. This is important to ensure consistency
>>> across a cluster
>>>
>>
>> Indded, but it may not relate to this feature I guess.
>>
>>
>>>  - REST API to query the status. I'd rather go ahead with a REST API
>>> before a JMS based implementation. IMO it's much simpler and easy to use.
>>>
>>
>> A REST API might be needed in a different context, may be in a central
>> monitoring server. In this context the design is to let servers publish
>> their status to a central server. Otherwise it might not be feasible for a
>> client to talk to each and every server and prepare the aggregated view.
>>
>>
>>>  - Why don't we provide a REST API to deploy artifacts rather than
>>> copying files (whenever applicable)? We can immediately notify the client
>>> (via HTTP response status) whether artifact deployment was successful.
>>>
>>
>> Might not be needed for container based deployments.
>>
>> Thanks
>>
>>
>>> This feature is for monitoring the deployment status of the artifacts.
>>> If an existing artifact needs to be updated or new artifacts needs to be
>>> added a new container image needs to be created. Then a rollout should be
>>> triggerred (depending on the container cluster management system used).
>>>
>>> Thanks
>>>

 Cheers,
 Ruwan

 On Wed, Mar 30, 2016 at 2:54 PM, Isuru Haththotuwa 
 wrote:

> Hi Kasun,
>
> On Wed, Mar 23, 2016 at 10:45 AM, KasunG Gajasinghe 
> wrote:
>
>> Hi,
>>
>> Given several issues we discovered with automatic artifact
>> synchronization with DepSync in C4, we have discussed how to approach 
>> this
>> problem in C5.
>>
>> We are thinking of not doing the automated artifact synchronization
>> in C5. Rather, users should use their own mechanism to synchronize the
>> artifacts across a cluster. Common approaches are RSync as a cron job and
>> shell scripts.
>>
>> But, it is vital to know the artifact deployment status of the nodes
>> in the entire cluster from a central place. For that, we are providing 
>> this
>> deployment coordination feature. There will be two ways to use this.
>>
>> 1. JMS based publishing - the deployment status will be published by
>> each node to a jms topic/queue
>>
>> 2. Log based publishing - publish the logs by using a syslog appender
>> [1] or our own custom appender to a central location.
>>
> Both are push mechanisms, IMHO we would need an API to check the
> status of a deployed artifacts on demand, WDYT?
>
>>
>> The log publishing may not be limited to just the deployment
>> coordination. In a containerized deployment, the carbon products will run
>> in disposable containers. But sometimes, the logs need to be backed up 
>> for
>> later reference. This will help with that.
>>
>> Any thoughts on this matter?
>>
>> [1]
>> https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender
>>
>> Thanks,
>> KasunG
>>
>>
>>
>> --
>> ~~--~~
>> Sending this mail via my phone. Do excuse any typo or short replies
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture