Re: [Dev] Recent changes causing errors in DB Scripts

[Dileesha Rajapakse]

   - MSSQL.sql Script caused following errors

Msg 128, Level 15, State 1, Line 5
The name "FALSE" is not permitted in this context. Valid expressions are
constants, constant expressions, and (in some contexts) variables. Column
names are not permitted.
Msg 156, Level 15, State 1, Line 409
Incorrect syntax near the keyword 'IF'.
Msg 156, Level 15, State 1, Line 426
Incorrect syntax near the keyword 'IF'.
Msg 156, Level 15, State 1, Line 450
Incorrect syntax near the keyword 'IF'.


On Tue, May 10, 2016 at 11:44 AM, Dileesha Rajapakse 
wrote:

> +dev@
>
> On Tue, May 10, 2016 at 11:38 AM, Dileesha Rajapakse 
> wrote:
>
>> Hi Guys,
>>
>> A bunch of errors found in MSSQL and Oracle DB scripts of the core due to
>> some recent changes.
>>
>> --
>> Dileesha Rajapakse
>> *Intern - Engineering*
>> Mobile : +94 (0) 772 555 933
>> Tel  : +94 112 741 505
>> dilee...@wso2.com
>>
>
>
>
> --
> Dileesha Rajapakse
> *Intern - Engineering*
> Mobile : +94 (0) 772 555 933
> Tel  : +94 112 741 505
> dilee...@wso2.com
>



-- 
Dileesha Rajapakse
*Intern - Engineering*
Mobile : +94 (0) 772 555 933
Tel  : +94 112 741 505
dilee...@wso2.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [GREG] Invalid value error for REG_CREATED_TIME column in REG_RESOURCE with mysql 5.7

[Janaka Ranabahu]

Hi Thushara

On Tue, May 10, 2016 at 12:06 PM, Thushara Ranawaka 
wrote:

> Hi Thilini,
>
> AFAIU you workaround need to be updated with the current timestamp[1][2].
> Setting default value to zero is not nice. You might have to figure out the
> correct syntax for other DB types and test against them.
>
​What Thilini is pointing is an issue in the Registry database creation
script. Hence we will create a public JIRA and assign it to you guys.
Please fix them.

We can not modify the Registry database creation script since API Manager
would not capture the complete scenarios of G-Reg.

Thanks,
Janaka​


>
>
> [1] - DEFAULT CURRENT_TIMESTAMP
> [2] -
> http://stackoverflow.com/questions/168736/how-do-you-set-a-default-value-for-a-mysql-datetime-column
>
> Thanks,
> Thushara.
>
> On Tue, May 10, 2016 at 11:52 AM, Thilini Cooray 
> wrote:
>
>> Hi GReg team,
>>
>> We encounter following issue [1] while testing API Manager with MySQL 5.7
>> MySQL 5.7 has enabled NO_ZERO_IN_DATE, NO_ZERO_DATE policies by default.
>> Therefore it does not allow 0 as a valid default value for date/time.
>>
>> As a workaround we can set MySQL server to accept 0 changing the default
>> server settings if the database owner agrees on it.
>> [2] contains the related table creation script.
>>
>> Appreciate your feedback on a fix for this.
>>
>> [1] https://wso2.org/jira/browse/APIMANAGER-4645
>>
>> [2] CREATE TABLE IF NOT EXISTS REG_RESOURCE (
>> REG_PATH_ID INTEGER NOT NULL,
>> REG_NAMEVARCHAR(256),
>> REG_VERSION INTEGER NOT NULL AUTO_INCREMENT,
>> REG_MEDIA_TYPE  VARCHAR(500),
>> REG_CREATOR VARCHAR(31) NOT NULL,
>> REG_CREATED_TIMETIMESTAMP NOT NULL *DEFAULT 0*,
>> REG_LAST_UPDATORVARCHAR(31),
>> REG_LAST_UPDATED_TIMETIMESTAMP NOT NULL *DEFAULT 0*,
>> REG_DESCRIPTION VARCHAR(1000),
>> REG_CONTENT_ID  INTEGER,
>> REG_TENANT_ID INTEGER DEFAULT 0,
>> REG_UUID VARCHAR(100) NOT NULL,
>> CONSTRAINT PK_REG_RESOURCE PRIMARY KEY(REG_VERSION,
>> REG_TENANT_ID)
>> )ENGINE INNODB;
>>
>> Thanks.
>>
>> --
>> Best Regards,
>>
>> *Thilini Cooray*
>> Software Engineer
>> Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194>
>> E-mail : thili...@wso2.com
>>
>> WSO2 Inc. www.wso2.com
>> lean.enterprise.middleware
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thanks,
> Thushara Kasun Ranawaka
> Software Engineer
> WSO2 Inc.; 
> lean.enterprise.middleware
> Mobile : *+94 (0) 773438949 <%2B94%20%280%29%20773438949>*
> *thusha...@wso2.com *
>



-- 
*Janaka Ranabahu*
Associate Technical Lead, WSO2 Inc.
http://wso2.com


*E-mail: jan...@wso2.com **M: **+94 718370861*

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

Re: [Dev] [GREG] Invalid value error for REG_CREATED_TIME column in REG_RESOURCE with mysql 5.7

[Thushara Ranawaka]

Hi Thilini,

AFAIU you workaround need to be updated with the current timestamp[1][2].
Setting default value to zero is not nice. You might have to figure out the
correct syntax for other DB types and test against them.


[1] - DEFAULT CURRENT_TIMESTAMP
[2] -
http://stackoverflow.com/questions/168736/how-do-you-set-a-default-value-for-a-mysql-datetime-column

Thanks,
Thushara.

On Tue, May 10, 2016 at 11:52 AM, Thilini Cooray  wrote:

> Hi GReg team,
>
> We encounter following issue [1] while testing API Manager with MySQL 5.7
> MySQL 5.7 has enabled NO_ZERO_IN_DATE, NO_ZERO_DATE policies by default.
> Therefore it does not allow 0 as a valid default value for date/time.
>
> As a workaround we can set MySQL server to accept 0 changing the default
> server settings if the database owner agrees on it.
> [2] contains the related table creation script.
>
> Appreciate your feedback on a fix for this.
>
> [1] https://wso2.org/jira/browse/APIMANAGER-4645
>
> [2] CREATE TABLE IF NOT EXISTS REG_RESOURCE (
> REG_PATH_ID INTEGER NOT NULL,
> REG_NAMEVARCHAR(256),
> REG_VERSION INTEGER NOT NULL AUTO_INCREMENT,
> REG_MEDIA_TYPE  VARCHAR(500),
> REG_CREATOR VARCHAR(31) NOT NULL,
> REG_CREATED_TIMETIMESTAMP NOT NULL *DEFAULT 0*,
> REG_LAST_UPDATORVARCHAR(31),
> REG_LAST_UPDATED_TIMETIMESTAMP NOT NULL *DEFAULT 0*,
> REG_DESCRIPTION VARCHAR(1000),
> REG_CONTENT_ID  INTEGER,
> REG_TENANT_ID INTEGER DEFAULT 0,
> REG_UUID VARCHAR(100) NOT NULL,
> CONSTRAINT PK_REG_RESOURCE PRIMARY KEY(REG_VERSION,
> REG_TENANT_ID)
> )ENGINE INNODB;
>
> Thanks.
>
> --
> Best Regards,
>
> *Thilini Cooray*
> Software Engineer
> Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194>
> E-mail : thili...@wso2.com
>
> WSO2 Inc. www.wso2.com
> lean.enterprise.middleware
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Thanks,
Thushara Kasun Ranawaka
Software Engineer
WSO2 Inc.; 
lean.enterprise.middleware
Mobile : *+94 (0) 773438949*
*thusha...@wso2.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [C5] BPS Server startup hangs after a NPE.

[Hasitha Aravinda]

Hi Kernel team,

I am getting following NPE when server startup. Please have a look.

[2016-05-10 11:52:55,080]  INFO
{org.wso2.msf4j.internal.MicroservicesServerSC} - All microservices are
available
[2016-05-10 11:52:55,081]  INFO
{org.wso2.carbon.transport.http.netty.internal.NettyTransportServiceComponent}
- All CarbonNettyServerInitializers are available
[2016-05-10 11:52:55,082]  INFO
{org.wso2.carbon.transport.http.netty.listener.NettyListener} - Starting
Netty Http Transport Listener
[2016-05-10 11:52:55,301]  INFO
{org.wso2.carbon.transport.http.netty.listener.NettyListener} - Netty
Listener starting on port 
[2016-05-10 11:52:55,302]  INFO
{org.wso2.carbon.transport.http.netty.listener.NettyListener} - Starting
Netty Http Transport Listener
[2016-05-10 11:52:55,352]  INFO
{org.wso2.carbon.transport.http.netty.listener.NettyListener} - Netty
Listener starting on port 
*Exception in thread "Timer-1" java.lang.NullPointerException*
at
org.wso2.carbon.kernel.internal.startupresolver.StartupOrderResolver$2.lambda$run$7(StartupOrderResolver.java:239)
at java.util.ArrayList.forEach(ArrayList.java:1249)
at
org.wso2.carbon.kernel.internal.startupresolver.StartupOrderResolver$2.run(StartupOrderResolver.java:236)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)


Thanks,
Hasitha.

-- 
--
Hasitha Aravinda,
Senior Software Engineer,
WSO2 Inc.
Email: hasi...@wso2.com
Mobile : +94 718 210 200
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [GREG] Invalid value error for REG_CREATED_TIME column in REG_RESOURCE with mysql 5.7

[Thilini Cooray]

Hi GReg team,

We encounter following issue [1] while testing API Manager with MySQL 5.7
MySQL 5.7 has enabled NO_ZERO_IN_DATE, NO_ZERO_DATE policies by default.
Therefore it does not allow 0 as a valid default value for date/time.

As a workaround we can set MySQL server to accept 0 changing the default
server settings if the database owner agrees on it.
[2] contains the related table creation script.

Appreciate your feedback on a fix for this.

[1] https://wso2.org/jira/browse/APIMANAGER-4645

[2] CREATE TABLE IF NOT EXISTS REG_RESOURCE (
REG_PATH_ID INTEGER NOT NULL,
REG_NAMEVARCHAR(256),
REG_VERSION INTEGER NOT NULL AUTO_INCREMENT,
REG_MEDIA_TYPE  VARCHAR(500),
REG_CREATOR VARCHAR(31) NOT NULL,
REG_CREATED_TIMETIMESTAMP NOT NULL *DEFAULT 0*,
REG_LAST_UPDATORVARCHAR(31),
REG_LAST_UPDATED_TIMETIMESTAMP NOT NULL *DEFAULT 0*,
REG_DESCRIPTION VARCHAR(1000),
REG_CONTENT_ID  INTEGER,
REG_TENANT_ID INTEGER DEFAULT 0,
REG_UUID VARCHAR(100) NOT NULL,
CONSTRAINT PK_REG_RESOURCE PRIMARY KEY(REG_VERSION,
REG_TENANT_ID)
)ENGINE INNODB;

Thanks.

-- 
Best Regards,

*Thilini Cooray*
Software Engineer
Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194>
E-mail : thili...@wso2.com

WSO2 Inc. www.wso2.com
lean.enterprise.middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Feature installation error with latest identity features

[Bhathiya Jayasekara]

Hi IS team,

We are experiencing this issue due to the restriction
[5.1.1.SNAPSHOT,6.0.0). Do you have a 5.1.1-SNAPSHOT version? Can you
please have a look? Please consider this urgent as our build if failing due
to this.

Installation failed.
Cannot complete the install because one or more required items could not be
found.
 Software being installed: BasicAuth Application Authenticator Server
Feature 5.0.9.SNAPSHOT
(org.wso2.carbon.identity.application.authenticator.basicauth.server.feature.group
5.0.9.SNAPSHOT)
 Missing requirement: BasicAuth Application Authenticator Server Feature
5.0.9.SNAPSHOT
(org.wso2.carbon.identity.application.authenticator.basicauth.server.feature.group
5.0.9.SNAPSHOT) requires
'org.wso2.carbon.identity.application.authentication.framework.server.feature.group
[5.1.1.SNAPSHOT,6.0.0)' but it could not be found

Thanks,
-- 
*Bhathiya Jayasekara*
*Senior Software Engineer,*
*WSO2 inc., http://wso2.com *

*Phone: +94715478185*
*LinkedIn: http://www.linkedin.com/in/bhathiyaj
*
*Twitter: https://twitter.com/bhathiyax *
*Blog: http://movingaheadblog.blogspot.com
*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [C5] Common directories to store DB scripts and databases for C5.

[Hasitha Aravinda]

Hi all,

I am bringing this topic, because we are using multiple place to store
dbscripts. In BPS we use  /dbscripts/bps folder to store scripts.
In carbon-security-user-store-jdbc, we use database folder. Shall we use
common place for this.

My suggestion is to use,

   - /dbscripts/(product | component name) to store DB scripts
   (Same location in C4)
   - /database or /resources/database to store
   file-system databases (h2) ?

Any thoughts ?

Thanks,
Hasitha.

-- 
--
Hasitha Aravinda,
Senior Software Engineer,
WSO2 Inc.
Email: hasi...@wso2.com
Mobile : +94 718 210 200
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] OOM Issues and HazelCast behaviour

[Ramith Jayasinghe]

HI Azeez/Sameera,

 Having encountered some OOM issues (relating to HZ) I looked at what
Hazelcast does in face of GC errors [1]. It will drop all connections,
threads, and shuts it self down.

Now, Think about one of our server's ( say MB) face a OOM and embedded HZ
instance shuts it self down. I propose when this happens entire server
should stop its processing intelligently ( if not shutting down).
Rational is one of the sub-system in the server shutdown while other parts
of the server don't care, which is wrong. As for MB, it tries to stop
processing in a meaningful manner and I argue this should be something any
server should do if they use HZ clustering.

thoughts?


[1]
https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/instance/DefaultOutOfMemoryHandler.java

-- 
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: ram...@wso2.com
P: +94 772534930
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

You do not have to add config data for each hierarchy. If you want to use
without any platform configuration then you can set the "platform" facter
variable to "default".

On Tue, May 10, 2016 at 9:54 AM, Lakmal Warusawithana 
wrote:

> Say platform k8s , we need to have vm_type right? I want to use vm_type
> docker , but without any platform configuration. How can I do that?
>
> On Tue, May 10, 2016 at 9:51 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Lakmal,
>>
>> Hierarchy will be the same (hiera.yaml). You need to set docker-compose
>> specific configuration in "vm_type/docker-compose.yaml" file. This is for
>> when building the image. Puppet cannot handle run time configuration in
>> container scenario. If there is no platform (Mesos, K8s etc.) involved then
>> no need to create platform specific yaml files.
>>
>> I think hiera.yaml should be abstract and flexible enough that a user
>> should be able to deploy WSO2 products/services on any platform or
>> container/VM type without changing it. Of course there can be custom
>> requirements. But this should suffice for most cases.
>>
>> Thanks.
>>
>> Thanks.
>>
>> On Tue, May 10, 2016 at 9:45 AM, Lakmal Warusawithana 
>> wrote:
>>
>>> Say I want to use in docker-compose (with pure docker). What hiera files
>>> (config) I have to use?
>>>
>>> On Tue, May 10, 2016 at 6:18 AM, Chamila De Alwis 
>>> wrote:
>>>
 I agree. Let's keep vm_type for simplicity.


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



 On Tue, May 10, 2016 at 6:15 AM, Akila Ravihansa Perera <
 raviha...@wso2.com> wrote:

> Hi Chamila,
>
> Docker is not really a platform if you look at the semantics. If we
> create another YAML for docker under platform hierarchy then we have to
> duplicate every platform specific YAML files under product hierarchy. I
> don't think it's a good option for us.
>
> Thanks.
>
> On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis 
> wrote:
>
>> Hi Akila,
>>
>> Why don't we use Docker as a platform rather than a vm_type? I'm not
>> sure about Rocket, however if there are no considerable data duplication
>> between Docker and a possible Rocket configuration data set, IMO we 
>> should
>> keep the hierarchy simple and include Docker as a platform. WDYT?
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> It seems "vm_type" hierarchy should exist to build Docker images
>>> (provisioned via Puppet) and then run on bare Docker. Because when 
>>> building
>>> the images for default platform (which is the option for bare Docker),
>>> there should be a separate hierarchy to set the installation_dir 
>>> parameter
>>> to "/mnt".
>>>
>>> I think it makes sense to have a separate hierarchy to control the
>>> configuration data for containers or VMs since that is one layer below 
>>> the
>>> platform level in a deployment infrastructure. For eg: we can have a
>>> Kubernetes platform with Docker as the container technology OR it could 
>>> be
>>> even Rocket. Inside this whatever vm_type we can have any base operating
>>> system running. So I've refined the hierarchy as follows;
>>>
>>> :hierarchy:
>>> - "node/%{::clientcert}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>>> - "osfamily/%{::osfamily}"
>>> - "vm_type/%{::vm_type}"
>>> - "platform/%{::platform}"
>>> - wso2/common
>>> - common
>>> :backends:
>>> - yaml
>>> :yaml:
>>> :datadir: "hieradata/%{::environment}"
>>>
>>> Since "wso2/common" and "common" are static hierarchies, those
>>> should be moved to the bottom. Please raise any concerns you may have 
>>> with
>>> this hierarchy.
>>>
>>> Thanks.
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis >> > wrote:
>>>
 +1, IMO that's better since now it's clear how what kubernetes.yaml
 stands for.


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



 On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
 raviha...@wso2.com> wrote:

> Hi Chamila,
>
> Agre

Re: [Dev] Developer Studio Server Modification to add Product based Servers

[Awanthika Senarath]

Hello all,

We have completed $subject as an improvement for user experience as follows,

We have enabled dynamic extension point generation in Developer Studio, we
retrieve the Specific display name from the product plugins when they
register their servers as given in the following example :

* *
* http://server.display.name>="WSO2 ESB
Server 3.3">*
* *
*  http://server.display.name>="WSO2 CEP
Server 3.9">*
* *
* http://server.display.name>="WSO2 ESB
Server 3.7">*
* *
*  http://server.display.name>="WSO2 CEP
Server 3.0">*
* *
* http://server.display.name>="WSO2 ESB
Server 3.0">*
* *
*  http://server.display.name>="WSO2 CEP
Server 3.2">*
* *
*  *


The product server can decide which versions of their servers they plan to
support from their tooling versions released.

*We will be removing the previous support we had for integrating servers
based on the carbon versions, hence it is mandatory that product teams
include these servers versions in their tooling plugins, in the plugin xml
as described above.*

Also note that the carbon.server.version should contain one of
carbon.server.40
carbon.server.42
carbon.server.44

as Developer Studio Kernel 4.1.0 we are only going to follow those carbon
versions, If you mention any String other than what is given the extension
point will be ignored by kernel.

Adopted Approach :


​

*@ Jasintha / Susinda/ Viraj :* Currently this server retrieval from
product plugins is bind to Developer Studio Dashboard opening action, since
we are accessing WSO2 servers from the dashboard. We need to configure this
in an Eclipse generic startup method if we are to display these servers in
show view -> servers option via eclipse menu.
Since eclipse discourages usage of early startups IMO it is OK to display
the servers only via the dashboard server option.

WDYT ?


[1] Associated Jira : https://wso2.org/jira/browse/DEVTOOLPFM-1

Awanthika Senarath
Software Engineer, WSO2 Inc.
Mobile: +94717681791
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Error while implementing the Integration test for salesforce(SOAP API) connector

[Hariprasath Thanarajah]

Hi Malaka,

As an offline chat with Buddhima,
if a certain version of automation frame work needs a certain axis2
version, then there should be a release version of automation framework
along with that axis2.

On Mon, May 9, 2016 at 9:56 AM, Hariprasath Thanarajah  wrote:

> Noted malaka.
>
>
> On Monday, May 9, 2016, Malaka Silva  wrote:
>
>> I think this is nothing to do with wso2-synapse. You need to change
>> automation framework accordingly.
>>
>> On Mon, May 9, 2016 at 9:48 AM, Hariprasath Thanarajah <
>> haripras...@wso2.com> wrote:
>>
>>> Yes Malaka. I think we have to change the axis2 version to 1.6.1-wso2v17
>>> in the wso2-synapse. Then we can release the connector with integration
>>> test.
>>>
>>>
>>> On Monday, May 9, 2016, Malaka Silva  wrote:
>>>
 Hi Hariprasath,

 So clearly this is nothing to do with ESB. Dependency you are getting
 from automation is causing this issue.

 On Sun, May 8, 2016 at 10:01 PM, Hariprasath Thanarajah <
 haripras...@wso2.com> wrote:

> Hi Malaka,
>
> In the integration test It takes the axis2-version from wso2-synapse
> according to[1]. But still the version of axis2 in wso2-synapse is
> 1.6.1-wso2v12 according to [2]. When I locally change the version to 
> axis2-1.6.1-wso2v17
> and built then the integration test for salesforce is running as we
> expected.
>
> [1] -
> https://github.com/wso2-extensions/esb-connector-salesforce/blob/master/pom.xml#L34
> [2] - https://github.com/wso2/wso2-synapse/blob/master/pom.xml#L1003
>
> On Fri, May 6, 2016 at 9:49 AM, Malaka Silva  wrote:
>
>> Hi Hariprasath,
>>
>> I had an offline discussion with Dharshana. Seems like the issue is
>> related the a mismatch and it takes the bundle from aytomation framework
>> rather than from esb plugins.
>>
>> Since the issue is not related to ESB 5, send the pr so that we can
>> resolve the issue. (Anyway we need to update the version in product ESB)
>>
>> Try upgrading the automation version or manually adding the 
>> axis2-1.6.1-wso2v17 dependency to
>> test run time.
>>
>> On Tue, May 3, 2016 at 1:31 PM, Hariprasath Thanarajah <
>> haripras...@wso2.com> wrote:
>>
>>> Noted Malaka.
>>>
>>> On Tue, May 3, 2016 at 1:05 PM, Malaka Silva 
>>> wrote:
>>>
 Hariprasath great if you could create the pr(master branch) and add
 to the jira.

 On Tue, May 3, 2016 at 1:02 PM, Hariprasath Thanarajah <
 haripras...@wso2.com> wrote:

> Hi Malaka/Chanaka,
>
> The axis2-1.6.1-wso2v17 is bundled with ESB 5.0.0 Alpha but For
> the integration test it takes axis2-1.6.1-wso2v12 from the 
> highlighted in
> [1].
>
> This is required for Salesforce integration test. We need to get
> it fix in BETA release.
>
> [1] -
> https://github.com/wso2/product-esb/blob/v5.0.0-ALPHA/pom.xml#L1064
>
> Thanks,
>
> On Tue, May 3, 2016 at 12:09 PM, Malaka Silva 
> wrote:
>
>> Hi Hariprasath,
>>
>> Can we verify the [1] fix is there with ESB 5.0.0 alpha please?
>>
>> [1] https://github.com/wso2/wso2-axis2/pull/73
>>
>> On Mon, May 2, 2016 at 11:16 PM, Chanaka Fernando <
>> chana...@wso2.com> wrote:
>>
>>> Hi Hariprasath,
>>>
>>> ESB 5.0.0 - Alpha has been released with the axis2 version
>>> 1.6.1.wso2v17 (kernel 4.4.5) and it should have this fix included. 
>>> Please
>>> double check this on the correct alpha pack.
>>>
>>> On Mon, May 2, 2016 at 12:12 PM, Malaka Silva 
>>> wrote:
>>>
 Thx

 On Mon, May 2, 2016 at 12:11 PM, Hariprasath Thanarajah <
 haripras...@wso2.com> wrote:

> Hi Malaka,
>
> I have created the jira[1] with highest priority,
>
> [1]
> https://wso2.org/jira/browse/ESBJAVA-4582
>
> On Mon, May 2, 2016 at 11:31 AM, Malaka Silva  > wrote:
>
>> Hi Hariprasath,
>>
>> Ideally fix should go with latest ESB. If you find the same
>> issue with ESB 5 Alpha, please report a jira with highest 
>> priority.
>>
>> On Mon, May 2, 2016 at 11:25 AM, Hariprasath Thanarajah <
>> haripras...@wso2.com> wrote:
>>
>>> Hi Malaka,
>>>
>>> I have changed the code in wso2-axis2 according to [1] and
>>> put it as a patch. Now it's working perfectly. Thank you 
>>> everyone for your
>>> suggestions.
>>>
>>> [1]
>>> https://github.com/ws

Re: [Dev] [DEV][Puppet Modules] Finalizing wso2/puppet-modules 2.0.0 release

[Anuruddha Liyanarachchi]

Hi,

Please find the node port ranges used in puppet modules. We should add this
to wiki.

Product
Port Range
Min Port Max Port
wso2am 32000 32020
wso2as 32021 32030
wso2bps 32031 32040
wso2brs 32041 32050
wso2cep 32051 32060
wso2das 32061 32070
wso2dss 32071 32080
wso2es 32081 32090
wso2esb 32091 32100
wso2greg 32101 32110
wso2is 32110 32120
wso2mb 32120 32130



On Tue, May 10, 2016 at 6:19 AM, Chamila De Alwis  wrote:

> Hi Akila,
>
> On Tue, May 10, 2016 at 6:14 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> WARNING: class inherits across module namespaces
>> WARNING: line has more than 80 characters
>>
>
> I think we can ignore these as they were considered in the decision
> process. I'll change the release notes to amend the line about vm_type.
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Thanks and Regards,*
Anuruddha Lanka Liyanarachchi
Software Engineer - WSO2
Mobile : +94 (0) 712762611
Tel  : +94 112 145 345
a nurudd...@wso2.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DAS] Starting DAS gives an error when secure vault enabled

[Amalka Subasinghe]

HI Inosh,

I tried again, it worked. But not sure what was wrong in my configurations.

Thanks
Amlaka

On Tue, May 10, 2016 at 9:44 AM, Inosh Goonewardena  wrote:

> Hi Amalka,
>
> Could you please try this again? I checked this and it worked without any
> issues. I think this might be some configuration issue happen when
> configuring Secure vault.
>
> On Tue, May 10, 2016 at 8:49 AM, Amalka Subasinghe 
> wrote:
>
>> Hi,
>>
>> Steps to reproduce.
>>
>> 1. Get DAS 3.0.1 vanilla pack.
>>
>> 2. Enable secure vault as follows
>>
>> a. added the following line to the
>> wso2das-3.0.1/repository/conf/security/cipher-tool.properties file
>>
>> Datasources.WSO2_ANALYTICS_EVENT_STORE_DB.Configuration.Password=repository/conf/datasources/analytics-datasources.xml//datasources-configuration/datasources/datasource[name='WSO2_ANALYTICS_EVENT_STORE_DB']/definition[@type='RDBMS']/configuration/password,true
>>
>> b. Added the following line to the
>> wso2das-3.0.1/repository/conf/security/cipher-text.properties file
>>
>> Datasources.WSO2_ANALYTICS_EVENT_STORE_DB.Configuration.Password=[wso2carbon]
>>
>> c. Go to wso2das-3.0.1/bin, run ./ciphertool.sh -Dconfigure
>>
>> d. Now the datasource config is as follows
>>
>> 
>> WSO2_ANALYTICS_EVENT_STORE_DB
>> The datasource used for analytics record
>> store
>> 
>> 
>>
>> jdbc:h2:repository/database/ANALYTICS_EVENT_STORE;AUTO_SERVER=TRUE;DB_CLOSE_ON_EXIT=FALSE;LOCK_TIMEOUT=6
>> wso2carbon
>> > svns:secretAlias="Datasources.WSO2_ANALYTICS_EVENT_STORE_DB.Configuration.Password">password
>> org.h2.Driver
>> 50
>> 6
>> SELECT 1
>> false
>> 0
>> true
>>
>> 4000
>> 
>> 
>> 
>>
>> 3. Start the DAS - this will give following error
>>
>> [2016-05-10 08:36:18,622] ERROR
>> {org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceComponent}
>> -  Error in activating analytics data service: Error in looking up database
>> type: Wrong user name or password [8004-140]
>> org.wso2.carbon.analytics.datasource.commons.exception.AnalyticsException:
>> Error in looking up database type: Wrong user name or password [8004-140]
>> at
>> org.wso2.carbon.analytics.datasource.rdbms.RDBMSUtils.lookupDatabaseInfo(RDBMSUtils.java:73)
>> at
>> org.wso2.carbon.analytics.datasource.rdbms.RDBMSUtils.lookupCurrentQueryConfigurationEntry(RDBMSUtils.java:89)
>> at
>> org.wso2.carbon.analytics.datasource.rdbms.RDBMSAnalyticsRecordStore.init(RDBMSAnalyticsRecordStore.java:83)
>> at
>> org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceImpl.initARS(AnalyticsDataServiceImpl.java:263)
>> at
>> org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceImpl.(AnalyticsDataServiceImpl.java:123)
>> at
>> org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceComponent.activate(AnalyticsDataServiceComponent.java:63)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>> at
>> org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:260)
>> at
>> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:146)
>> at
>> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:345)
>> at
>> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:620)
>> at
>> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:197)
>> at
>> org.eclipse.equinox.internal.ds.Resolver.getEligible(Resolver.java:343)
>> at
>> org.eclipse.equinox.internal.ds.SCRManager.serviceChanged(SCRManager.java:222)
>> at
>> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
>> at
>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
>> at
>> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
>> at
>> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
>> at
>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
>> at
>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:771)
>> at
>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130)
>> at
>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Lakmal Warusawithana]

Say platform k8s , we need to have vm_type right? I want to use vm_type
docker , but without any platform configuration. How can I do that?

On Tue, May 10, 2016 at 9:51 AM, Akila Ravihansa Perera 
wrote:

> Hi Lakmal,
>
> Hierarchy will be the same (hiera.yaml). You need to set docker-compose
> specific configuration in "vm_type/docker-compose.yaml" file. This is for
> when building the image. Puppet cannot handle run time configuration in
> container scenario. If there is no platform (Mesos, K8s etc.) involved then
> no need to create platform specific yaml files.
>
> I think hiera.yaml should be abstract and flexible enough that a user
> should be able to deploy WSO2 products/services on any platform or
> container/VM type without changing it. Of course there can be custom
> requirements. But this should suffice for most cases.
>
> Thanks.
>
> Thanks.
>
> On Tue, May 10, 2016 at 9:45 AM, Lakmal Warusawithana 
> wrote:
>
>> Say I want to use in docker-compose (with pure docker). What hiera files
>> (config) I have to use?
>>
>> On Tue, May 10, 2016 at 6:18 AM, Chamila De Alwis 
>> wrote:
>>
>>> I agree. Let's keep vm_type for simplicity.
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Tue, May 10, 2016 at 6:15 AM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
 Hi Chamila,

 Docker is not really a platform if you look at the semantics. If we
 create another YAML for docker under platform hierarchy then we have to
 duplicate every platform specific YAML files under product hierarchy. I
 don't think it's a good option for us.

 Thanks.

 On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis 
 wrote:

> Hi Akila,
>
> Why don't we use Docker as a platform rather than a vm_type? I'm not
> sure about Rocket, however if there are no considerable data duplication
> between Docker and a possible Rocket configuration data set, IMO we should
> keep the hierarchy simple and include Docker as a platform. WDYT?
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> It seems "vm_type" hierarchy should exist to build Docker images
>> (provisioned via Puppet) and then run on bare Docker. Because when 
>> building
>> the images for default platform (which is the option for bare Docker),
>> there should be a separate hierarchy to set the installation_dir 
>> parameter
>> to "/mnt".
>>
>> I think it makes sense to have a separate hierarchy to control the
>> configuration data for containers or VMs since that is one layer below 
>> the
>> platform level in a deployment infrastructure. For eg: we can have a
>> Kubernetes platform with Docker as the container technology OR it could 
>> be
>> even Rocket. Inside this whatever vm_type we can have any base operating
>> system running. So I've refined the hierarchy as follows;
>>
>> :hierarchy:
>> - "node/%{::clientcert}"
>> - 
>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>> - "osfamily/%{::osfamily}"
>> - "vm_type/%{::vm_type}"
>> - "platform/%{::platform}"
>> - wso2/common
>> - common
>> :backends:
>> - yaml
>> :yaml:
>> :datadir: "hieradata/%{::environment}"
>>
>> Since "wso2/common" and "common" are static hierarchies, those should
>> be moved to the bottom. Please raise any concerns you may have with this
>> hierarchy.
>>
>> Thanks.
>>
>>
>>
>> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis 
>> wrote:
>>
>>> +1, IMO that's better since now it's clear how what kubernetes.yaml
>>> stands for.
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
 Hi Chamila,

 Agreed. I don't think there would be anymore files in addition to
 common.yaml here. How about moving this to root level; for eg:
 "platform/kubernetes.yaml" ?

 Full Hierarchy will be as follows;

 :hierarchy:
 - "node/%{::clientcert}"
 - 
 "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
 - 
 "w

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

Hi Lakmal,

Hierarchy will be the same (hiera.yaml). You need to set docker-compose
specific configuration in "vm_type/docker-compose.yaml" file. This is for
when building the image. Puppet cannot handle run time configuration in
container scenario. If there is no platform (Mesos, K8s etc.) involved then
no need to create platform specific yaml files.

I think hiera.yaml should be abstract and flexible enough that a user
should be able to deploy WSO2 products/services on any platform or
container/VM type without changing it. Of course there can be custom
requirements. But this should suffice for most cases.

Thanks.

Thanks.

On Tue, May 10, 2016 at 9:45 AM, Lakmal Warusawithana 
wrote:

> Say I want to use in docker-compose (with pure docker). What hiera files
> (config) I have to use?
>
> On Tue, May 10, 2016 at 6:18 AM, Chamila De Alwis 
> wrote:
>
>> I agree. Let's keep vm_type for simplicity.
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Tue, May 10, 2016 at 6:15 AM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi Chamila,
>>>
>>> Docker is not really a platform if you look at the semantics. If we
>>> create another YAML for docker under platform hierarchy then we have to
>>> duplicate every platform specific YAML files under product hierarchy. I
>>> don't think it's a good option for us.
>>>
>>> Thanks.
>>>
>>> On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis 
>>> wrote:
>>>
 Hi Akila,

 Why don't we use Docker as a platform rather than a vm_type? I'm not
 sure about Rocket, however if there are no considerable data duplication
 between Docker and a possible Rocket configuration data set, IMO we should
 keep the hierarchy simple and include Docker as a platform. WDYT?


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



 On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
 raviha...@wso2.com> wrote:

> Hi,
>
> It seems "vm_type" hierarchy should exist to build Docker images
> (provisioned via Puppet) and then run on bare Docker. Because when 
> building
> the images for default platform (which is the option for bare Docker),
> there should be a separate hierarchy to set the installation_dir parameter
> to "/mnt".
>
> I think it makes sense to have a separate hierarchy to control the
> configuration data for containers or VMs since that is one layer below the
> platform level in a deployment infrastructure. For eg: we can have a
> Kubernetes platform with Docker as the container technology OR it could be
> even Rocket. Inside this whatever vm_type we can have any base operating
> system running. So I've refined the hierarchy as follows;
>
> :hierarchy:
> - "node/%{::clientcert}"
> - 
> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
> - "osfamily/%{::osfamily}"
> - "vm_type/%{::vm_type}"
> - "platform/%{::platform}"
> - wso2/common
> - common
> :backends:
> - yaml
> :yaml:
> :datadir: "hieradata/%{::environment}"
>
> Since "wso2/common" and "common" are static hierarchies, those should
> be moved to the bottom. Please raise any concerns you may have with this
> hierarchy.
>
> Thanks.
>
>
>
> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis 
> wrote:
>
>> +1, IMO that's better since now it's clear how what kubernetes.yaml
>> stands for.
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi Chamila,
>>>
>>> Agreed. I don't think there would be anymore files in addition to
>>> common.yaml here. How about moving this to root level; for eg:
>>> "platform/kubernetes.yaml" ?
>>>
>>> Full Hierarchy will be as follows;
>>>
>>> :hierarchy:
>>> - "node/%{::clientcert}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>>> - "platform/%{::platform}"
>>> - "osfamily/%{::osfamily}"
>>> - wso2/common
>>> - common
>>> :backends:
>>> - yaml
>>> :yaml:
>>> :datadir: "hieradata/%{::environment}"
>>>
>>>
>>> Thanks.
>>>
>>>
>>> On Mon, May 9, 2016 at 11:31 AM, Ch

[Dev] Fwd: Why we Keep older versions in the new Releases?

[Hariprasath Thanarajah]

Hi All,

In every release of our product we didn't upgrade the dependency versions
in the pom file. For example take wso2-synapse and wso2-axis2. The new
released version of axis2 according to [1] is v1.6.1-wso2v17 and
wso2-synapse is 2.1.7-wso2v3-ALPHA. But in the synapse still the version of
axis2 according to [2] is v1.6.1-wso2v12. Is there any particular reason to
keep the older version in the new release? I think we need to check with
latest releases before releasing a new version of product. When we using
the older versions in the new releases we didn't get the new changes from
those dependencies.

correct If I am wrong.

[1] - https://github.com/wso2/wso2-axis2/blob/v1.6.1-wso2v17/pom.xml#L31
[2] -
https://github.com/wso2/wso2-synapse/blob/v2.1.7-wso2v3-ALPHA/pom.xml#L1003



-- 


*Thank you and Regards**Hariprasath Thanarajah*
Associate Software Engineer | WSO2
E: haripras...@wso2.com
M: +94752806528, 0777216903
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Lakmal Warusawithana]

Say I want to use in docker-compose (with pure docker). What hiera files
(config) I have to use?

On Tue, May 10, 2016 at 6:18 AM, Chamila De Alwis  wrote:

> I agree. Let's keep vm_type for simplicity.
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Tue, May 10, 2016 at 6:15 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Chamila,
>>
>> Docker is not really a platform if you look at the semantics. If we
>> create another YAML for docker under platform hierarchy then we have to
>> duplicate every platform specific YAML files under product hierarchy. I
>> don't think it's a good option for us.
>>
>> Thanks.
>>
>> On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis 
>> wrote:
>>
>>> Hi Akila,
>>>
>>> Why don't we use Docker as a platform rather than a vm_type? I'm not
>>> sure about Rocket, however if there are no considerable data duplication
>>> between Docker and a possible Rocket configuration data set, IMO we should
>>> keep the hierarchy simple and include Docker as a platform. WDYT?
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
 Hi,

 It seems "vm_type" hierarchy should exist to build Docker images
 (provisioned via Puppet) and then run on bare Docker. Because when building
 the images for default platform (which is the option for bare Docker),
 there should be a separate hierarchy to set the installation_dir parameter
 to "/mnt".

 I think it makes sense to have a separate hierarchy to control the
 configuration data for containers or VMs since that is one layer below the
 platform level in a deployment infrastructure. For eg: we can have a
 Kubernetes platform with Docker as the container technology OR it could be
 even Rocket. Inside this whatever vm_type we can have any base operating
 system running. So I've refined the hierarchy as follows;

 :hierarchy:
 - "node/%{::clientcert}"
 - 
 "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
 - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
 - "osfamily/%{::osfamily}"
 - "vm_type/%{::vm_type}"
 - "platform/%{::platform}"
 - wso2/common
 - common
 :backends:
 - yaml
 :yaml:
 :datadir: "hieradata/%{::environment}"

 Since "wso2/common" and "common" are static hierarchies, those should
 be moved to the bottom. Please raise any concerns you may have with this
 hierarchy.

 Thanks.



 On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis 
 wrote:

> +1, IMO that's better since now it's clear how what kubernetes.yaml
> stands for.
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Chamila,
>>
>> Agreed. I don't think there would be anymore files in addition to
>> common.yaml here. How about moving this to root level; for eg:
>> "platform/kubernetes.yaml" ?
>>
>> Full Hierarchy will be as follows;
>>
>> :hierarchy:
>> - "node/%{::clientcert}"
>> - 
>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>> - "platform/%{::platform}"
>> - "osfamily/%{::osfamily}"
>> - wso2/common
>> - common
>> :backends:
>> - yaml
>> :yaml:
>> :datadir: "hieradata/%{::environment}"
>>
>>
>> Thanks.
>>
>>
>> On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis 
>> wrote:
>>
>>> +1
>>>
>>> How about wso2/kubernetes.yaml instead of
>>> wso2/kubernetes/common.yaml? Will there be a YAML file in addition to 
>>> the
>>> common.yaml?
>>>
>>> - "wso2/%{::platform}"
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
 Hi,

 We recently introduced a facter named "platform" to denote a PaaS
 framework or cluster management system on which WSO2 products could be
 deployed. With this addition I feel there is no reason to keep -
 "vm_typ

Re: [Dev] [DAS] Starting DAS gives an error when secure vault enabled

[Inosh Goonewardena]

Hi Amalka,

Could you please try this again? I checked this and it worked without any
issues. I think this might be some configuration issue happen when
configuring Secure vault.

On Tue, May 10, 2016 at 8:49 AM, Amalka Subasinghe  wrote:

> Hi,
>
> Steps to reproduce.
>
> 1. Get DAS 3.0.1 vanilla pack.
>
> 2. Enable secure vault as follows
>
> a. added the following line to the
> wso2das-3.0.1/repository/conf/security/cipher-tool.properties file
>
> Datasources.WSO2_ANALYTICS_EVENT_STORE_DB.Configuration.Password=repository/conf/datasources/analytics-datasources.xml//datasources-configuration/datasources/datasource[name='WSO2_ANALYTICS_EVENT_STORE_DB']/definition[@type='RDBMS']/configuration/password,true
>
> b. Added the following line to the
> wso2das-3.0.1/repository/conf/security/cipher-text.properties file
>
> Datasources.WSO2_ANALYTICS_EVENT_STORE_DB.Configuration.Password=[wso2carbon]
>
> c. Go to wso2das-3.0.1/bin, run ./ciphertool.sh -Dconfigure
>
> d. Now the datasource config is as follows
>
> 
> WSO2_ANALYTICS_EVENT_STORE_DB
> The datasource used for analytics record
> store
> 
> 
>
> jdbc:h2:repository/database/ANALYTICS_EVENT_STORE;AUTO_SERVER=TRUE;DB_CLOSE_ON_EXIT=FALSE;LOCK_TIMEOUT=6
> wso2carbon
>  svns:secretAlias="Datasources.WSO2_ANALYTICS_EVENT_STORE_DB.Configuration.Password">password
> org.h2.Driver
> 50
> 6
> SELECT 1
> false
> 0
> true
>
> 4000
> 
> 
> 
>
> 3. Start the DAS - this will give following error
>
> [2016-05-10 08:36:18,622] ERROR
> {org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceComponent}
> -  Error in activating analytics data service: Error in looking up database
> type: Wrong user name or password [8004-140]
> org.wso2.carbon.analytics.datasource.commons.exception.AnalyticsException:
> Error in looking up database type: Wrong user name or password [8004-140]
> at
> org.wso2.carbon.analytics.datasource.rdbms.RDBMSUtils.lookupDatabaseInfo(RDBMSUtils.java:73)
> at
> org.wso2.carbon.analytics.datasource.rdbms.RDBMSUtils.lookupCurrentQueryConfigurationEntry(RDBMSUtils.java:89)
> at
> org.wso2.carbon.analytics.datasource.rdbms.RDBMSAnalyticsRecordStore.init(RDBMSAnalyticsRecordStore.java:83)
> at
> org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceImpl.initARS(AnalyticsDataServiceImpl.java:263)
> at
> org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceImpl.(AnalyticsDataServiceImpl.java:123)
> at
> org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceComponent.activate(AnalyticsDataServiceComponent.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:260)
> at
> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:146)
> at
> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:345)
> at
> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:620)
> at
> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:197)
> at
> org.eclipse.equinox.internal.ds.Resolver.getEligible(Resolver.java:343)
> at
> org.eclipse.equinox.internal.ds.SCRManager.serviceChanged(SCRManager.java:222)
> at
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
> at
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:771)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:214)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:433)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:451)
> at
> 

Re: [Dev] [Docker][Puppet] [MB] Setting 'thriftServerHost' in WSO2 MB broker.xml file

[Thanuja Uruththirakodeeswaran]

Hi All,

I have added the custom extension to wso2mb puppet module through
'system_file_list' method.

Like we used file_list to copy files to wso2 carbon home, we can copy files
which are added */files/system* to system using *system_file_list
*as below:

wso2::system_file_list:
  -
file: 
target_path: 


I used the above approach to fix the MB thrift server issue.  Added
wso2mb-default-init.sh extension script to wso2mb/files/system and copied
to /usr/local/bin path using system_file_list as below:

wso2::system_file_list:
  -
file: wso2mb-default-init.sh
target_path: /usr/local/bin



Thanks.


On Mon, May 9, 2016 at 2:07 PM, Thanuja Uruththirakodeeswaran <
thanu...@wso2.com> wrote:

> Hi All,
>
> Thanks for the suggestions !!! As Isuru suggested, the best approach would
> be to use an extension point to update thriftServerHost with container
> ip. Will go with this approach.
>
> Thanks.
>
> On Mon, May 9, 2016 at 2:01 PM, Akila Ravihansa Perera  > wrote:
>
>> Hi Pumudu,
>>
>> We can't use "%{::ipaddress}" in kubernetes platform since Puppet is
>> only used to build the Docker images. The ipaddress is assigned when the
>> Kubernetes pods/services are deployed.
>>
>> I think best method would be to use the extension point as explained by
>> Isuru. This should be similar to how we replace the localMemberHost section
>> in axis2.xml.
>>
>> Thanks.
>>
>> On Mon, May 9, 2016 at 1:34 PM, Pumudu Ruhunage  wrote:
>>
>>> Hi,
>>> AFAIU, Thrift hostname should be changed to IP from puppet modules when
>>> configuring hiera data[1]. Following line[2] should added to
>>> default.yaml[3] to get the IP when initializing.
>>>
>>> [1]
>>> https://github.com/wso2/puppet-modules/wiki/Creating-a-Puppet-Module-for-a-WSO2-Product#create-the-hiera-configuration-data-set
>>> [2] wso2::mb_thrift_hostname : "%{::ipaddress}"
>>> [3]
>>> https://github.com/wso2/puppet-modules/blob/master/hieradata/dev/wso2/wso2mb/3.1.0/kubernetes/default.yaml
>>>
>>> Thanks,
>>> Pumudu
>>>
>>> On Mon, May 9, 2016 at 12:08 PM, Akalanka Pagoda Arachchi <
>>> darsha...@wso2.com> wrote:
>>>
 Hi Thanuja,

 As you have mentioned, the MB needs the IP address instead of the host
 name to configure the Thrift server. So you will have to correct the thrift
 server connection details mentioned in "wso2mb-default/
 10.100.186.164:7611".

 Thanks,
 Akalanka.

 On Mon, May 9, 2016 at 11:31 AM, Isuru Haththotuwa 
 wrote:

> Hi Thanuja,
>
> There is an extension point [1] in the startup script for Dockerfiles,
> where is looks for another script with a particular name format to execute
> before starting the server. You should b able to use that to do a find
> replace in the broker.xml with the container IP.
>
> [1].
> https://github.com/wso2/dockerfiles/blob/master/common/scripts/entrypoint.sh#L87
>
> [2]. docker---init.sh
>
> On Mon, May 9, 2016 at 11:15 AM, Thanuja Uruththirakodeeswaran <
> thanu...@wso2.com> wrote:
>
>> Hi All,
>>
>> When we try to run WSO2 MB docker image build using puppet
>> provisioning with clustering enabled in kubernetes, I'm getting the below
>> error  at the server startup:
>>
>> TID: [-1234] [] [2016-05-09 05:39:06,811] ERROR
>> {org.wso2.andes.server.Main} -  Exception during startup. Triggering
>> shutdown  {org.wso2.andes.server.Main}
>> org.wso2.andes.kernel.AndesException: Unable to initialise
>> application registry
>> at org.wso2.andes.server.Broker.startupImpl(Broker.java:308)
>> at org.wso2.andes.server.Broker.startup(Broker.java:110)
>> at org.wso2.andes.server.Main.startBroker(Main.java:217)
>> at org.wso2.andes.server.Main.execute(Main.java:206)
>> at org.wso2.andes.server.Main.(Main.java:54)
>> at org.wso2.andes.server.Main.main(Main.java:47)
>> at
>> org.wso2.carbon.andes.internal.QpidServiceComponent.startAndesBroker(QpidServiceComponent.java:391)
>> at
>> org.wso2.carbon.andes.internal.QpidServiceComponent.setHazelcastInstance(QpidServiceComponent.java:250)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>> at
>> org.eclipse.equinox.internal.ds.model.ComponentReference.bind(ComponentReference.java:376)
>> at
>> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.bindReference(ServiceComponentProp.java:430)
>> at
>> org.eclipse.equinox.internal.ds.InstanceProcess.dynamicBind(InstanceProcess.java:416)
>> at
>> org.eclipse.equinox.internal.ds.Resolver.getEligible(Resolver.java:334)
>> at
>> org.eclipse.equinox.internal.ds.SCRManager.serviceChanged(SCRManager.java:222)
>> at
>> org.ecli

[Dev] [DAS] Starting DAS gives an error when secure vault enabled

[Amalka Subasinghe]

Hi,

Steps to reproduce.

1. Get DAS 3.0.1 vanilla pack.

2. Enable secure vault as follows

a. added the following line to the
wso2das-3.0.1/repository/conf/security/cipher-tool.properties file
Datasources.WSO2_ANALYTICS_EVENT_STORE_DB.Configuration.Password=repository/conf/datasources/analytics-datasources.xml//datasources-configuration/datasources/datasource[name='WSO2_ANALYTICS_EVENT_STORE_DB']/definition[@type='RDBMS']/configuration/password,true

b. Added the following line to the
wso2das-3.0.1/repository/conf/security/cipher-text.properties file
Datasources.WSO2_ANALYTICS_EVENT_STORE_DB.Configuration.Password=[wso2carbon]

c. Go to wso2das-3.0.1/bin, run ./ciphertool.sh -Dconfigure

d. Now the datasource config is as follows


WSO2_ANALYTICS_EVENT_STORE_DB
The datasource used for analytics record
store



jdbc:h2:repository/database/ANALYTICS_EVENT_STORE;AUTO_SERVER=TRUE;DB_CLOSE_ON_EXIT=FALSE;LOCK_TIMEOUT=6
wso2carbon
password
org.h2.Driver
50
6
SELECT 1
false
0
true

4000




3. Start the DAS - this will give following error

[2016-05-10 08:36:18,622] ERROR
{org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceComponent}
-  Error in activating analytics data service: Error in looking up database
type: Wrong user name or password [8004-140]
org.wso2.carbon.analytics.datasource.commons.exception.AnalyticsException:
Error in looking up database type: Wrong user name or password [8004-140]
at
org.wso2.carbon.analytics.datasource.rdbms.RDBMSUtils.lookupDatabaseInfo(RDBMSUtils.java:73)
at
org.wso2.carbon.analytics.datasource.rdbms.RDBMSUtils.lookupCurrentQueryConfigurationEntry(RDBMSUtils.java:89)
at
org.wso2.carbon.analytics.datasource.rdbms.RDBMSAnalyticsRecordStore.init(RDBMSAnalyticsRecordStore.java:83)
at
org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceImpl.initARS(AnalyticsDataServiceImpl.java:263)
at
org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceImpl.(AnalyticsDataServiceImpl.java:123)
at
org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceComponent.activate(AnalyticsDataServiceComponent.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:260)
at
org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:146)
at
org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:345)
at
org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:620)
at
org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:197)
at
org.eclipse.equinox.internal.ds.Resolver.getEligible(Resolver.java:343)
at
org.eclipse.equinox.internal.ds.SCRManager.serviceChanged(SCRManager.java:222)
at
org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
at
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at
org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:771)
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130)
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:214)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:433)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:451)
at
org.wso2.carbon.ntask.core.internal.TasksDSComponent.activate(TasksDSComponent.java:106)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:260)
at
org.eclipse.equinox.internal.ds.

Re: [Dev] [Vote] Developer Studio Kernel RC 2 released !

[Jasintha Dasanayake]

I have noticed following  improvement , those are not blockers but better
if we can get it fix in GA from usability point of view

-Menu seperators are appearing in Developer studio menu , all the eclipse
standard menus has menu separators
-Add keyboard shortcut for relevant sub menus
-All submenus should have a menu icon
-better if we can add submenu under Developer studio menu to reach
Developer studio preferences  directly
-Capp and Maven preferences pages  should be removed from kernel and should
only appear when that plugins are installed
-In Install feature dialog , WSO2 carbon UI appear before the BPS feature ,
seems there is bug when sorting

Apart from above important all other major features are working fine

Thanks and Regards
/Jasintha




On Thu, May 5, 2016 at 3:01 PM, Awanthika Senarath 
wrote:

> Hello Devs,
>
>
> We are pleased to announce the vote for RC-2 of
> *WSO2 Developer Studio Kernel 4.1.0.*
>
> P2 repository of WSO2 developer Studio kernel 4.1.0 is available here
> .
>  Source
> and Tag Location to be voted upon is available here
> 
> .
>
> Developer Studio 4.1.0 Kernel is released on Eclipse Mars (Eclipse 4.5)
>
> Developer Studio Kernel contains a single feature which has the bundles
> that are required to implement WSO2 specific product tooling on Eclipse.
>
>- This release contains Developer Studio migration to Eclipse mars
>- Improvements in the Developer Studio Updater tool for automatic
>updates
>
> The Features and improvements in the RC 2 :
>
>
>1. [+] Stable - go ahead and release
>2. [-]  Broken - do not release (please explain why)
>
>
>
> Regards,
> Dev Studio Team
> Awanthika Senarath
> Software Engineer, WSO2 Inc.
> Mobile: +94717681791
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 

*Jasintha Dasanayake*

*Senior Software EngineerWSO2 Inc. | http://wso2.com lean
. enterprise . middleware*


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

Re: [Dev] [GSOC 16] Initial Project Progress

[Isuru Haththotuwa]

Hi Osura,

On Mon, May 9, 2016 at 11:22 PM, Osura Rathnayake 
wrote:

> Hi mentors,
>
> When setting up the DB according to [1], should shared REGISTRY_DB and
> shared WSO2_USER_DB be resided on a separate server other than the
> manager/worker node? if so can I use the same server i used for load
> balancer for this purpose?
>
Yes, you can.

>
>
> [1] https://docs.wso2.com/display/CLUSTER44x/Setting+up+the+Database
>
> Thanks and Regards
> Osura
>
> On Sun, May 1, 2016 at 9:53 AM, Imesh Gunaratne  wrote:
>
>>
>>
>> On Sat, Apr 30, 2016 at 9:20 PM, Osura Rathnayake 
>> wrote:
>>
>>> Hi Imesh,
>>>
>>> Thank you very much for the guidelines. I will do as you have instructed
>>> and let you know the progress.
>>>
>>
>> Great! Let us know if you find any problems.
>>
>> Thanks
>>
>>>
>>> Regards,
>>> Osura
>>>
>>> On Saturday, April 30, 2016, Imesh Gunaratne  wrote:
>>>
 Hi Osura,

 It's nice to hear from you. I think it would be better if you can
 follow below steps:

 1. Implementing WSO2 Azure membership scheme:

- First understand how WSO2 Carbon works by setting up a WSO2
Application Server worker/manager deployment on Azure.
- Use WKA membership scheme for this and see how clustering works.
- Then go through the WSO2 Kubernetes membership scheme source code.
- Afterwards implement a new WSO2 membership scheme for Azure.

 2. Next see how each of the following can be setup on Azure using
 native features:

- Auto healing
- Autoscaling
- Dynamic load balancing
- Centralized logging
- Monitoring
- Metering

 Thanks


 On Fri, Apr 29, 2016 at 8:07 PM, Osura Rathnayake 
 wrote:

> Hi All,
>
> Thank you very much for accepting my proposal.
>
> Yes these days i am working on understanding how hazelcast behaves.
>
> I have already come across some of Azure API references that can be
> used to identify a group of VMs.
>
> Network Security Group (NSG) is the equivalent AWS Security group that
> we could find in azure. And this [1] is the API reference that can be used
> to get information about a particular NSG. There under 
> networkInterfaces.id
> element, we can get a collection of references to Network Interface
> Cards that reference this NSG. And then using that we can get information
> about NICs [2]. There under virtualMachine element, we can get the VM
> associated with that NIC. I think we can use method to identify a group of
> VMs.
>
>
>
> [1] https://msdn.microsoft.com/en-us/library/azure/mt163654.aspx
> [2] https://msdn.microsoft.com/en-us/library/azure/mt163611.aspx
>
> Regards,
> Osura
>
> On Fri, Apr 29, 2016 at 4:16 PM, Isuru Haththotuwa 
> wrote:
>
>> Hi Osura,
>>
>> First of all, great work with the proposal and congratulations on
>> getting selected!
>>
>> As you know, this is the community bonding period which you can use
>> to enhance your community relationship and of course to gain knowledge in
>> the related areas. Hope you are right on it!
>>
>> Can you please send a brief update about the any project related work
>> that you are doing now? Please copy the wso2 dev list (dev@wso2.org)
>> as well.
>>
>> --
>> Thanks and Regards,
>>
>> Isuru H.
>> +94 716 358 048* *
>>
>>
>>
>
>


 --
 *Imesh Gunaratne*
 Senior Technical Lead
 WSO2 Inc: http://wso2.com
 T: +94 11 214 5345 M: +94 77 374 2057
 W: http://imesh.io TW: @imesh
 Lean . Enterprise . Middleware


>>
>>
>> --
>> *Imesh Gunaratne*
>> Senior Technical Lead
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057
>> W: http://imesh.io TW: @imesh
>> Lean . Enterprise . Middleware
>>
>>
>


-- 
Thanks and Regards,

Isuru H.
+94 716 358 048* *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [GSOC 16] Initial Project Progress

[Imesh Gunaratne]

Hi Osura,

On Mon, May 9, 2016 at 11:22 PM, Osura Rathnayake 
wrote:

> Hi mentors,
>
> When setting up the DB according to [1], should shared REGISTRY_DB and
> shared WSO2_USER_DB be resided on a separate server other than the
> manager/worker node? if so can I use the same server i used for load
> balancer for this purpose?
>

It is not a problem, you can install your database server in any host.

>
>
> [1] https://docs.wso2.com/display/CLUSTER44x/Setting+up+the+Database
>
> Thanks and Regards
> Osura
>
> On Sun, May 1, 2016 at 9:53 AM, Imesh Gunaratne  wrote:
>
>>
>>
>> On Sat, Apr 30, 2016 at 9:20 PM, Osura Rathnayake 
>> wrote:
>>
>>> Hi Imesh,
>>>
>>> Thank you very much for the guidelines. I will do as you have instructed
>>> and let you know the progress.
>>>
>>
>> Great! Let us know if you find any problems.
>>
>> Thanks
>>
>>>
>>> Regards,
>>> Osura
>>>
>>> On Saturday, April 30, 2016, Imesh Gunaratne  wrote:
>>>
 Hi Osura,

 It's nice to hear from you. I think it would be better if you can
 follow below steps:

 1. Implementing WSO2 Azure membership scheme:

- First understand how WSO2 Carbon works by setting up a WSO2
Application Server worker/manager deployment on Azure.
- Use WKA membership scheme for this and see how clustering works.
- Then go through the WSO2 Kubernetes membership scheme source code.
- Afterwards implement a new WSO2 membership scheme for Azure.

 2. Next see how each of the following can be setup on Azure using
 native features:

- Auto healing
- Autoscaling
- Dynamic load balancing
- Centralized logging
- Monitoring
- Metering

 Thanks


 On Fri, Apr 29, 2016 at 8:07 PM, Osura Rathnayake 
 wrote:

> Hi All,
>
> Thank you very much for accepting my proposal.
>
> Yes these days i am working on understanding how hazelcast behaves.
>
> I have already come across some of Azure API references that can be
> used to identify a group of VMs.
>
> Network Security Group (NSG) is the equivalent AWS Security group that
> we could find in azure. And this [1] is the API reference that can be used
> to get information about a particular NSG. There under 
> networkInterfaces.id
> element, we can get a collection of references to Network Interface
> Cards that reference this NSG. And then using that we can get information
> about NICs [2]. There under virtualMachine element, we can get the VM
> associated with that NIC. I think we can use method to identify a group of
> VMs.
>
>
>
> [1] https://msdn.microsoft.com/en-us/library/azure/mt163654.aspx
> [2] https://msdn.microsoft.com/en-us/library/azure/mt163611.aspx
>
> Regards,
> Osura
>
> On Fri, Apr 29, 2016 at 4:16 PM, Isuru Haththotuwa 
> wrote:
>
>> Hi Osura,
>>
>> First of all, great work with the proposal and congratulations on
>> getting selected!
>>
>> As you know, this is the community bonding period which you can use
>> to enhance your community relationship and of course to gain knowledge in
>> the related areas. Hope you are right on it!
>>
>> Can you please send a brief update about the any project related work
>> that you are doing now? Please copy the wso2 dev list (dev@wso2.org)
>> as well.
>>
>> --
>> Thanks and Regards,
>>
>> Isuru H.
>> +94 716 358 048* *
>>
>>
>>
>
>


 --
 *Imesh Gunaratne*
 Senior Technical Lead
 WSO2 Inc: http://wso2.com
 T: +94 11 214 5345 M: +94 77 374 2057
 W: http://imesh.io TW: @imesh
 Lean . Enterprise . Middleware


>>
>>
>> --
>> *Imesh Gunaratne*
>> Senior Technical Lead
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057
>> W: http://imesh.io TW: @imesh
>> Lean . Enterprise . Middleware
>>
>>
>


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

Re: [Dev] [DEV][Puppet Modules] Finalizing wso2/puppet-modules 2.0.0 release

[Chamila De Alwis]

Hi Akila,

On Tue, May 10, 2016 at 6:14 AM, Akila Ravihansa Perera 
wrote:

> WARNING: class inherits across module namespaces
> WARNING: line has more than 80 characters
>

I think we can ignore these as they were considered in the decision
process. I'll change the release notes to amend the line about vm_type.


Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Chamila De Alwis]

I agree. Let's keep vm_type for simplicity.


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



On Tue, May 10, 2016 at 6:15 AM, Akila Ravihansa Perera 
wrote:

> Hi Chamila,
>
> Docker is not really a platform if you look at the semantics. If we create
> another YAML for docker under platform hierarchy then we have to duplicate
> every platform specific YAML files under product hierarchy. I don't think
> it's a good option for us.
>
> Thanks.
>
> On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis 
> wrote:
>
>> Hi Akila,
>>
>> Why don't we use Docker as a platform rather than a vm_type? I'm not sure
>> about Rocket, however if there are no considerable data duplication between
>> Docker and a possible Rocket configuration data set, IMO we should keep the
>> hierarchy simple and include Docker as a platform. WDYT?
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> It seems "vm_type" hierarchy should exist to build Docker images
>>> (provisioned via Puppet) and then run on bare Docker. Because when building
>>> the images for default platform (which is the option for bare Docker),
>>> there should be a separate hierarchy to set the installation_dir parameter
>>> to "/mnt".
>>>
>>> I think it makes sense to have a separate hierarchy to control the
>>> configuration data for containers or VMs since that is one layer below the
>>> platform level in a deployment infrastructure. For eg: we can have a
>>> Kubernetes platform with Docker as the container technology OR it could be
>>> even Rocket. Inside this whatever vm_type we can have any base operating
>>> system running. So I've refined the hierarchy as follows;
>>>
>>> :hierarchy:
>>> - "node/%{::clientcert}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>>> - "osfamily/%{::osfamily}"
>>> - "vm_type/%{::vm_type}"
>>> - "platform/%{::platform}"
>>> - wso2/common
>>> - common
>>> :backends:
>>> - yaml
>>> :yaml:
>>> :datadir: "hieradata/%{::environment}"
>>>
>>> Since "wso2/common" and "common" are static hierarchies, those should be
>>> moved to the bottom. Please raise any concerns you may have with this
>>> hierarchy.
>>>
>>> Thanks.
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis 
>>> wrote:
>>>
 +1, IMO that's better since now it's clear how what kubernetes.yaml
 stands for.


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



 On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
 raviha...@wso2.com> wrote:

> Hi Chamila,
>
> Agreed. I don't think there would be anymore files in addition to
> common.yaml here. How about moving this to root level; for eg:
> "platform/kubernetes.yaml" ?
>
> Full Hierarchy will be as follows;
>
> :hierarchy:
> - "node/%{::clientcert}"
> - 
> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
> - "platform/%{::platform}"
> - "osfamily/%{::osfamily}"
> - wso2/common
> - common
> :backends:
> - yaml
> :yaml:
> :datadir: "hieradata/%{::environment}"
>
>
> Thanks.
>
>
> On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis 
> wrote:
>
>> +1
>>
>> How about wso2/kubernetes.yaml instead of
>> wso2/kubernetes/common.yaml? Will there be a YAML file in addition to the
>> common.yaml?
>>
>> - "wso2/%{::platform}"
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> We recently introduced a facter named "platform" to denote a PaaS
>>> framework or cluster management system on which WSO2 products could be
>>> deployed. With this addition I feel there is no reason to keep -
>>> "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
>>> configuration parameters that is common across all the products for a
>>> specific platform.
>>>
>>> For eg: In Kubernetes platform, we need to copy the Kubernetes
>>> membership scheme and related dependency jars for all the products. 
>>> Also we
>>> need t

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

Hi Chamila,

Docker is not really a platform if you look at the semantics. If we create
another YAML for docker under platform hierarchy then we have to duplicate
every platform specific YAML files under product hierarchy. I don't think
it's a good option for us.

Thanks.

On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis  wrote:

> Hi Akila,
>
> Why don't we use Docker as a platform rather than a vm_type? I'm not sure
> about Rocket, however if there are no considerable data duplication between
> Docker and a possible Rocket configuration data set, IMO we should keep the
> hierarchy simple and include Docker as a platform. WDYT?
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> It seems "vm_type" hierarchy should exist to build Docker images
>> (provisioned via Puppet) and then run on bare Docker. Because when building
>> the images for default platform (which is the option for bare Docker),
>> there should be a separate hierarchy to set the installation_dir parameter
>> to "/mnt".
>>
>> I think it makes sense to have a separate hierarchy to control the
>> configuration data for containers or VMs since that is one layer below the
>> platform level in a deployment infrastructure. For eg: we can have a
>> Kubernetes platform with Docker as the container technology OR it could be
>> even Rocket. Inside this whatever vm_type we can have any base operating
>> system running. So I've refined the hierarchy as follows;
>>
>> :hierarchy:
>> - "node/%{::clientcert}"
>> - 
>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>> - "osfamily/%{::osfamily}"
>> - "vm_type/%{::vm_type}"
>> - "platform/%{::platform}"
>> - wso2/common
>> - common
>> :backends:
>> - yaml
>> :yaml:
>> :datadir: "hieradata/%{::environment}"
>>
>> Since "wso2/common" and "common" are static hierarchies, those should be
>> moved to the bottom. Please raise any concerns you may have with this
>> hierarchy.
>>
>> Thanks.
>>
>>
>>
>> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis 
>> wrote:
>>
>>> +1, IMO that's better since now it's clear how what kubernetes.yaml
>>> stands for.
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
 Hi Chamila,

 Agreed. I don't think there would be anymore files in addition to
 common.yaml here. How about moving this to root level; for eg:
 "platform/kubernetes.yaml" ?

 Full Hierarchy will be as follows;

 :hierarchy:
 - "node/%{::clientcert}"
 - 
 "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
 - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
 - "platform/%{::platform}"
 - "osfamily/%{::osfamily}"
 - wso2/common
 - common
 :backends:
 - yaml
 :yaml:
 :datadir: "hieradata/%{::environment}"


 Thanks.


 On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis 
 wrote:

> +1
>
> How about wso2/kubernetes.yaml instead of wso2/kubernetes/common.yaml?
> Will there be a YAML file in addition to the common.yaml?
>
> - "wso2/%{::platform}"
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> We recently introduced a facter named "platform" to denote a PaaS
>> framework or cluster management system on which WSO2 products could be
>> deployed. With this addition I feel there is no reason to keep -
>> "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
>> configuration parameters that is common across all the products for a
>> specific platform.
>>
>> For eg: In Kubernetes platform, we need to copy the Kubernetes
>> membership scheme and related dependency jars for all the products. Also 
>> we
>> need to set the installation dir to "/mnt" (instead of 
>> "/mnt/%{ipaddress}"
>> because ipaddress is not available at the image build time.
>>
>> Therefore I'd like to propose that we include the
>> "wso2/%{platform}/common" to the hierarchy. Full hiera.yaml would look 
>> like
>> this;
>>
>> :hierarchy:
>> - "node/%{::clientcert}"
>> - 
>> "wso2/%{::product_na

Re: [Dev] [DEV][Puppet Modules] Finalizing wso2/puppet-modules 2.0.0 release

[Akila Ravihansa Perera]

Hi Chamila,

We had to bring back "vm_type" because it is needed for bare Docker
scenario. Please refer to the other thread on wso2-dev list for a detailed
explanation.

I've also fixed Puppet Lint issues in all modules. There are 2 warnings
remaining though, as follows;

WARNING: class inherits across module namespaces
WARNING: line has more than 80 characters

We knew about class inheritance issue from the beginning and decided to go
with it anyway. Line max length of 80 is being enforced by Lint. But that
won't have a big impact I think.

Thanks.


On Mon, May 9, 2016 at 10:31 PM, Chamila De Alwis  wrote:

> Hi,
>
> Let's finalize the wso2/puppet-modules [1] 2.0.0 release. Following are
> the features and fixes implemented in this release.
>
>
>-
>
>Updated Hiera data hierarchy to include deployment platform
>-
>
>Kubernetes based workflow supported, based on wso2/kubernetes-artifacts
>-
>
>system_file_list to copy files with scope outside of CARBON_HOME
>-
>
>Platform specific configuration data sets for Kubernetes
>-
>
>   Kubernetes deployment-ready Puppet modules
>   -
>
>   Data sources matching a distributed set of Kubernetes MySQL Services
>   -
>
>Streamlined Default platform YAML configuration data
>-
>
>Optional update flags to control product pack and JDK cleanup
>-
>
>Minor fixes on the Hiera data
>-
>
>   Issues in YAML file formatting
>   -
>
>   Puppet templates for identity.xml added to relevant products
>   -
>
>   Proxy Port values assigned to different products are streamlined
>   -
>
>   Hostname entries streamlined in default deployment platform data set
>   -
>
>   Pass Through Port Mapping for WSO2 ESB
>   -
>
>   Fixing Thrift Server IP configuration for WSO2 MB
>   -
>
>   SecureVault parameters made optional
>   -
>
>WSO2 API Manager Gateway Manager-Worker separate profiles in Hieradata
>-
>
>WSO2 PPaaS Puppet module and Hiera data removed
>-
>
>vm_type level in the Hiera hierarchy removed
>- Improve Puppet Vagrant setup to use PUPPET_HOME environment variable
>
>
> The Hiera hierarchy is incompatible with the 1.x.x releases, as new levels
> are introduced with the features.
>
> Following are the tasks that should be completed to finalize the release.
>
>- Smoke test each product on the default platform for the default
>profile
>- Smoke test each product on the Kubernetes platform with clustering
>- Fix minor issues found during testing the products
>   - Consistent structure of the YAML file
>   - Style corrections
>   - Missing values that are crucial for product functionality from a
>   Smoke test's point of view
>- Improve and verify the README content
>
> Please refrain from implementing new features that are not fixing critical
> issues.
>
> You can use the following style guide [2] for YAML files in
> wso2/puppet-modules to streamline and format any YAML files that are
> inconsistent.
>
> Furthermore, please share details on the work you are doing and update as
> they are completed.
>
> [1] - https://github.com/wso2/puppet-modules
> [2] -
> https://docs.google.com/document/d/14fblI46ztAwFoq0YR5HjFeloj1jFVBxnuAl-aZ4Ropk/edit?usp=sharing
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>


-- 
Akila Ravihansa Perera
WSO2 Inc.;  http://wso2.com/

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

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Chamila De Alwis]

Hi Akila,

Why don't we use Docker as a platform rather than a vm_type? I'm not sure
about Rocket, however if there are no considerable data duplication between
Docker and a possible Rocket configuration data set, IMO we should keep the
hierarchy simple and include Docker as a platform. WDYT?


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



On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera 
wrote:

> Hi,
>
> It seems "vm_type" hierarchy should exist to build Docker images
> (provisioned via Puppet) and then run on bare Docker. Because when building
> the images for default platform (which is the option for bare Docker),
> there should be a separate hierarchy to set the installation_dir parameter
> to "/mnt".
>
> I think it makes sense to have a separate hierarchy to control the
> configuration data for containers or VMs since that is one layer below the
> platform level in a deployment infrastructure. For eg: we can have a
> Kubernetes platform with Docker as the container technology OR it could be
> even Rocket. Inside this whatever vm_type we can have any base operating
> system running. So I've refined the hierarchy as follows;
>
> :hierarchy:
> - "node/%{::clientcert}"
> - 
> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
> - "osfamily/%{::osfamily}"
> - "vm_type/%{::vm_type}"
> - "platform/%{::platform}"
> - wso2/common
> - common
> :backends:
> - yaml
> :yaml:
> :datadir: "hieradata/%{::environment}"
>
> Since "wso2/common" and "common" are static hierarchies, those should be
> moved to the bottom. Please raise any concerns you may have with this
> hierarchy.
>
> Thanks.
>
>
>
> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis 
> wrote:
>
>> +1, IMO that's better since now it's clear how what kubernetes.yaml
>> stands for.
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi Chamila,
>>>
>>> Agreed. I don't think there would be anymore files in addition to
>>> common.yaml here. How about moving this to root level; for eg:
>>> "platform/kubernetes.yaml" ?
>>>
>>> Full Hierarchy will be as follows;
>>>
>>> :hierarchy:
>>> - "node/%{::clientcert}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>>> - "platform/%{::platform}"
>>> - "osfamily/%{::osfamily}"
>>> - wso2/common
>>> - common
>>> :backends:
>>> - yaml
>>> :yaml:
>>> :datadir: "hieradata/%{::environment}"
>>>
>>>
>>> Thanks.
>>>
>>>
>>> On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis 
>>> wrote:
>>>
 +1

 How about wso2/kubernetes.yaml instead of wso2/kubernetes/common.yaml?
 Will there be a YAML file in addition to the common.yaml?

 - "wso2/%{::platform}"


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



 On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
 raviha...@wso2.com> wrote:

> Hi,
>
> We recently introduced a facter named "platform" to denote a PaaS
> framework or cluster management system on which WSO2 products could be
> deployed. With this addition I feel there is no reason to keep -
> "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
> configuration parameters that is common across all the products for a
> specific platform.
>
> For eg: In Kubernetes platform, we need to copy the Kubernetes
> membership scheme and related dependency jars for all the products. Also 
> we
> need to set the installation dir to "/mnt" (instead of "/mnt/%{ipaddress}"
> because ipaddress is not available at the image build time.
>
> Therefore I'd like to propose that we include the
> "wso2/%{platform}/common" to the hierarchy. Full hiera.yaml would look 
> like
> this;
>
> :hierarchy:
> - "node/%{::clientcert}"
> - 
> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
> - "wso2/%{::platform}/common"
> - wso2/common
> - "osfamily/%{::osfamily}"
> - common
> :backends:
> - yaml
> :yaml:
> :datadir: "hieradata/%{::environment}"
>
>
> Any thoughts?
>
> Thanks.
>
> --
> Akila Ravihansa Perera
> WSO2 Inc.;  http://wso2.com/
>
> Blog: http://ravihans

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

Hi,

It seems "vm_type" hierarchy should exist to build Docker images
(provisioned via Puppet) and then run on bare Docker. Because when building
the images for default platform (which is the option for bare Docker),
there should be a separate hierarchy to set the installation_dir parameter
to "/mnt".

I think it makes sense to have a separate hierarchy to control the
configuration data for containers or VMs since that is one layer below the
platform level in a deployment infrastructure. For eg: we can have a
Kubernetes platform with Docker as the container technology OR it could be
even Rocket. Inside this whatever vm_type we can have any base operating
system running. So I've refined the hierarchy as follows;

:hierarchy:
- "node/%{::clientcert}"
- 
"wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
- "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
- "osfamily/%{::osfamily}"
- "vm_type/%{::vm_type}"
- "platform/%{::platform}"
- wso2/common
- common
:backends:
- yaml
:yaml:
:datadir: "hieradata/%{::environment}"

Since "wso2/common" and "common" are static hierarchies, those should be
moved to the bottom. Please raise any concerns you may have with this
hierarchy.

Thanks.



On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis  wrote:

> +1, IMO that's better since now it's clear how what kubernetes.yaml stands
> for.
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Chamila,
>>
>> Agreed. I don't think there would be anymore files in addition to
>> common.yaml here. How about moving this to root level; for eg:
>> "platform/kubernetes.yaml" ?
>>
>> Full Hierarchy will be as follows;
>>
>> :hierarchy:
>> - "node/%{::clientcert}"
>> - 
>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>> - "platform/%{::platform}"
>> - "osfamily/%{::osfamily}"
>> - wso2/common
>> - common
>> :backends:
>> - yaml
>> :yaml:
>> :datadir: "hieradata/%{::environment}"
>>
>>
>> Thanks.
>>
>>
>> On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis 
>> wrote:
>>
>>> +1
>>>
>>> How about wso2/kubernetes.yaml instead of wso2/kubernetes/common.yaml?
>>> Will there be a YAML file in addition to the common.yaml?
>>>
>>> - "wso2/%{::platform}"
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
 Hi,

 We recently introduced a facter named "platform" to denote a PaaS
 framework or cluster management system on which WSO2 products could be
 deployed. With this addition I feel there is no reason to keep -
 "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
 configuration parameters that is common across all the products for a
 specific platform.

 For eg: In Kubernetes platform, we need to copy the Kubernetes
 membership scheme and related dependency jars for all the products. Also we
 need to set the installation dir to "/mnt" (instead of "/mnt/%{ipaddress}"
 because ipaddress is not available at the image build time.

 Therefore I'd like to propose that we include the
 "wso2/%{platform}/common" to the hierarchy. Full hiera.yaml would look like
 this;

 :hierarchy:
 - "node/%{::clientcert}"
 - 
 "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
 - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
 - "wso2/%{::platform}/common"
 - wso2/common
 - "osfamily/%{::osfamily}"
 - common
 :backends:
 - yaml
 :yaml:
 :datadir: "hieradata/%{::environment}"


 Any thoughts?

 Thanks.

 --
 Akila Ravihansa Perera
 WSO2 Inc.;  http://wso2.com/

 Blog: http://ravihansa3000.blogspot.com

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


>>>
>>
>>
>> --
>> Akila Ravihansa Perera
>> WSO2 Inc.;  http://wso2.com/
>>
>> Blog: http://ravihansa3000.blogspot.com
>>
>
>


-- 
Akila Ravihansa Perera
WSO2 Inc.;  http://wso2.com/

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

Re: [Dev] [GSOC 16] Initial Project Progress

[Osura Rathnayake]

Hi mentors,

When setting up the DB according to [1], should shared REGISTRY_DB and
shared WSO2_USER_DB be resided on a separate server other than the
manager/worker node? if so can I use the same server i used for load
balancer for this purpose?


[1] https://docs.wso2.com/display/CLUSTER44x/Setting+up+the+Database

Thanks and Regards
Osura

On Sun, May 1, 2016 at 9:53 AM, Imesh Gunaratne  wrote:

>
>
> On Sat, Apr 30, 2016 at 9:20 PM, Osura Rathnayake 
> wrote:
>
>> Hi Imesh,
>>
>> Thank you very much for the guidelines. I will do as you have instructed
>> and let you know the progress.
>>
>
> Great! Let us know if you find any problems.
>
> Thanks
>
>>
>> Regards,
>> Osura
>>
>> On Saturday, April 30, 2016, Imesh Gunaratne  wrote:
>>
>>> Hi Osura,
>>>
>>> It's nice to hear from you. I think it would be better if you can follow
>>> below steps:
>>>
>>> 1. Implementing WSO2 Azure membership scheme:
>>>
>>>- First understand how WSO2 Carbon works by setting up a WSO2
>>>Application Server worker/manager deployment on Azure.
>>>- Use WKA membership scheme for this and see how clustering works.
>>>- Then go through the WSO2 Kubernetes membership scheme source code.
>>>- Afterwards implement a new WSO2 membership scheme for Azure.
>>>
>>> 2. Next see how each of the following can be setup on Azure using native
>>> features:
>>>
>>>- Auto healing
>>>- Autoscaling
>>>- Dynamic load balancing
>>>- Centralized logging
>>>- Monitoring
>>>- Metering
>>>
>>> Thanks
>>>
>>>
>>> On Fri, Apr 29, 2016 at 8:07 PM, Osura Rathnayake 
>>> wrote:
>>>
 Hi All,

 Thank you very much for accepting my proposal.

 Yes these days i am working on understanding how hazelcast behaves.

 I have already come across some of Azure API references that can be
 used to identify a group of VMs.

 Network Security Group (NSG) is the equivalent AWS Security group that
 we could find in azure. And this [1] is the API reference that can be used
 to get information about a particular NSG. There under networkInterfaces.id
 element, we can get a collection of references to Network Interface
 Cards that reference this NSG. And then using that we can get information
 about NICs [2]. There under virtualMachine element, we can get the VM
 associated with that NIC. I think we can use method to identify a group of
 VMs.



 [1] https://msdn.microsoft.com/en-us/library/azure/mt163654.aspx
 [2] https://msdn.microsoft.com/en-us/library/azure/mt163611.aspx

 Regards,
 Osura

 On Fri, Apr 29, 2016 at 4:16 PM, Isuru Haththotuwa 
 wrote:

> Hi Osura,
>
> First of all, great work with the proposal and congratulations on
> getting selected!
>
> As you know, this is the community bonding period which you can use to
> enhance your community relationship and of course to gain knowledge in the
> related areas. Hope you are right on it!
>
> Can you please send a brief update about the any project related work
> that you are doing now? Please copy the wso2 dev list (dev@wso2.org)
> as well.
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* *
>
>
>


>>>
>>>
>>> --
>>> *Imesh Gunaratne*
>>> Senior Technical Lead
>>> WSO2 Inc: http://wso2.com
>>> T: +94 11 214 5345 M: +94 77 374 2057
>>> W: http://imesh.io TW: @imesh
>>> Lean . Enterprise . Middleware
>>>
>>>
>
>
> --
> *Imesh Gunaratne*
> Senior Technical Lead
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: http://imesh.io TW: @imesh
> Lean . Enterprise . Middleware
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [DEV][Puppet Modules] Finalizing wso2/puppet-modules 2.0.0 release

[Chamila De Alwis]

Hi,

Let's finalize the wso2/puppet-modules [1] 2.0.0 release. Following are the
features and fixes implemented in this release.


   -

   Updated Hiera data hierarchy to include deployment platform
   -

   Kubernetes based workflow supported, based on wso2/kubernetes-artifacts
   -

   system_file_list to copy files with scope outside of CARBON_HOME
   -

   Platform specific configuration data sets for Kubernetes
   -

  Kubernetes deployment-ready Puppet modules
  -

  Data sources matching a distributed set of Kubernetes MySQL Services
  -

   Streamlined Default platform YAML configuration data
   -

   Optional update flags to control product pack and JDK cleanup
   -

   Minor fixes on the Hiera data
   -

  Issues in YAML file formatting
  -

  Puppet templates for identity.xml added to relevant products
  -

  Proxy Port values assigned to different products are streamlined
  -

  Hostname entries streamlined in default deployment platform data set
  -

  Pass Through Port Mapping for WSO2 ESB
  -

  Fixing Thrift Server IP configuration for WSO2 MB
  -

  SecureVault parameters made optional
  -

   WSO2 API Manager Gateway Manager-Worker separate profiles in Hieradata
   -

   WSO2 PPaaS Puppet module and Hiera data removed
   -

   vm_type level in the Hiera hierarchy removed
   - Improve Puppet Vagrant setup to use PUPPET_HOME environment variable


The Hiera hierarchy is incompatible with the 1.x.x releases, as new levels
are introduced with the features.

Following are the tasks that should be completed to finalize the release.

   - Smoke test each product on the default platform for the default profile
   - Smoke test each product on the Kubernetes platform with clustering
   - Fix minor issues found during testing the products
  - Consistent structure of the YAML file
  - Style corrections
  - Missing values that are crucial for product functionality from a
  Smoke test's point of view
   - Improve and verify the README content

Please refrain from implementing new features that are not fixing critical
issues.

You can use the following style guide [2] for YAML files in
wso2/puppet-modules to streamline and format any YAML files that are
inconsistent.

Furthermore, please share details on the work you are doing and update as
they are completed.

[1] - https://github.com/wso2/puppet-modules
[2] -
https://docs.google.com/document/d/14fblI46ztAwFoq0YR5HjFeloj1jFVBxnuAl-aZ4Ropk/edit?usp=sharing


Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [PC] Getting user names from registry log entries

[Sameera Gunarathne]

Thanks for the input given.I will look into go for implementing a registry
handler in this case.

Thanks,
Sameera.

On Mon, May 9, 2016 at 1:56 PM, Thushara Ranawaka 
wrote:

> Hi Sameera,
>
> Even though test_user did 868, 869 and 870 activities the registry
> delegate the process to wso2.system.user.
> For example when you creating a soap service using WSDL soap service
> creation entries are done by wso2.system.user.
> However you should able to see actions done using test_user for process
> assets under test_user. But not the automated ones done by wso2.system.
> user.
> This is the behaviour and a known limitation in G-Reg. In your case you
> need to write a new component to store these audit logs.
>
>
> Thanks,
> Thushara.
>
>
> On Thu, May 5, 2016 at 6:51 PM, Sameera Gunarathne 
> wrote:
>
>> Hi all,
>>
>> I am trying to get user name for log entries by accessing REG_LOG table
>> at the registry. There it is recorded as the wso2.system.user. I have
>> created a separate user called "test_user" along with the "admin" user. The
>> activities done by the "test_user" also recorded as the wso2.system.user at
>> the REG_LOG.
>>
>>
>> ​
>> I need to know is there a way to get the user names for these log entries
>> as it is created at the mgmt console?
>> --
>> Sameera Gunarathne
>> Software Engineer, WSO2 Inc. http://wso2.com
>> 
>> Email: samee...@wso2.com
>> Mobile: +94714155561
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thanks,
> Thushara Kasun Ranawaka
> Software Engineer
> WSO2 Inc.; 
> lean.enterprise.middleware
> Mobile : *+94 (0) 773438949 <%2B94%20%280%29%20773438949>*
> *thusha...@wso2.com *
>



-- 
Sameera Gunarathne
Software Engineer, WSO2 Inc. http://wso2.com

Email: samee...@wso2.com
Mobile: +94714155561
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DS] Adding same child for two different parents in WSO2 permission tree

[Manuranga Perera]

Note that there are two ways to do the permission mapping in C4.

1) Per-resource - eg: in registry each resources has delete read writes
permissions for each role.
2) Per-action - eg: in admin console each role can have permission to add
users (but this can't be limited for just one user store)

We have kind of done 1 but in our code (this was how it was and didn't have
time to change in last release), may be we should move it to gov side. I am
not sure which one is correct for us, but please think about this.

On Mon, May 9, 2016 at 3:11 AM, Sinthuja Ragendran 
wrote:

> Hi Megala,
>
> From the dashboard server point of view, we just need to have permission
> tree as,
>
> - Portal
>   - Login
>   - Dashboard
>  - Create
>  - Delete
>  - Settings
>
> In this model, the create permission is required for the user to create
> the dashboard, and similarly for other operations. We don't need to have
> the designer/viewer permissions in this level, because we the design and
> viewers are being assigned per dashboard and hence we can't globally
> control with permission.
>
> Thanks,
> Sinthuja.
>
> On Sat, May 7, 2016 at 3:31 PM, Megala Uthayakumar 
> wrote:
>
>> Hi All,
>>
>> I am working on adding a permission model for Dashboard Server. I came
>> across following requirement.
>>
>> Assume there is a permission for accessing designer portal of DS
>> ("Designer-Portal"). Among the users who have "Designer-Portal" permission,
>> only some are provided with the "Create-Dashboard" and "Delete-Dashboard"
>> permission. AFAIU according to wso2 permission tree, we need to add
>> "Design-Portal" permission as a child for both "Create-Dashboard" and
>> "Delete-Dashboard" parents. But in that case, there will be two different
>> permissions for accessing same designer portal. I think, it is not correct
>> to provide the same accessing capabilities using two different permission
>> level settings.
>>
>> Is there any way, such that permission tree can have the same child for
>> two different parents? Any suggestions on this is highly appreciated.
>>
>> Thanks
>>
>> Regards,
>> Megala
>>
>> --
>> Megala Uthayakumar
>>
>> Software Engineer
>> Mobile : 0779967122
>>
>
>
>
> --
> *Sinthuja Rajendran*
> Associate 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
>
>


-- 
With regards,
*Manu*ranga Perera.

phone : 071 7 70 20 50
mail : m...@wso2.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Issue in creating a SaaS App with the Multi-Tenant Carbon Framework

[Sirojan Tharmakulasingam]

Hi all,

I am following the below blog post in order to get an understanding
of creating a SaaS App with the Multi-Tenant Carbon Framework.

 Blog post link :
http://wso2.com/library/blog-post/2013/09/creating-a-saas-app-with-the-multi-tenant-carbon-framework-step-1/

According to the blog post,
1. I create two tenants in application server
2. Deploy a sample war file created from the source at
https://github.com/karux/CarbonSaaSTest which is associated to all Tenants
3. But when I tried to log in with the valid credentials of the
tenant admin, it gives me "HTTP Status 403 - Access to the requested
resource has been denied" [In the blog post I struck with the step 5 under
the section of  "Provision a Global Scope Application"]

Am I missing anything? Can anybody guide me on this?


Thanks.

Regards,
-- 
Sirojan Tharmakulasingam
Software Engineer, WSO2 Inc. http://wso2.com
Email: siro...@wso2.com
Mobile: +94779797913
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [PC] [ES] Cannot retrieve feature details of searchHistory error after moving to latest store version

[Waruna Jayaweera]

Hi,
Thanks Denuwanthi. After adding the new element to our
 process-store-tenant.json issue got resolved.

Thanks,
Waruna

On Fri, May 6, 2016 at 3:30 PM, Denuwanthi De Silva 
wrote:

> Hi Waruna,
>
> Can you specify the store and registry versions you are using?
> We have introduced new element
> "searchHistory": {
> "enabled": true,
> "keys": {
> "maxCount": 5
> }
> }
>
> to store-tenant.json in carbon-store [1].
> If that element is not present the above mentioned error will occur when
> try to log in to the store.
> You can check whether this element is present in your set up by visiting
> management console and browse to '/_system/config/store/configs/store.json'
> file and check for the above element.
>
> [1]
> https://github.com/wso2/carbon-store/blob/master/apps/store/config/store-tenant.json#L17-22
>
> Thanks
>
> On Fri, May 6, 2016 at 3:14 PM, Waruna Jayaweera  wrote:
>
>> Hi,
>> We are following getting error and warnings[1] after moving to latest
>> registry and store versions. Every time we browse process( asset) in the
>> store, following warnings and errors can be seen. I found a similar issue
>> in [2].
>> Appreciate any help on how to solve this.
>>
>> [1]
>> [2016-05-06 14:20:25,936] ERROR {app-core} -  Cannot retrieve feature
>>  details of searchHistory as it does not exist in the feature block.
>> [2016-05-06 14:20:25,937]  WARN {app-core} -  Could not locate feature
>> details of : searchHistory.The feature will be assumed to be disabled.
>> [2016-05-06 14:21:00,343] ERROR {app-core} -  Cannot retrieve feature
>>  details of searchHistory as it does not exist in the feature block.
>> [2016-05-06 14:21:00,345]  WARN {app-core} -  Could not locate feature
>> details of : searchHistory.The feature will be assumed to be disabled.
>> [2016-05-06 14:21:12,158] ERROR {app-core} -  Cannot retrieve feature
>>  details of searchHistory as it does not exist in the feature block.
>> [2016-05-06 14:21:12,160]  WARN {app-core} -  Could not locate feature
>> details of : searchHistory.The feature will be assumed to be disabled.
>> [2016-05-06 14:21:13,015] ERROR {app-core} -  Cannot retrieve feature
>>  details of searchHistory as it does not exist in the feature block.
>> [2016-05-06 14:21:13,016]  WARN {app-core} -  Could not locate feature
>> details of : searchHistory.The feature will be assumed to be disabled.
>> [2016-05-06 14:51:36,447] ERROR {app-core} -  Cannot retrieve feature
>>  details of searchHistory as it does not exist in the feature block.
>> [2016-05-06 14:51:36,448]  WARN {app-core} -  Could not locate feature
>> details of : searchHistory.The feature will be assumed to be disabled.
>>
>> [2] https://wso2.org/jira/browse/REGISTRY-3528
>>
>>
>> Thanks,
>> Waruna
>> --
>> Regards,
>>
>> Waruna Lakshitha Jayaweera
>> Software Engineer
>> WSO2 Inc; http://wso2.com
>> phone: +94713255198
>>
>
>
>
> --
> Denuwanthi De Silva
> Software Engineer;
> WSO2 Inc.; http://wso2.com,
> Email: denuwan...@wso2.com
> Blog: https://denuwanthi.wordpress.com/
>



-- 
Regards,

Waruna Lakshitha Jayaweera
Software Engineer
WSO2 Inc; http://wso2.com
phone: +94713255198
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Running WSO2ESB in Clutered mode

[Vishanth Balasubramaniam]

Hi Abhishek,



On Mon, May 9, 2016 at 7:14 AM, Abhishek Tiwari <
abhishek.tiwari0...@gmail.com> wrote:

> Hi All,
>
> I have been trying to run ESB in clustered setup (one master and one
> worker node). Here are the steps I followed:
> 1) Have two copies of wso2esb-4.9.0 (esb-master and esb-worker).
> 2) Started esb-master/bin/wso2server.sh
> 3) Verified server start from logs and web management console.
> 4) Started esb-workder/bin/wso2server.sh -DworkerNode (this gave port
> already used exceptions for monitoring ports already in use)
>

I guess it could be because the port offset is not set in one of your esb
nodes. Follow the steps in the link provided by Chamila, that would help.


>
> The above does not work, and unfortunately, I did not find cluster/profile
> specific documentation in ESB documentation (
> https://docs.wso2.com/display/ESB490/Getting+Started), and there weren't
> any samples (https://docs.wso2.com/display/ESB490/Samples) either. So my
> questions are:
> 1) How do run master worker setup in localhost. Any Docs?
> 2) Are there any predefined profiles for this use-case?
>
> Thanks
> Abhishek
>

Regards,
Vishanth

-- 
*Vishanth Balasubramaniam*
Committer & PMC Member, Apache Stratos,
Software Engineer, WSO2 Inc.; http://wso2.com

mobile: *+94 77 17 377 18*
about me: *http://about.me/vishanth *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Failed to add rxt to registry issue in GREG

[Vishanth Balasubramaniam]

Hi,

I'm trying to setup 2 GREG nodes clustered in Kubernetes using Kubernetes
Membership Scheme. The GREG nodes are started using Dsetup.
When both GREG nodes are started in different Pods during same time, the
following error occurs in one of the nodes but the product starts fine.

TID: [-1234] [] [2016-05-09 11:50:03,903] ERROR
{JAGGERY.app-scripts.init-scripts.app:js} -
 org.mozilla.javascript.WrappedException: Wrapped
*org.wso2.carbon.registry.core.exceptions.RegistryException*: *Failed to
add rxt to registry*  (/publisher/modules/publisher.js#48)
at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1754)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:148)
at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:225)
at org.mozilla.javascript.optimizer.OptRuntime.call2(OptRuntime.java:42)
at
org.jaggeryjs.rhino.publisher.modules.c1._c_anonymous_2(/publisher/modules/publisher.js:48)
at
org.jaggeryjs.rhino.publisher.modules.c1.call(/publisher/modules/publisher.js)
at org.mozilla.javascript.ScriptRuntime.applyOrCall(ScriptRuntime.java:2430)
.
.
.
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
*Caused by: org.wso2.carbon.registry.core.exceptions.RegistryException:
Failed to add rxt to registry*
at
org.wso2.carbon.governance.registry.extensions.utils.CommonUtil.addRxtConfigs(CommonUtil.java:265)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:126)
... 144 more
*Caused by:
org.wso2.carbon.registry.core.exceptions.ResourceNotFoundException:
Resource does not exist at path
/_system/governance/repository/components/org.wso2.carbon.governance/types*
at
org.wso2.carbon.registry.core.jdbc.EmbeddedRegistry.get(EmbeddedRegistry.java:532)
at
org.wso2.carbon.registry.core.caching.CacheBackedRegistry.get(CacheBackedRegistry.java:172)
at
org.wso2.carbon.registry.core.session.UserRegistry.getInternal(UserRegistry.java:613)
at
org.wso2.carbon.registry.core.session.UserRegistry.access$400(UserRegistry.java:60)
at
org.wso2.carbon.registry.core.session.UserRegistry$5.run(UserRegistry.java:596)
at
org.wso2.carbon.registry.core.session.UserRegistry$5.run(UserRegistry.java:593)
at java.security.AccessController.doPrivileged(Native Method)
at
org.wso2.carbon.registry.core.session.UserRegistry.get(UserRegistry.java:593)
at
org.wso2.carbon.governance.registry.extensions.utils.CommonUtil.addRxtConfigs(CommonUtil.java:224)
... 149 more
 {JAGGERY.app-scripts.init-scripts.app:js}

What causes this issue?

Also this doesn't happen when one node is started first and then later if
it is scaled up.

Regards,
Vishanth

-- 
*Vishanth Balasubramaniam*
Committer & PMC Member, Apache Stratos,
Software Engineer, WSO2 Inc.; http://wso2.com

mobile: *+94 77 17 377 18*
about me: *http://about.me/vishanth *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Fwd: Fwd: [IS] Missing requirement in building product-is from source

[Chamila Wijayarathna]

[Adding dev]

-- Forwarded message --
From: Manujith Pallewatte 
Date: Mon, May 9, 2016 at 5:00 PM
Subject: Re: [Dev] Fwd: [IS] Missing requirement in building product-is
from source
To: Chamila Wijayarathna 


Hi Malithi,

This error in building identity-framework it's due to an error in maven
felix scr plugin
You can have a temporary fix for this by adding a later version of felix
scr to the place you get the issue
You can find the bug at [2] in apache bug tracker, also the changelog for
1.8.0 mention that bug fixed [3]

Fix I did was to add version 1.8.0 to
identity-framework/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/pom.xml

Note: this will override the scr plugin version defined in the parent pom
which is 1.7.4

[1] https://issues.apache.org/jira/browse/FELIX-3571
[2]
https://svn.apache.org/repos/asf/felix/releases/maven-scr-plugin-1.21.0/changelog.txt

Best Regards,
Manujith


On Mon, May 2, 2016 at 11:29 AM, Manujith Pallewatte 
wrote:

> Hi all,
>
> Just to update in case anyone else is having the issue, product-is didn't
> build on Ubuntu 16.04 (for reasons still not known) but build successfully
> in Ubuntu 14.04. Still having the above mentioned issue in
> identity-framework build though.
>
> Thanks!
>
> On Thu, Apr 28, 2016 at 9:26 AM, Manujith Pallewatte <
> manujith...@gmail.com> wrote:
>
>> Hi Chamila,
>>
>> I tried with maven 3.3 also with maven 3.0.5 as mentioned in the
>> requirements
>> I build product-is only before in a windows environment, with no issues,
>> but it didn't work in the current (ubuntu 16.04) environment
>> From the link above[1] i have all prerequisites other than svn, since I
>> clone from git i believe svn is of no use
>>
>>
>> [1]. https://docs.wso2.com/display/IS510/Installation+Prerequisites
>>
>>
>> On Wed, Apr 27, 2016 at 9:06 PM, Chamila Wijayarathna 
>> wrote:
>>
>>> [adding dev]
>>>
>>> identity-framework should build without any issues, what is the maven
>>> version you are using? Can you check if you have all the requirement
>>> mentioned at [1] for building the identity server from source code. Was
>>> this building successfully previously?
>>>
>>> [1]. https://docs.wso2.com/display/IS510/Installation+Prerequisites
>>>
>>> -- Forwarded message --
>>> From: Manujith Pallewatte 
>>> Date: Wed, Apr 27, 2016 at 7:49 PM
>>> Subject: Re: [IS] Missing requirement in building product-is from source
>>> To: Chamila Wijayarathna 
>>>
>>>
>>> Hi Chamila,
>>>
>>> Apparently identity framework didnt have the latest commits, I forked it
>>> today and pulled but It must have missed some commits
>>> Anyway I updated the local repo to all changes, but now identity
>>> framework gives an error in building
>>>
>>> "[ERROR] Failed to execute goal
>>> org.apache.felix:maven-scr-plugin:1.7.2:scr (generate-scr-scrdescriptor) on
>>> project org.wso2.carbon.identity.application.authentication.framework:
>>> Execution generate-scr-scrdescriptor of goal
>>> org.apache.felix:maven-scr-plugin:1.7.2:scr failed: Comparison method
>>> violates its general contract! -> [Help 1]"
>>>
>>> I google and found that this is a known bug of apache felix, but it
>>> didn't provide and solid way to solve other than to change jdk version
>>> I tried changing version with no luck, any ideas?
>>>
>>> Also found similar error in dev list
>>> http://mail.wso2.org/mailarchive/dev/2015-June/049912.html
>>>
>>> Thank You
>>>
>>> On Wed, Apr 27, 2016 at 4:46 PM, Chamila Wijayarathna 
>>> wrote:
>>>
 Hi Manujith,

 It seems like your identity-framework or product-is is not upto date.

 Can you check what are the latest commits in both repos using git log
 and check if commits merged within last few days are there in your local
 repo?

 Thank You!

 On Wed, Apr 27, 2016 at 3:56 PM, Manujith Pallewatte <
 manujith...@gmail.com> wrote:

> Hi all,
>
> I'm trying to setup the development environment to start working for
> GSOC on the identity server, and I already downloaded and build the
> carbon-identity-framework repo along with the extensions as mentioned in 
> [1]
>
> Now I'm trying to build product-is from source as well, to make sure I
> have all the dependencies before doing in changes to the source, but
> running maven install in product is gives the following error
>
> "Missing requirement: Application Authentication Framework Server
> Feature 5.0.9.SNAPSHOT
> (org.wso2.carbon.identity.application.authentication.framework.server.feature.group
> 5.0.9.SNAPSHOT) requires
> 'org.wso2.carbon.tenant.mgt.common.server.feature.group [4.4.8,4.5.0)' but
> it could not be found"
>
> I check the local maven repo and this package isnt available in it, so
> why is maven not downloading this from the remote repository?
>
> Thank You
>
>
> [1] https://gist.github.com/pulasthi7/3d365a

Re: [Dev] Fwd: [IS] Missing requirement in building product-is from source

[Malithi Edirisinghe]

Anybody know a way to get out of this error ???

On Mon, May 9, 2016 at 1:59 PM, Malithi Edirisinghe 
wrote:

> Hi,
>
> Is this being solved. I get the same error [1] when building on OS X
> Yosemite. Also seems the same was discussed in [2] as well.
>
> This was identified as a bug in felix plugin at [3]. Upgrading the
> maven-scr-plugin to version 1.8.0 successfully built the respective
> component. However, that does to build OSGI bundles properly.
>
> Any idea on how to solve this issue?
>
> [1] "[ERROR] Failed to execute goal 
> org.apache.felix:maven-scr-plugin:1.7.2:scr
> (generate-scr-scrdescriptor) on project org.wso2.carbon.identity.
> application.authentication.framework: Execution
> generate-scr-scrdescriptor of goal org.apache.felix:maven-scr-plugin:1.7.2:scr
> failed: Comparison method violates its general contract! -> [Help 1]"
> [2]"[Dev] [Carbon] Build fail in cerbon4-kernel source code."
> [3] https://issues.apache.org/jira/browse/FELIX-3571
>
> Thanks,
> Malithi
>
> On Mon, May 2, 2016 at 11:29 AM, Manujith Pallewatte <
> manujith...@gmail.com> wrote:
>
>> Hi all,
>>
>> Just to update in case anyone else is having the issue, product-is didn't
>> build on Ubuntu 16.04 (for reasons still not known) but build successfully
>> in Ubuntu 14.04. Still having the above mentioned issue in
>> identity-framework build though.
>>
>> Thanks!
>>
>> On Thu, Apr 28, 2016 at 9:26 AM, Manujith Pallewatte <
>> manujith...@gmail.com> wrote:
>>
>>> Hi Chamila,
>>>
>>> I tried with maven 3.3 also with maven 3.0.5 as mentioned in the
>>> requirements
>>> I build product-is only before in a windows environment, with no issues,
>>> but it didn't work in the current (ubuntu 16.04) environment
>>> From the link above[1] i have all prerequisites other than svn, since I
>>> clone from git i believe svn is of no use
>>>
>>>
>>> [1]. https://docs.wso2.com/display/IS510/Installation+Prerequisites
>>>
>>>
>>> On Wed, Apr 27, 2016 at 9:06 PM, Chamila Wijayarathna 
>>> wrote:
>>>
 [adding dev]

 identity-framework should build without any issues, what is the maven
 version you are using? Can you check if you have all the requirement
 mentioned at [1] for building the identity server from source code. Was
 this building successfully previously?

 [1]. https://docs.wso2.com/display/IS510/Installation+Prerequisites

 -- Forwarded message --
 From: Manujith Pallewatte 
 Date: Wed, Apr 27, 2016 at 7:49 PM
 Subject: Re: [IS] Missing requirement in building product-is from source
 To: Chamila Wijayarathna 


 Hi Chamila,

 Apparently identity framework didnt have the latest commits, I forked
 it today and pulled but It must have missed some commits
 Anyway I updated the local repo to all changes, but now identity
 framework gives an error in building

 "[ERROR] Failed to execute goal
 org.apache.felix:maven-scr-plugin:1.7.2:scr (generate-scr-scrdescriptor) on
 project org.wso2.carbon.identity.application.authentication.framework:
 Execution generate-scr-scrdescriptor of goal
 org.apache.felix:maven-scr-plugin:1.7.2:scr failed: Comparison method
 violates its general contract! -> [Help 1]"

 I google and found that this is a known bug of apache felix, but it
 didn't provide and solid way to solve other than to change jdk version
 I tried changing version with no luck, any ideas?

 Also found similar error in dev list
 http://mail.wso2.org/mailarchive/dev/2015-June/049912.html

 Thank You

 On Wed, Apr 27, 2016 at 4:46 PM, Chamila Wijayarathna >>> > wrote:

> Hi Manujith,
>
> It seems like your identity-framework or product-is is not upto date.
>
> Can you check what are the latest commits in both repos using git log
> and check if commits merged within last few days are there in your local
> repo?
>
> Thank You!
>
> On Wed, Apr 27, 2016 at 3:56 PM, Manujith Pallewatte <
> manujith...@gmail.com> wrote:
>
>> Hi all,
>>
>> I'm trying to setup the development environment to start working for
>> GSOC on the identity server, and I already downloaded and build the
>> carbon-identity-framework repo along with the extensions as mentioned in 
>> [1]
>>
>> Now I'm trying to build product-is from source as well, to make sure
>> I have all the dependencies before doing in changes to the source, but
>> running maven install in product is gives the following error
>>
>> "Missing requirement: Application Authentication Framework Server
>> Feature 5.0.9.SNAPSHOT
>> (org.wso2.carbon.identity.application.authentication.framework.server.feature.group
>> 5.0.9.SNAPSHOT) requires
>> 'org.wso2.carbon.tenant.mgt.common.server.feature.group [4.4.8,4.5.0)' 
>> but
>> it could not be found"
>>
>> I check the local maven repo and this package isnt ava

Re: [Dev] [C5][BPS] Startup errors with new kernel SNAPSHOT

[Nandika Jayawardana]

Can we have a quick resolution to this issue.

Regards
Nandika

On Mon, May 9, 2016 at 11:09 AM, Niranjan Karunanandham 
wrote:

> Hi Sameera,
>
> I have fixed this for carbon-datasources in PR [1].
>
> [1] - https://github.com/wso2/carbon-datasources/pull/14
>
> Regards,
> Nira
>
> On Mon, May 9, 2016 at 10:43 AM, Afkham Azeez  wrote:
>
>> Transport folks, please note. I think a release is planned but we will
>> need to hold it back until these changes are made.
>>
>> On Sun, May 8, 2016 at 12:39 PM, Niranjan Karunanandham <
>> niran...@wso2.com> wrote:
>>
>>> Hi Hasitha,
>>>
>>> There were some improvements done to the startup resolver as mentioned
>>> in [1]. I faced a similar issue[2] when testing the Kernel 5.1.0-alpha2
>>> (which is in staging) with carbon-datasources and I was able to fix it by
>>> following the doc and updating the datasource.core pom.xml [3] and
>>> DataSourceListenerComponent.java [4].
>>>
>>> [1] - https://medium.com/@sameera.jayasoma/497fe3287e67#.ravrmkjir
>>> [2] -
>>> [2016-05-08 11:31:16,371] ERROR {org.wso2.carbon.core} - FrameworkEvent
>>> ERROR - org.wso2.carbon.core
>>> org.wso2.carbon.kernel.internal.startupresolver.StartOrderResolverException:
>>> componentName value is missing in the services registered with the key
>>> org.wso2.carbon.kernel.startupresolver.RequiredCapabilityListener,
>>> implementation class name is
>>> org.wso2.carbon.datasource.core.internal.DataSourceListenerComponent
>>> at
>>> org.wso2.carbon.kernel.internal.startupresolver.OSGiServiceCapabilityTracker$CapabilityServiceTrackerCustomizer.addingService(OSGiServiceCapabilityTracker.java:142)
>>> at
>>> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
>>> at
>>> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
>>> at
>>> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>>> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>>> at
>>> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
>>> at
>>> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109)
>>> at
>>> org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:914)
>>> at
>>> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
>>> at
>>> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
>>> at
>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862)
>>> at
>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801)
>>> at
>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:127)
>>> at
>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:225)
>>> at
>>> org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:464)
>>> at
>>> org.eclipse.equinox.internal.ds.InstanceProcess.registerService(InstanceProcess.java:536)
>>> at
>>> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:213)
>>> at
>>> org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:473)
>>> at
>>> org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:217)
>>> at
>>> org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:816)
>>> at
>>> org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:783)
>>> at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89)
>>> at
>>> org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:70)
>>>
>>> [3] -
>>>
>>> 
>>> 
>>> startup.listener;componentName="carbon-datasource-service";requiredService="org.wso2.carbon.datasource.core.spi.DataSourceReader"
>>> 
>>>
>>>
>>> [4] -
>>>
>>> @Component(
>>> name = 
>>> "org.wso2.carbon.kernel.datasource.core.internal.DataSourceListenerComponent",
>>> immediate = true,
>>> service = RequiredCapabilityListener.class,
>>> property = {
>>> "componentName=carbon-datasource-service"
>>> }
>>> )
>>>
>>> Regards,
>>> Nira
>>>
>>> On Sat, May 7, 2016 at 8:26 PM, Hasitha Aravinda 
>>> wrote:
>>>
 Hi Sameera,

 We are getting following error when server startup.

 osgi> [2016-05-07 20:21:11,972] ERROR
 {org.wso2.carbon.kernel.internal.startupresolver.StartupOrderResolver} -
 Error occurred in Startup Order Resolver.
 org.wso2.carbon.kernel.internal.startupresolver.StartOrderResolverException:
 capabilityName value is missing in the services registered with the key
 org.wso2.carbon.kernel.startupresolver.CapabilityProvider, implementation
 class name is
 org.wso2.msf4j.analytics.internal.Intercepto

Re: [Dev] [Docker][Puppet] [MB] Setting 'thriftServerHost' in WSO2 MB broker.xml file

[Thanuja Uruththirakodeeswaran]

Hi All,

Thanks for the suggestions !!! As Isuru suggested, the best approach would
be to use an extension point to update thriftServerHost with container
ip. Will go with this approach.

Thanks.

On Mon, May 9, 2016 at 2:01 PM, Akila Ravihansa Perera 
wrote:

> Hi Pumudu,
>
> We can't use "%{::ipaddress}" in kubernetes platform since Puppet is only
> used to build the Docker images. The ipaddress is assigned when the
> Kubernetes pods/services are deployed.
>
> I think best method would be to use the extension point as explained by
> Isuru. This should be similar to how we replace the localMemberHost section
> in axis2.xml.
>
> Thanks.
>
> On Mon, May 9, 2016 at 1:34 PM, Pumudu Ruhunage  wrote:
>
>> Hi,
>> AFAIU, Thrift hostname should be changed to IP from puppet modules when
>> configuring hiera data[1]. Following line[2] should added to
>> default.yaml[3] to get the IP when initializing.
>>
>> [1]
>> https://github.com/wso2/puppet-modules/wiki/Creating-a-Puppet-Module-for-a-WSO2-Product#create-the-hiera-configuration-data-set
>> [2] wso2::mb_thrift_hostname : "%{::ipaddress}"
>> [3]
>> https://github.com/wso2/puppet-modules/blob/master/hieradata/dev/wso2/wso2mb/3.1.0/kubernetes/default.yaml
>>
>> Thanks,
>> Pumudu
>>
>> On Mon, May 9, 2016 at 12:08 PM, Akalanka Pagoda Arachchi <
>> darsha...@wso2.com> wrote:
>>
>>> Hi Thanuja,
>>>
>>> As you have mentioned, the MB needs the IP address instead of the host
>>> name to configure the Thrift server. So you will have to correct the thrift
>>> server connection details mentioned in "wso2mb-default/
>>> 10.100.186.164:7611".
>>>
>>> Thanks,
>>> Akalanka.
>>>
>>> On Mon, May 9, 2016 at 11:31 AM, Isuru Haththotuwa 
>>> wrote:
>>>
 Hi Thanuja,

 There is an extension point [1] in the startup script for Dockerfiles,
 where is looks for another script with a particular name format to execute
 before starting the server. You should b able to use that to do a find
 replace in the broker.xml with the container IP.

 [1].
 https://github.com/wso2/dockerfiles/blob/master/common/scripts/entrypoint.sh#L87

 [2]. docker---init.sh

 On Mon, May 9, 2016 at 11:15 AM, Thanuja Uruththirakodeeswaran <
 thanu...@wso2.com> wrote:

> Hi All,
>
> When we try to run WSO2 MB docker image build using puppet
> provisioning with clustering enabled in kubernetes, I'm getting the below
> error  at the server startup:
>
> TID: [-1234] [] [2016-05-09 05:39:06,811] ERROR
> {org.wso2.andes.server.Main} -  Exception during startup. Triggering
> shutdown  {org.wso2.andes.server.Main}
> org.wso2.andes.kernel.AndesException: Unable to initialise application
> registry
> at org.wso2.andes.server.Broker.startupImpl(Broker.java:308)
> at org.wso2.andes.server.Broker.startup(Broker.java:110)
> at org.wso2.andes.server.Main.startBroker(Main.java:217)
> at org.wso2.andes.server.Main.execute(Main.java:206)
> at org.wso2.andes.server.Main.(Main.java:54)
> at org.wso2.andes.server.Main.main(Main.java:47)
> at
> org.wso2.carbon.andes.internal.QpidServiceComponent.startAndesBroker(QpidServiceComponent.java:391)
> at
> org.wso2.carbon.andes.internal.QpidServiceComponent.setHazelcastInstance(QpidServiceComponent.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.eclipse.equinox.internal.ds.model.ComponentReference.bind(ComponentReference.java:376)
> at
> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.bindReference(ServiceComponentProp.java:430)
> at
> org.eclipse.equinox.internal.ds.InstanceProcess.dynamicBind(InstanceProcess.java:416)
> at
> org.eclipse.equinox.internal.ds.Resolver.getEligible(Resolver.java:334)
> at
> org.eclipse.equinox.internal.ds.SCRManager.serviceChanged(SCRManager.java:222)
> at
> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
> at
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at
> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:771)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130)
> at
> org

Re: [Dev] [DEV][Puppet Modules] Unnecessary lookup for wso2::secure_vault_configs

[Thanuja Uruththirakodeeswaran]

Hi Chamila,

On Mon, May 9, 2016 at 1:50 PM, Chamila De Alwis  wrote:

> Hi,
>
> In wso2base/manifests/init.pp [1], we do a Hiera lookup
> for wso2::secure_vault_configs, without checking if SecureVault
> configurations are needed. IMO we should only do this lookup if the
> previous lookup for wso2::enable_secure_vault is true.
>

Yes, we need to do lookup for  wso2::secure_vault_configs only if secure
vault is enabled. Will do the needed changes.

Thanks.

Otherwise wso2::secure_vault_configs[key_store_password] has to be added
> even if SecureVault is not enabled.
>
> [1] -
> https://github.com/wso2/puppet-modules/blob/master/modules/wso2base/manifests/init.pp#L61-L63
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>


-- 
Thanuja Uruththirakodeeswaran
Software Engineer
WSO2 Inc.;http://wso2.com
lean.enterprise.middleware

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

Re: [Dev] [Docker][Puppet] [MB] Setting 'thriftServerHost' in WSO2 MB broker.xml file

[Akila Ravihansa Perera]

Hi Pumudu,

We can't use "%{::ipaddress}" in kubernetes platform since Puppet is only
used to build the Docker images. The ipaddress is assigned when the
Kubernetes pods/services are deployed.

I think best method would be to use the extension point as explained by
Isuru. This should be similar to how we replace the localMemberHost section
in axis2.xml.

Thanks.

On Mon, May 9, 2016 at 1:34 PM, Pumudu Ruhunage  wrote:

> Hi,
> AFAIU, Thrift hostname should be changed to IP from puppet modules when
> configuring hiera data[1]. Following line[2] should added to
> default.yaml[3] to get the IP when initializing.
>
> [1]
> https://github.com/wso2/puppet-modules/wiki/Creating-a-Puppet-Module-for-a-WSO2-Product#create-the-hiera-configuration-data-set
> [2] wso2::mb_thrift_hostname : "%{::ipaddress}"
> [3]
> https://github.com/wso2/puppet-modules/blob/master/hieradata/dev/wso2/wso2mb/3.1.0/kubernetes/default.yaml
>
> Thanks,
> Pumudu
>
> On Mon, May 9, 2016 at 12:08 PM, Akalanka Pagoda Arachchi <
> darsha...@wso2.com> wrote:
>
>> Hi Thanuja,
>>
>> As you have mentioned, the MB needs the IP address instead of the host
>> name to configure the Thrift server. So you will have to correct the thrift
>> server connection details mentioned in "wso2mb-default/
>> 10.100.186.164:7611".
>>
>> Thanks,
>> Akalanka.
>>
>> On Mon, May 9, 2016 at 11:31 AM, Isuru Haththotuwa 
>> wrote:
>>
>>> Hi Thanuja,
>>>
>>> There is an extension point [1] in the startup script for Dockerfiles,
>>> where is looks for another script with a particular name format to execute
>>> before starting the server. You should b able to use that to do a find
>>> replace in the broker.xml with the container IP.
>>>
>>> [1].
>>> https://github.com/wso2/dockerfiles/blob/master/common/scripts/entrypoint.sh#L87
>>>
>>> [2]. docker---init.sh
>>>
>>> On Mon, May 9, 2016 at 11:15 AM, Thanuja Uruththirakodeeswaran <
>>> thanu...@wso2.com> wrote:
>>>
 Hi All,

 When we try to run WSO2 MB docker image build using puppet provisioning
 with clustering enabled in kubernetes, I'm getting the below error  at the
 server startup:

 TID: [-1234] [] [2016-05-09 05:39:06,811] ERROR
 {org.wso2.andes.server.Main} -  Exception during startup. Triggering
 shutdown  {org.wso2.andes.server.Main}
 org.wso2.andes.kernel.AndesException: Unable to initialise application
 registry
 at org.wso2.andes.server.Broker.startupImpl(Broker.java:308)
 at org.wso2.andes.server.Broker.startup(Broker.java:110)
 at org.wso2.andes.server.Main.startBroker(Main.java:217)
 at org.wso2.andes.server.Main.execute(Main.java:206)
 at org.wso2.andes.server.Main.(Main.java:54)
 at org.wso2.andes.server.Main.main(Main.java:47)
 at
 org.wso2.carbon.andes.internal.QpidServiceComponent.startAndesBroker(QpidServiceComponent.java:391)
 at
 org.wso2.carbon.andes.internal.QpidServiceComponent.setHazelcastInstance(QpidServiceComponent.java:250)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at
 org.eclipse.equinox.internal.ds.model.ComponentReference.bind(ComponentReference.java:376)
 at
 org.eclipse.equinox.internal.ds.model.ServiceComponentProp.bindReference(ServiceComponentProp.java:430)
 at
 org.eclipse.equinox.internal.ds.InstanceProcess.dynamicBind(InstanceProcess.java:416)
 at
 org.eclipse.equinox.internal.ds.Resolver.getEligible(Resolver.java:334)
 at
 org.eclipse.equinox.internal.ds.SCRManager.serviceChanged(SCRManager.java:222)
 at
 org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
 at
 org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
 at
 org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
 at
 org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
 at
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
 at
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:771)
 at
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130)
 at
 org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:214)
 at
 org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:433)
 at
 org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:451)
 at
 org.eclipse.osgi.framework.internal.core

Re: [Dev] Fwd: [IS] Missing requirement in building product-is from source

[Malithi Edirisinghe]

Hi,

Is this being solved. I get the same error [1] when building on OS X
Yosemite. Also seems the same was discussed in [2] as well.

This was identified as a bug in felix plugin at [3]. Upgrading the
maven-scr-plugin to version 1.8.0 successfully built the respective
component. However, that does to build OSGI bundles properly.

Any idea on how to solve this issue?

[1] "[ERROR] Failed to execute goal org.apache.felix:maven-scr-plugin:1.7.2:scr
(generate-scr-scrdescriptor) on project org.wso2.carbon.identity.
application.authentication.framework: Execution generate-scr-scrdescriptor
of goal org.apache.felix:maven-scr-plugin:1.7.2:scr failed: Comparison
method violates its general contract! -> [Help 1]"
[2]"[Dev] [Carbon] Build fail in cerbon4-kernel source code."
[3] https://issues.apache.org/jira/browse/FELIX-3571

Thanks,
Malithi

On Mon, May 2, 2016 at 11:29 AM, Manujith Pallewatte 
wrote:

> Hi all,
>
> Just to update in case anyone else is having the issue, product-is didn't
> build on Ubuntu 16.04 (for reasons still not known) but build successfully
> in Ubuntu 14.04. Still having the above mentioned issue in
> identity-framework build though.
>
> Thanks!
>
> On Thu, Apr 28, 2016 at 9:26 AM, Manujith Pallewatte <
> manujith...@gmail.com> wrote:
>
>> Hi Chamila,
>>
>> I tried with maven 3.3 also with maven 3.0.5 as mentioned in the
>> requirements
>> I build product-is only before in a windows environment, with no issues,
>> but it didn't work in the current (ubuntu 16.04) environment
>> From the link above[1] i have all prerequisites other than svn, since I
>> clone from git i believe svn is of no use
>>
>>
>> [1]. https://docs.wso2.com/display/IS510/Installation+Prerequisites
>>
>>
>> On Wed, Apr 27, 2016 at 9:06 PM, Chamila Wijayarathna 
>> wrote:
>>
>>> [adding dev]
>>>
>>> identity-framework should build without any issues, what is the maven
>>> version you are using? Can you check if you have all the requirement
>>> mentioned at [1] for building the identity server from source code. Was
>>> this building successfully previously?
>>>
>>> [1]. https://docs.wso2.com/display/IS510/Installation+Prerequisites
>>>
>>> -- Forwarded message --
>>> From: Manujith Pallewatte 
>>> Date: Wed, Apr 27, 2016 at 7:49 PM
>>> Subject: Re: [IS] Missing requirement in building product-is from source
>>> To: Chamila Wijayarathna 
>>>
>>>
>>> Hi Chamila,
>>>
>>> Apparently identity framework didnt have the latest commits, I forked it
>>> today and pulled but It must have missed some commits
>>> Anyway I updated the local repo to all changes, but now identity
>>> framework gives an error in building
>>>
>>> "[ERROR] Failed to execute goal
>>> org.apache.felix:maven-scr-plugin:1.7.2:scr (generate-scr-scrdescriptor) on
>>> project org.wso2.carbon.identity.application.authentication.framework:
>>> Execution generate-scr-scrdescriptor of goal
>>> org.apache.felix:maven-scr-plugin:1.7.2:scr failed: Comparison method
>>> violates its general contract! -> [Help 1]"
>>>
>>> I google and found that this is a known bug of apache felix, but it
>>> didn't provide and solid way to solve other than to change jdk version
>>> I tried changing version with no luck, any ideas?
>>>
>>> Also found similar error in dev list
>>> http://mail.wso2.org/mailarchive/dev/2015-June/049912.html
>>>
>>> Thank You
>>>
>>> On Wed, Apr 27, 2016 at 4:46 PM, Chamila Wijayarathna 
>>> wrote:
>>>
 Hi Manujith,

 It seems like your identity-framework or product-is is not upto date.

 Can you check what are the latest commits in both repos using git log
 and check if commits merged within last few days are there in your local
 repo?

 Thank You!

 On Wed, Apr 27, 2016 at 3:56 PM, Manujith Pallewatte <
 manujith...@gmail.com> wrote:

> Hi all,
>
> I'm trying to setup the development environment to start working for
> GSOC on the identity server, and I already downloaded and build the
> carbon-identity-framework repo along with the extensions as mentioned in 
> [1]
>
> Now I'm trying to build product-is from source as well, to make sure I
> have all the dependencies before doing in changes to the source, but
> running maven install in product is gives the following error
>
> "Missing requirement: Application Authentication Framework Server
> Feature 5.0.9.SNAPSHOT
> (org.wso2.carbon.identity.application.authentication.framework.server.feature.group
> 5.0.9.SNAPSHOT) requires
> 'org.wso2.carbon.tenant.mgt.common.server.feature.group [4.4.8,4.5.0)' but
> it could not be found"
>
> I check the local maven repo and this package isnt available in it, so
> why is maven not downloading this from the remote repository?
>
> Thank You
>
>
> [1] https://gist.github.com/pulasthi7/3d365a3345371fd63f74
>
> --
>
>
>
> [image: Manujith Pallewatte on about.me]
>
> Manujith Palle

Re: [Dev] [PC] Getting user names from registry log entries

[Thushara Ranawaka]

Hi Sameera,

Even though test_user did 868, 869 and 870 activities the registry delegate
the process to wso2.system.user.
For example when you creating a soap service using WSDL soap service
creation entries are done by wso2.system.user.
However you should able to see actions done using test_user for process
assets under test_user. But not the automated ones done by wso2.system.user.
This is the behaviour and a known limitation in G-Reg. In your case you
need to write a new component to store these audit logs.


Thanks,
Thushara.


On Thu, May 5, 2016 at 6:51 PM, Sameera Gunarathne 
wrote:

> Hi all,
>
> I am trying to get user name for log entries by accessing REG_LOG table at
> the registry. There it is recorded as the wso2.system.user. I have created
> a separate user called "test_user" along with the "admin" user. The
> activities done by the "test_user" also recorded as the wso2.system.user at
> the REG_LOG.
>
>
> ​
> I need to know is there a way to get the user names for these log entries
> as it is created at the mgmt console?
> --
> Sameera Gunarathne
> Software Engineer, WSO2 Inc. http://wso2.com
> 
> Email: samee...@wso2.com
> Mobile: +94714155561
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Thanks,
Thushara Kasun Ranawaka
Software Engineer
WSO2 Inc.; 
lean.enterprise.middleware
Mobile : *+94 (0) 773438949*
*thusha...@wso2.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [DEV][Puppet Modules] Unnecessary lookup for wso2::secure_vault_configs

[Chamila De Alwis]

Hi,

In wso2base/manifests/init.pp [1], we do a Hiera lookup
for wso2::secure_vault_configs, without checking if SecureVault
configurations are needed. IMO we should only do this lookup if the
previous lookup for wso2::enable_secure_vault is true. Otherwise
wso2::secure_vault_configs[key_store_password] has to be added even if
SecureVault is not enabled.

[1] -
https://github.com/wso2/puppet-modules/blob/master/modules/wso2base/manifests/init.pp#L61-L63


Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [ESB 5.0.0][Mediation Debugger]After restarting debug process, it will not take previous debug points

[Praneesha Chandrasiri]

Updated the information given on the "Resend ESB Debug Points" option in
[1], to match the current implementation.

Thanks everyone!

[1] https://docs.wso2.com/display/ESB500/Debugging+Mediation

On Mon, May 9, 2016 at 1:24 PM, Dilshani Subasinghe 
wrote:

> Hi Chanaka,
>
> Added a jira [1] and +1 for fixing it with this release.
>
> [1] https://wso2.org/jira/browse/DEVTOOLESB-208
>
> Regards,
> Dilshani
>
>
> On Mon, May 9, 2016 at 1:00 PM, Nuwan Pallewela  wrote:
>
>> Hi Chanaka,
>>
>> This is not reported as a public JIRA yet.
>>
>> Thanks,
>> Nuwan
>>
>> On Mon, May 9, 2016 at 12:51 PM, Chanaka Fernando 
>> wrote:
>>
>>> Is there any public JIRA already created?
>>>
>>> On Mon, May 9, 2016 at 12:46 PM, Isabelle Mauny 
>>> wrote:
>>>
 +1 - Can we fix this in 5.0.0 …
 __

 Isabelle Mauny
 VP, Product Management; WSO2, Inc.;  http://wso2.com/

 On May 9, 2016, at 9:05 AM, Chathurika De Silva 
 wrote:

 Hi ESB Team

 Addition to dilshani' and nuwan's feedback, from user's perspective,
 when debug points are set and if the artifact is not changed, the need for
 him to resend debug point information is an additional task. Ideally it's
 better to give the same feel to a developer who is using this tool after
 using the general eclipse debugging (since we are based on eclipse). It's
 understandable that resend is needed when the artifact has changed, but if
 doesn't the developer should be able to start debugging without any extra
 effort from the tooling side. So is there any possibility in getting this
 fixed with this release rather than marking it as an improvement?

 Thank You
 Erandi

 On Mon, May 9, 2016 at 12:09 PM, Dilshani Subasinghe >>> > wrote:

> Hi ESB Team,
>
> After restarting debug process, it may not identify previously added
> debug points. But newly added ESB points will be added to debug process
> successfully.
>
> When we using the option "*Resend ESB Debug Points*", it may send
> previous debug points too.
>
> As Far As I Feel, this is bit of misleading and I also took much time
> to identify relevant option.
>
> What is the improvement you can do about that ?
>
> @Nisrin/Praneesha - As I seen in the blog post (
> https://nuwanpallewela.wordpress.com/2016/04/10/how-to-debug-wso2-esb-mediation-flow/),
> "*Resend ESB Debug Points*" will be useful when we changing the
> artifact. But in documentation it may just give explanation like "Sends
> all registered debugging points to the ESB Server".
>
> Hope it will be better to be more descriptive with relevant
> functionalities (Ex: When to use). Because user may confuse with exact
> options as they are having similar functionalities.
>
> Thank you
>
> --
> Best Regards,
>
> Dilshani Subasinghe
> Software Engineer - QA
> WSO2, Inc.;http://wso2.com/
> 
> lean.enterprise.middleware
> Mobile: +94773375185
> Blog: dilshanilive.blogspot.com
>



 --
 *Chathurika Erandi*
 Software Engineer,
 WSO2 Inc.

 *E-mail:* chathuri...@wso2.com
 *Mobile: *+94714 328 612
 *Blog*: chathurikaerandi.blogspot.com

 --
 You received this message because you are subscribed to the Google
 Groups "WSO2 Documentation Group" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to documentation+unsubscr...@wso2.com.
 For more options, visit https://groups.google.com/a/wso2.com/d/optout.



>>>
>>>
>>> --
>>> 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> --
>>
>> *Nuwan Chamara Pallewela*
>>
>>
>> *Software Engineer*
>>
>> *WSO2, Inc. *http://wso2.com
>> *lean . enterprise . middleware*
>>
>> Email   *nuw...@wso2.com *
>> Mobile  *+94719079739 <%2B94719079739>@*
>>
>>
>>
>
>
> --
> Best Regards,
>
> Dilshani Subasinghe
> Software Engineer - QA
> WSO2, Inc.;http://wso2.com/
> 
> lean.enterprise.middleware
> Mobile: +94773375185
> Blog: dilshanilive.blogspot.com
>



-- 
Thanks & Best Regards,
*Praneesha Chandrasiri*
*Technical Writer*
*WSO2 Inc. *
*Mobile: +(94) 718156888*
*E-mail: pranee...@wso2.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.or

Re: [Dev] [Docker][Puppet] [MB] Setting 'thriftServerHost' in WSO2 MB broker.xml file

[Pumudu Ruhunage]

Hi,
AFAIU, Thrift hostname should be changed to IP from puppet modules when
configuring hiera data[1]. Following line[2] should added to
default.yaml[3] to get the IP when initializing.

[1]
https://github.com/wso2/puppet-modules/wiki/Creating-a-Puppet-Module-for-a-WSO2-Product#create-the-hiera-configuration-data-set
[2] wso2::mb_thrift_hostname : "%{::ipaddress}"
[3]
https://github.com/wso2/puppet-modules/blob/master/hieradata/dev/wso2/wso2mb/3.1.0/kubernetes/default.yaml

Thanks,
Pumudu

On Mon, May 9, 2016 at 12:08 PM, Akalanka Pagoda Arachchi <
darsha...@wso2.com> wrote:

> Hi Thanuja,
>
> As you have mentioned, the MB needs the IP address instead of the host
> name to configure the Thrift server. So you will have to correct the thrift
> server connection details mentioned in "wso2mb-default/10.100.186.164:7611
> ".
>
> Thanks,
> Akalanka.
>
> On Mon, May 9, 2016 at 11:31 AM, Isuru Haththotuwa 
> wrote:
>
>> Hi Thanuja,
>>
>> There is an extension point [1] in the startup script for Dockerfiles,
>> where is looks for another script with a particular name format to execute
>> before starting the server. You should b able to use that to do a find
>> replace in the broker.xml with the container IP.
>>
>> [1].
>> https://github.com/wso2/dockerfiles/blob/master/common/scripts/entrypoint.sh#L87
>>
>> [2]. docker---init.sh
>>
>> On Mon, May 9, 2016 at 11:15 AM, Thanuja Uruththirakodeeswaran <
>> thanu...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> When we try to run WSO2 MB docker image build using puppet provisioning
>>> with clustering enabled in kubernetes, I'm getting the below error  at the
>>> server startup:
>>>
>>> TID: [-1234] [] [2016-05-09 05:39:06,811] ERROR
>>> {org.wso2.andes.server.Main} -  Exception during startup. Triggering
>>> shutdown  {org.wso2.andes.server.Main}
>>> org.wso2.andes.kernel.AndesException: Unable to initialise application
>>> registry
>>> at org.wso2.andes.server.Broker.startupImpl(Broker.java:308)
>>> at org.wso2.andes.server.Broker.startup(Broker.java:110)
>>> at org.wso2.andes.server.Main.startBroker(Main.java:217)
>>> at org.wso2.andes.server.Main.execute(Main.java:206)
>>> at org.wso2.andes.server.Main.(Main.java:54)
>>> at org.wso2.andes.server.Main.main(Main.java:47)
>>> at
>>> org.wso2.carbon.andes.internal.QpidServiceComponent.startAndesBroker(QpidServiceComponent.java:391)
>>> at
>>> org.wso2.carbon.andes.internal.QpidServiceComponent.setHazelcastInstance(QpidServiceComponent.java:250)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:606)
>>> at
>>> org.eclipse.equinox.internal.ds.model.ComponentReference.bind(ComponentReference.java:376)
>>> at
>>> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.bindReference(ServiceComponentProp.java:430)
>>> at
>>> org.eclipse.equinox.internal.ds.InstanceProcess.dynamicBind(InstanceProcess.java:416)
>>> at
>>> org.eclipse.equinox.internal.ds.Resolver.getEligible(Resolver.java:334)
>>> at
>>> org.eclipse.equinox.internal.ds.SCRManager.serviceChanged(SCRManager.java:222)
>>> at
>>> org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:107)
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:861)
>>> at
>>> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
>>> at
>>> org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
>>> at
>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:819)
>>> at
>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:771)
>>> at
>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130)
>>> at
>>> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:214)
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:433)
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:451)
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:950)
>>> at
>>> org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent.init(HazelcastClusteringAgent.java:258)
>>> at
>>> org.wso2.carbon.core.util.ClusteringUtil.enableClustering(ClusteringUtil.java:38)
>>> at
>>> org.wso2.carbon.core.internal.StartupFinalizerServiceComponent.completeInitialization(StartupFinalizerServiceComponent.java:177)
>>> at
>>> org.wso2.carbon.core.internal.StartupFinalizerServiceComponent.serviceChanged(StartupFinalizerServiceComponent.java

Re: [Dev] [ESB 5.0.0][Mediation Debugger]After restarting debug process, it will not take previous debug points

[Dilshani Subasinghe]

Hi Chanaka,

Added a jira [1] and +1 for fixing it with this release.

[1] https://wso2.org/jira/browse/DEVTOOLESB-208

Regards,
Dilshani


On Mon, May 9, 2016 at 1:00 PM, Nuwan Pallewela  wrote:

> Hi Chanaka,
>
> This is not reported as a public JIRA yet.
>
> Thanks,
> Nuwan
>
> On Mon, May 9, 2016 at 12:51 PM, Chanaka Fernando 
> wrote:
>
>> Is there any public JIRA already created?
>>
>> On Mon, May 9, 2016 at 12:46 PM, Isabelle Mauny 
>> wrote:
>>
>>> +1 - Can we fix this in 5.0.0 …
>>> __
>>>
>>> Isabelle Mauny
>>> VP, Product Management; WSO2, Inc.;  http://wso2.com/
>>>
>>> On May 9, 2016, at 9:05 AM, Chathurika De Silva 
>>> wrote:
>>>
>>> Hi ESB Team
>>>
>>> Addition to dilshani' and nuwan's feedback, from user's perspective,
>>> when debug points are set and if the artifact is not changed, the need for
>>> him to resend debug point information is an additional task. Ideally it's
>>> better to give the same feel to a developer who is using this tool after
>>> using the general eclipse debugging (since we are based on eclipse). It's
>>> understandable that resend is needed when the artifact has changed, but if
>>> doesn't the developer should be able to start debugging without any extra
>>> effort from the tooling side. So is there any possibility in getting this
>>> fixed with this release rather than marking it as an improvement?
>>>
>>> Thank You
>>> Erandi
>>>
>>> On Mon, May 9, 2016 at 12:09 PM, Dilshani Subasinghe 
>>>  wrote:
>>>
 Hi ESB Team,

 After restarting debug process, it may not identify previously added
 debug points. But newly added ESB points will be added to debug process
 successfully.

 When we using the option "*Resend ESB Debug Points*", it may send
 previous debug points too.

 As Far As I Feel, this is bit of misleading and I also took much time
 to identify relevant option.

 What is the improvement you can do about that ?

 @Nisrin/Praneesha - As I seen in the blog post (
 https://nuwanpallewela.wordpress.com/2016/04/10/how-to-debug-wso2-esb-mediation-flow/),
 "*Resend ESB Debug Points*" will be useful when we changing the
 artifact. But in documentation it may just give explanation like "Sends
 all registered debugging points to the ESB Server".

 Hope it will be better to be more descriptive with relevant
 functionalities (Ex: When to use). Because user may confuse with exact
 options as they are having similar functionalities.

 Thank you

 --
 Best Regards,

 Dilshani Subasinghe
 Software Engineer - QA
 WSO2, Inc.;http://wso2.com/
 
 lean.enterprise.middleware
 Mobile: +94773375185
 Blog: dilshanilive.blogspot.com

>>>
>>>
>>>
>>> --
>>> *Chathurika Erandi*
>>> Software Engineer,
>>> WSO2 Inc.
>>>
>>> *E-mail:* chathuri...@wso2.com
>>> *Mobile: *+94714 328 612
>>> *Blog*: chathurikaerandi.blogspot.com
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "WSO2 Documentation Group" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to documentation+unsubscr...@wso2.com.
>>> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>>>
>>>
>>>
>>
>>
>> --
>> 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
>>
>>
>>
>>
>>
>
>
> --
> --
>
> *Nuwan Chamara Pallewela*
>
>
> *Software Engineer*
>
> *WSO2, Inc. *http://wso2.com
> *lean . enterprise . middleware*
>
> Email   *nuw...@wso2.com *
> Mobile  *+94719079739 <%2B94719079739>@*
>
>
>


-- 
Best Regards,

Dilshani Subasinghe
Software Engineer - QA
WSO2, Inc.;http://wso2.com/

lean.enterprise.middleware
Mobile: +94773375185
Blog: dilshanilive.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [ESB 5.0.0][Mediation Debugger]After restarting debug process, it will not take previous debug points

[Nuwan Pallewela]

Hi Chanaka,

This is not reported as a public JIRA yet.

Thanks,
Nuwan

On Mon, May 9, 2016 at 12:51 PM, Chanaka Fernando  wrote:

> Is there any public JIRA already created?
>
> On Mon, May 9, 2016 at 12:46 PM, Isabelle Mauny  wrote:
>
>> +1 - Can we fix this in 5.0.0 …
>> __
>>
>> Isabelle Mauny
>> VP, Product Management; WSO2, Inc.;  http://wso2.com/
>>
>> On May 9, 2016, at 9:05 AM, Chathurika De Silva 
>> wrote:
>>
>> Hi ESB Team
>>
>> Addition to dilshani' and nuwan's feedback, from user's perspective, when
>> debug points are set and if the artifact is not changed, the need for him
>> to resend debug point information is an additional task. Ideally it's
>> better to give the same feel to a developer who is using this tool after
>> using the general eclipse debugging (since we are based on eclipse). It's
>> understandable that resend is needed when the artifact has changed, but if
>> doesn't the developer should be able to start debugging without any extra
>> effort from the tooling side. So is there any possibility in getting this
>> fixed with this release rather than marking it as an improvement?
>>
>> Thank You
>> Erandi
>>
>> On Mon, May 9, 2016 at 12:09 PM, Dilshani Subasinghe 
>> wrote:
>>
>>> Hi ESB Team,
>>>
>>> After restarting debug process, it may not identify previously added
>>> debug points. But newly added ESB points will be added to debug process
>>> successfully.
>>>
>>> When we using the option "*Resend ESB Debug Points*", it may send
>>> previous debug points too.
>>>
>>> As Far As I Feel, this is bit of misleading and I also took much time to
>>> identify relevant option.
>>>
>>> What is the improvement you can do about that ?
>>>
>>> @Nisrin/Praneesha - As I seen in the blog post (
>>> https://nuwanpallewela.wordpress.com/2016/04/10/how-to-debug-wso2-esb-mediation-flow/),
>>> "*Resend ESB Debug Points*" will be useful when we changing the
>>> artifact. But in documentation it may just give explanation like "Sends
>>> all registered debugging points to the ESB Server".
>>>
>>> Hope it will be better to be more descriptive with relevant
>>> functionalities (Ex: When to use). Because user may confuse with exact
>>> options as they are having similar functionalities.
>>>
>>> Thank you
>>>
>>> --
>>> Best Regards,
>>>
>>> Dilshani Subasinghe
>>> Software Engineer - QA
>>> WSO2, Inc.;http://wso2.com/
>>> 
>>> lean.enterprise.middleware
>>> Mobile: +94773375185
>>> Blog: dilshanilive.blogspot.com
>>>
>>
>>
>>
>> --
>> *Chathurika Erandi*
>> Software Engineer,
>> WSO2 Inc.
>>
>> *E-mail:* chathuri...@wso2.com
>> *Mobile: *+94714 328 612
>> *Blog*: chathurikaerandi.blogspot.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "WSO2 Documentation Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to documentation+unsubscr...@wso2.com.
>> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>>
>>
>>
>
>
> --
> 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
>
>
>
>
>


-- 
--

*Nuwan Chamara Pallewela*


*Software Engineer*

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

Email   *nuw...@wso2.com *
Mobile  *+94719079739@*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [ESB 5.0.0][Mediation Debugger]After restarting debug process, it will not take previous debug points

[Chanaka Fernando]

Is there any public JIRA already created?

On Mon, May 9, 2016 at 12:46 PM, Isabelle Mauny  wrote:

> +1 - Can we fix this in 5.0.0 …
> __
>
> Isabelle Mauny
> VP, Product Management; WSO2, Inc.;  http://wso2.com/
>
> On May 9, 2016, at 9:05 AM, Chathurika De Silva 
> wrote:
>
> Hi ESB Team
>
> Addition to dilshani' and nuwan's feedback, from user's perspective, when
> debug points are set and if the artifact is not changed, the need for him
> to resend debug point information is an additional task. Ideally it's
> better to give the same feel to a developer who is using this tool after
> using the general eclipse debugging (since we are based on eclipse). It's
> understandable that resend is needed when the artifact has changed, but if
> doesn't the developer should be able to start debugging without any extra
> effort from the tooling side. So is there any possibility in getting this
> fixed with this release rather than marking it as an improvement?
>
> Thank You
> Erandi
>
> On Mon, May 9, 2016 at 12:09 PM, Dilshani Subasinghe 
> wrote:
>
>> Hi ESB Team,
>>
>> After restarting debug process, it may not identify previously added
>> debug points. But newly added ESB points will be added to debug process
>> successfully.
>>
>> When we using the option "*Resend ESB Debug Points*", it may send
>> previous debug points too.
>>
>> As Far As I Feel, this is bit of misleading and I also took much time to
>> identify relevant option.
>>
>> What is the improvement you can do about that ?
>>
>> @Nisrin/Praneesha - As I seen in the blog post (
>> https://nuwanpallewela.wordpress.com/2016/04/10/how-to-debug-wso2-esb-mediation-flow/),
>> "*Resend ESB Debug Points*" will be useful when we changing the
>> artifact. But in documentation it may just give explanation like "Sends
>> all registered debugging points to the ESB Server".
>>
>> Hope it will be better to be more descriptive with relevant
>> functionalities (Ex: When to use). Because user may confuse with exact
>> options as they are having similar functionalities.
>>
>> Thank you
>>
>> --
>> Best Regards,
>>
>> Dilshani Subasinghe
>> Software Engineer - QA
>> WSO2, Inc.;http://wso2.com/
>> 
>> lean.enterprise.middleware
>> Mobile: +94773375185
>> Blog: dilshanilive.blogspot.com
>>
>
>
>
> --
> *Chathurika Erandi*
> Software Engineer,
> WSO2 Inc.
>
> *E-mail:* chathuri...@wso2.com
> *Mobile: *+94714 328 612
> *Blog*: chathurikaerandi.blogspot.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "WSO2 Documentation Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to documentation+unsubscr...@wso2.com.
> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>
>
>


-- 
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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Chamila De Alwis]

+1, IMO that's better since now it's clear how what kubernetes.yaml stands
for.


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



On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera 
wrote:

> Hi Chamila,
>
> Agreed. I don't think there would be anymore files in addition to
> common.yaml here. How about moving this to root level; for eg:
> "platform/kubernetes.yaml" ?
>
> Full Hierarchy will be as follows;
>
> :hierarchy:
> - "node/%{::clientcert}"
> - 
> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
> - "platform/%{::platform}"
> - "osfamily/%{::osfamily}"
> - wso2/common
> - common
> :backends:
> - yaml
> :yaml:
> :datadir: "hieradata/%{::environment}"
>
>
> Thanks.
>
>
> On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis 
> wrote:
>
>> +1
>>
>> How about wso2/kubernetes.yaml instead of wso2/kubernetes/common.yaml?
>> Will there be a YAML file in addition to the common.yaml?
>>
>> - "wso2/%{::platform}"
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> We recently introduced a facter named "platform" to denote a PaaS
>>> framework or cluster management system on which WSO2 products could be
>>> deployed. With this addition I feel there is no reason to keep -
>>> "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
>>> configuration parameters that is common across all the products for a
>>> specific platform.
>>>
>>> For eg: In Kubernetes platform, we need to copy the Kubernetes
>>> membership scheme and related dependency jars for all the products. Also we
>>> need to set the installation dir to "/mnt" (instead of "/mnt/%{ipaddress}"
>>> because ipaddress is not available at the image build time.
>>>
>>> Therefore I'd like to propose that we include the
>>> "wso2/%{platform}/common" to the hierarchy. Full hiera.yaml would look like
>>> this;
>>>
>>> :hierarchy:
>>> - "node/%{::clientcert}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>>> - "wso2/%{::platform}/common"
>>> - wso2/common
>>> - "osfamily/%{::osfamily}"
>>> - common
>>> :backends:
>>> - yaml
>>> :yaml:
>>> :datadir: "hieradata/%{::environment}"
>>>
>>>
>>> Any thoughts?
>>>
>>> Thanks.
>>>
>>> --
>>> Akila Ravihansa Perera
>>> WSO2 Inc.;  http://wso2.com/
>>>
>>> Blog: http://ravihansa3000.blogspot.com
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>
>
> --
> Akila Ravihansa Perera
> WSO2 Inc.;  http://wso2.com/
>
> Blog: http://ravihansa3000.blogspot.com
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [ESB 5.0.0][Mediation Debugger]After restarting debug process, it will not take previous debug points

[Isabelle Mauny]

+1 - Can we fix this in 5.0.0 … 
__

Isabelle Mauny
VP, Product Management; WSO2, Inc.;  http://wso2.com/
> On May 9, 2016, at 9:05 AM, Chathurika De Silva  wrote:
> 
> Hi ESB Team
> 
> Addition to dilshani' and nuwan's feedback, from user's perspective, when 
> debug points are set and if the artifact is not changed, the need for him to 
> resend debug point information is an additional task. Ideally it's better to 
> give the same feel to a developer who is using this tool after using the 
> general eclipse debugging (since we are based on eclipse). It's 
> understandable that resend is needed when the artifact has changed, but if 
> doesn't the developer should be able to start debugging without any extra 
> effort from the tooling side. So is there any possibility in getting this 
> fixed with this release rather than marking it as an improvement?
> 
> Thank You
> Erandi
> 
> On Mon, May 9, 2016 at 12:09 PM, Dilshani Subasinghe  > wrote:
> Hi ESB Team,
> 
> After restarting debug process, it may not identify previously added debug 
> points. But newly added ESB points will be added to debug process 
> successfully.
> 
> When we using the option "Resend ESB Debug Points", it may send previous 
> debug points too. 
> 
> As Far As I Feel, this is bit of misleading and I also took much time to 
> identify relevant option. 
> 
> What is the improvement you can do about that ? 
> 
> @Nisrin/Praneesha - As I seen in the blog post 
> (https://nuwanpallewela.wordpress.com/2016/04/10/how-to-debug-wso2-esb-mediation-flow/
>  
> ),
>  "Resend ESB Debug Points" will be useful when we changing the artifact. But 
> in documentation it may just give explanation like "Sends all registered 
> debugging points to the ESB Server". 
> 
> Hope it will be better to be more descriptive with relevant functionalities 
> (Ex: When to use). Because user may confuse with exact options as they are 
> having similar functionalities. 
> 
> Thank you
> 
> -- 
> Best Regards,
> 
> Dilshani Subasinghe
> Software Engineer - QA
> WSO2, Inc.;http://wso2.com/ 
> 
> lean.enterprise.middleware  
> Mobile: +94773375185 
> Blog: dilshanilive.blogspot.com 
> 
> 
> 
> -- 
> Chathurika Erandi
> Software Engineer, 
> WSO2 Inc.
> 
> E-mail: chathuri...@wso2.com 
> Mobile: +94714 328 612
>  <>
> Blog: chathurikaerandi.blogspot.com 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "WSO2 Documentation Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to documentation+unsubscr...@wso2.com 
> .
> For more options, visit https://groups.google.com/a/wso2.com/d/optout 
> .

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

Re: [Dev] [DS] Adding same child for two different parents in WSO2 permission tree

[Sinthuja Ragendran]

Hi Megala,

>From the dashboard server point of view, we just need to have permission
tree as,

- Portal
  - Login
  - Dashboard
 - Create
 - Delete
 - Settings

In this model, the create permission is required for the user to create the
dashboard, and similarly for other operations. We don't need to have the
designer/viewer permissions in this level, because we the design and
viewers are being assigned per dashboard and hence we can't globally
control with permission.

Thanks,
Sinthuja.

On Sat, May 7, 2016 at 3:31 PM, Megala Uthayakumar  wrote:

> Hi All,
>
> I am working on adding a permission model for Dashboard Server. I came
> across following requirement.
>
> Assume there is a permission for accessing designer portal of DS
> ("Designer-Portal"). Among the users who have "Designer-Portal" permission,
> only some are provided with the "Create-Dashboard" and "Delete-Dashboard"
> permission. AFAIU according to wso2 permission tree, we need to add
> "Design-Portal" permission as a child for both "Create-Dashboard" and
> "Delete-Dashboard" parents. But in that case, there will be two different
> permissions for accessing same designer portal. I think, it is not correct
> to provide the same accessing capabilities using two different permission
> level settings.
>
> Is there any way, such that permission tree can have the same child for
> two different parents? Any suggestions on this is highly appreciated.
>
> Thanks
>
> Regards,
> Megala
>
> --
> Megala Uthayakumar
>
> Software Engineer
> Mobile : 0779967122
>



-- 
*Sinthuja Rajendran*
Associate 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] [ESB 5.0.0][Mediation Debugger]After restarting debug process, it will not take previous debug points

[Chathurika De Silva]

Hi ESB Team

Addition to dilshani' and nuwan's feedback, from user's perspective, when
debug points are set and if the artifact is not changed, the need for him
to resend debug point information is an additional task. Ideally it's
better to give the same feel to a developer who is using this tool after
using the general eclipse debugging (since we are based on eclipse). It's
understandable that resend is needed when the artifact has changed, but if
doesn't the developer should be able to start debugging without any extra
effort from the tooling side. So is there any possibility in getting this
fixed with this release rather than marking it as an improvement?

Thank You
Erandi

On Mon, May 9, 2016 at 12:09 PM, Dilshani Subasinghe 
wrote:

> Hi ESB Team,
>
> After restarting debug process, it may not identify previously added debug
> points. But newly added ESB points will be added to debug process
> successfully.
>
> When we using the option "*Resend ESB Debug Points*", it may send
> previous debug points too.
>
> As Far As I Feel, this is bit of misleading and I also took much time to
> identify relevant option.
>
> What is the improvement you can do about that ?
>
> @Nisrin/Praneesha - As I seen in the blog post (
> https://nuwanpallewela.wordpress.com/2016/04/10/how-to-debug-wso2-esb-mediation-flow/),
> "*Resend ESB Debug Points*" will be useful when we changing the artifact.
> But in documentation it may just give explanation like "Sends all
> registered debugging points to the ESB Server".
>
> Hope it will be better to be more descriptive with relevant
> functionalities (Ex: When to use). Because user may confuse with exact
> options as they are having similar functionalities.
>
> Thank you
>
> --
> Best Regards,
>
> Dilshani Subasinghe
> Software Engineer - QA
> WSO2, Inc.;http://wso2.com/
> 
> lean.enterprise.middleware
> Mobile: +94773375185
> Blog: dilshanilive.blogspot.com
>



-- 
*Chathurika Erandi*
Software Engineer,
WSO2 Inc.

*E-mail:* chathuri...@wso2.com
*Mobile: *+94714 328 612
*Blog*: chathurikaerandi.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [ESB 5.0.0][Mediation Debugger]After restarting debug process, it will not take previous debug points

[Nuwan Pallewela]

Hi Dilshani,

Thank you for pointing out this. ESB will forget the registered debug
points when synapse configuration changes or server gets restarts. So when
one of those happens user need to use the  *"Resend ESB Debug Points"*
command to re-register the debug-points in the server.

But I think we need to do this improvement in ESB side. We should send the
registered debug-points automatically when user connects esb server in
debug mode with esb tool or synapse configuration changes in the server.

Thanks,
Nuwan

On Mon, May 9, 2016 at 12:09 PM, Dilshani Subasinghe 
wrote:

> Hi ESB Team,
>
> After restarting debug process, it may not identify previously added debug
> points. But newly added ESB points will be added to debug process
> successfully.
>
> When we using the option "*Resend ESB Debug Points*", it may send
> previous debug points too.
>
> As Far As I Feel, this is bit of misleading and I also took much time to
> identify relevant option.
>
> What is the improvement you can do about that ?
>
> @Nisrin/Praneesha - As I seen in the blog post (
> https://nuwanpallewela.wordpress.com/2016/04/10/how-to-debug-wso2-esb-mediation-flow/),
> "*Resend ESB Debug Points*" will be useful when we changing the artifact.
> But in documentation it may just give explanation like "Sends all
> registered debugging points to the ESB Server".
>
> Hope it will be better to be more descriptive with relevant
> functionalities (Ex: When to use). Because user may confuse with exact
> options as they are having similar functionalities.
>
> Thank you
>
> --
> Best Regards,
>
> Dilshani Subasinghe
> Software Engineer - QA
> WSO2, Inc.;http://wso2.com/
> 
> lean.enterprise.middleware
> Mobile: +94773375185
> Blog: dilshanilive.blogspot.com
>



-- 
--

*Nuwan Chamara Pallewela*


*Software Engineer*

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

Email   *nuw...@wso2.com *
Mobile  *+94719079739@*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev