[Dev] Create a gadget via REST datasource

[Amalka Subasinghe]

Hi,

I want to create a gadget in DAS via rest datasource
What are the urls I need to provide for Data Retrieve URL * and Schema
Retrieve URL * ?

I want execute following kind of queries
curl -GET 'http://wso2.influxdb.com:32086/query?pretty=true'
--data-urlencode "db=k8s" --data-urlencode "q=SHOW MEASUREMENTS"

Please help

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

Re: [Dev] Create a gadget via REST datasource

[Dunith Dhanushka]

+Geesara

On Wed, Sep 7, 2016 at 1:24 PM, Amalka Subasinghe  wrote:

>
> Hi,
>
> I want to create a gadget in DAS via rest datasource
> What are the urls I need to provide for Data Retrieve URL * and Schema
> Retrieve URL * ?
>
> I want execute following kind of queries
> curl -GET 'http://wso2.influxdb.com:32086/query?pretty=true'
> --data-urlencode "db=k8s" --data-urlencode "q=SHOW MEASUREMENTS"
>
> Please help
>
> Thanks
> Amalka
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Regards,

Dunith Dhanushka,
Associate Technical Lead
WSO2 Inc,

Mobile - +94 71 8615744
Blog - *https://medium.com/@dunithd *
Twitter - @dunithd 
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] ISSUE IN CREATING PROXY SERVICE FOR HL7 IN ESB 5.0.0

[Amutheezan Sivagnanam]

Hi,
I am doing HL7 Monitoring Solution Project, for part of initial study I
need to configure HL7 for DAS. For this I tried ESB 4.8.1 and ESB 4.9.0, it
successfully publish data to DAS, but when I tried with ESB 5.0.0, It makes
the proxy-service  which I used for other version(ESB 4.8.1, ESB 4.9.0) to
disabled. I have attached the "error log" which I received while creating
proxy-service.

Regards,
S.Amutheezan
-- 
S.Amutheezan
*Software Engineering Intern*
Mobile : +94 76 771 1924
amuthee...@wso2.com
Public Profile : 







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

Re: [Dev] [Architecture] [VOTE] Release WSO2 Machine Learner 1.2.0 RC1

[Nirmal Fernando]

[+] Stable - go ahead and release

On Tue, Sep 6, 2016 at 6:09 PM, Supun Sethunga  wrote:

> Hi Devs,
>
> This is the 1st Release Candidate of the WSO2 Machine Learner 1.2.0. This
> release includes the  following improvements and fixes:
>
>- ML-DAS integration
>- Spark upgrade to v1.6.2
>- Security fixes associated with the WSO2 Carbon 4.4.9 platform release
>
>
> Please download, test the product and vote. Vote will be open for 72 hours
> or as needed.
> Refer to github readme for guides.
>
> The distribution is available to download at [1].
>
> Fixed Issue in [2]. Tag to be vote upon [3].
>
> [1] https://github.com/wso2/product-ml/releases/download/
> v1.2.0-rc1/wso2ml-1.2.0-rc1.zip
> [2] https://wso2.org/jira/issues/?filter=13325
> [3] https://github.com/wso2/product-ml/releases/tag/v1.2.0-rc1
>
> Please vote as follows.
> [+] Stable - go ahead and release
> [-]  Broken - do not release (please explain why)
>
> Thanks,
> WSO2 ML Team
>
> --
> *Supun Sethunga*
> Senior Software Engineer
> WSO2, Inc.
> http://wso2.com/
> lean | enterprise | middleware
> Mobile : +94 716546324
> Blog: http://supunsetunga.blogspot.com
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

Thanks & regards,
Nirmal

Team Lead - WSO2 Machine Learner
Associate Technical Lead - Data Technologies Team, WSO2 Inc.
Mobile: +94715779733
Blog: http://nirmalfdo.blogspot.com/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [IoTs][IOT] How to write plugin api to receive photo uploaded from device with python agent

[云展智创]

Hi team,

Does anyone have written a sample IoTS plugins with an api to receive photo 
uploaded from device with python agent? And api to be used by APP to get the 
uploaded photo in IoTS.

Could you guide me how to write these rest apis for post and get photos in IoTS 
plugins?

Thanks.

－－
Zhanwen Zhou (Jason)
+86 13922218435
zhanwen.z...@smartcloudex.com
Guangzhou Smart Cloudex Technology Co., Ltd.
Business: IOT, API Management

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

[Dev] [Puppet] Deep dive into WSO2 Puppet module implementation

[Akila Ravihansa Perera]

Hi,

This thread is to raise awareness around some of the implementation level
decisions that were taken when refactoring Puppet modules and splitting
them into their own respective GitHub repos.

* - Decouple Hiera from Puppet modules*
In last Puppet-Modules release Hiera lookups were done in /manifests/init.pp which made it mandatory for users to use Hiera.
As part of the refactoring Hiera is made optional and configuration
parameters are defined as class parameters which can be passed by site.pp


* - Use Hiera only as a data store*
There were some discussions about creating hooks in Puppet manifest to
which Puppet resources can be plugged in via Hiera data. However, going
forward we have come to a conclusion that Hiera should only be used as a
data store and nothing more. Any customizations to Puppet manifest can be
done directly in init.pp.

* - Break Puppet configurations into stages*
We have identified following stages which can be considered completely
independent from each other;
system - set operating system configs, install packages etc.
clean - remove any existing installation
install - extract the pack and set user permissions
configure - populate templates, copy config files, import certs
service - start the service

Here is a snippet of wso2as/manifests/init.pp

contain wso2base
contain wso2base::system
contain wso2base::clean
contain wso2base::install
contain wso2base::configure
contain wso2base::service

Class['::wso2base'] -> Class['::wso2base::system']
-> Class['::wso2base::clean'] -> Class['::wso2base::install']
-> Class['::wso2base::configure'] ~> Class['::wso2base::service']

As you can see Puppet class containment [1] is used to ensure the
dependency ordering. This is useful when users combine WSO2 Puppet modules
with other modules (for eg: when creating roles and profiles).

* - Remove inter module class inheritance*
As per official Puppet docs class inheritance is to be avoided whenever
possible [2]. Considering this we have removed all such relationships
except for params.pp which contains default values.

* - Move default values to params.pp and remove wso2base/params.pp*
After giving much thought, we decided to keep default values in
/manifests/params.pp and only in that place. Having common
default values in /manifests/params.pp would minimize duplication
but would be less readable for end users. Therefore we have come to a
conclusion that wso2base module should only be used as a common
resources/classes pool. It should not contain any data.

*Try it out!*

1. Git clone https://github.com/wso2/puppet-common
2. Run puppet-common/setup.sh -p as
3. Goto puppet-common/vagrant
4. Run vagrant up


[1]
https://docs.puppet.com/puppet/latest/reference/lang_containment.html#containing-classes
[2] https://docs.puppet.com/guides/style_guide.html#class-inheritance

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

Re: [Dev] [Architecture] [VOTE] Release WSO2 Machine Learner 1.2.0 RC1

[Supun Sethunga]

Tested all the samples.

[+] Stable - go ahead and release



On Wed, Sep 7, 2016 at 1:55 PM, Nirmal Fernando  wrote:

> [+] Stable - go ahead and release
>
> On Tue, Sep 6, 2016 at 6:09 PM, Supun Sethunga  wrote:
>
>> Hi Devs,
>>
>> This is the 1st Release Candidate of the WSO2 Machine Learner 1.2.0. This
>> release includes the  following improvements and fixes:
>>
>>- ML-DAS integration
>>- Spark upgrade to v1.6.2
>>- Security fixes associated with the WSO2 Carbon 4.4.9 platform
>>release
>>
>>
>> Please download, test the product and vote. Vote will be open for 72
>> hours or as needed.
>> Refer to github readme for guides.
>>
>> The distribution is available to download at [1].
>>
>> Fixed Issue in [2]. Tag to be vote upon [3].
>>
>> [1] https://github.com/wso2/product-ml/releases/download/v1.
>> 2.0-rc1/wso2ml-1.2.0-rc1.zip
>> [2] https://wso2.org/jira/issues/?filter=13325
>> [3] https://github.com/wso2/product-ml/releases/tag/v1.2.0-rc1
>>
>> Please vote as follows.
>> [+] Stable - go ahead and release
>> [-]  Broken - do not release (please explain why)
>>
>> Thanks,
>> WSO2 ML Team
>>
>> --
>> *Supun Sethunga*
>> Senior Software Engineer
>> WSO2, Inc.
>> http://wso2.com/
>> lean | enterprise | middleware
>> Mobile : +94 716546324
>> Blog: http://supunsetunga.blogspot.com
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> Thanks & regards,
> Nirmal
>
> Team Lead - WSO2 Machine Learner
> Associate Technical Lead - Data Technologies Team, WSO2 Inc.
> Mobile: +94715779733
> Blog: http://nirmalfdo.blogspot.com/
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Supun Sethunga*
Senior Software Engineer
WSO2, Inc.
http://wso2.com/
lean | enterprise | middleware
Mobile : +94 716546324
Blog: http://supunsetunga.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [VOTE] Release WSO2 Machine Learner 1.2.0 RC1

[Upul Bandara]

+1 for CEP Extension

On Wed, Sep 7, 2016 at 2:59 PM, Supun Sethunga  wrote:

> Tested all the samples.
>
> [+] Stable - go ahead and release
>
>
>
> On Wed, Sep 7, 2016 at 1:55 PM, Nirmal Fernando  wrote:
>
>> [+] Stable - go ahead and release
>>
>> On Tue, Sep 6, 2016 at 6:09 PM, Supun Sethunga  wrote:
>>
>>> Hi Devs,
>>>
>>> This is the 1st Release Candidate of the WSO2 Machine Learner 1.2.0. This
>>> release includes the  following improvements and fixes:
>>>
>>>- ML-DAS integration
>>>- Spark upgrade to v1.6.2
>>>- Security fixes associated with the WSO2 Carbon 4.4.9 platform
>>>release
>>>
>>>
>>> Please download, test the product and vote. Vote will be open for 72
>>> hours or as needed.
>>> Refer to github readme for guides.
>>>
>>> The distribution is available to download at [1].
>>>
>>> Fixed Issue in [2]. Tag to be vote upon [3].
>>>
>>> [1] https://github.com/wso2/product-ml/releases/download/v1.
>>> 2.0-rc1/wso2ml-1.2.0-rc1.zip
>>> [2] https://wso2.org/jira/issues/?filter=13325
>>> [3] https://github.com/wso2/product-ml/releases/tag/v1.2.0-rc1
>>>
>>> Please vote as follows.
>>> [+] Stable - go ahead and release
>>> [-]  Broken - do not release (please explain why)
>>>
>>> Thanks,
>>> WSO2 ML Team
>>>
>>> --
>>> *Supun Sethunga*
>>> Senior Software Engineer
>>> WSO2, Inc.
>>> http://wso2.com/
>>> lean | enterprise | middleware
>>> Mobile : +94 716546324
>>> Blog: http://supunsetunga.blogspot.com
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> Thanks & regards,
>> Nirmal
>>
>> Team Lead - WSO2 Machine Learner
>> Associate Technical Lead - Data Technologies Team, WSO2 Inc.
>> Mobile: +94715779733
>> Blog: http://nirmalfdo.blogspot.com/
>>
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Supun Sethunga*
> Senior Software Engineer
> WSO2, Inc.
> http://wso2.com/
> lean | enterprise | middleware
> Mobile : +94 716546324
> Blog: http://supunsetunga.blogspot.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Upul Bandara,
Associate Technical Lead, WSO2, Inc.,
Mob: +94 715 468 345.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [puppet] Setting up puppet home from script

[Anuruddha Liyanarachchi]

Hi Imesh,

I have now added the ability to configure multiple products using comma
separated product list.
Also included '-p all' option which configures all the products.

Ex: ./setup.sh -p as
Ex: ./setup.sh -p as,esb,bps
Ex: ./setup.sh -p all

On Wed, Sep 7, 2016 at 12:46 AM, Imesh Gunaratne  wrote:

> Great work Anuruddha! The bash script works well!
>
> Shall we add the ability to install multiple product modules in one go?
> Maybe we can use a comma separated product list with -p.
>
> Thanks
>
> On Tue, Sep 6, 2016 at 6:26 PM, Anuruddha Liyanarachchi <
> anurudd...@wso2.com> wrote:
>
>> Hi,
>>
>> We have  created separate GitHub repos for Puppet modules so that the
>> Puppet module can be shipped as part of a product release.
>>
>> Since modules are distributed we have introduced a script to generate
>> PUPPET_HOME. The script will work as following.
>>
>>  1. Check puppet_home folder exists.
>>
>>  2. Create folder structure required for puppet_home.
>> ├── hiera.yaml
>> ├── hieradata
>> ├── manifests
>> └── modules
>>
>> 3.  Create a symlink to manifest/site.pp file.
>>
>> 4. Clone wso2base puppet module into  /modules directory.
>>
>> 5. Create a symlink to wso2base common.yaml hiera-file.
>>
>>> /modules/wso2base/hieradata/wso2/common.yaml ->
>>> /hieradata/dev/wso2/
>>
>>
>> 6. Clone wso2 puppet module into  /modules
>> directory.
>>
>> 7. Create a symlink to wso2 hiera-files.
>>
>>>   /wso2/hieradata/dev/wso2/wso2 ->
>>> ../hieradata/dev/wso2/
>>
>>
>> Once the setup.sh completes, users can copy product pack and jdk
>> distribution for relevant folders and run vagrant setup against
>> above-created puppet home.
>>
>> We are planning to automate the copying of product pack, jdk distribution
>> and starting vagrant setup as well.
>>
>> Setup.sh can be found at [1]. Please share your suggestions towards this
>> approach.
>>
>> [1] https://github.com/wso2/puppet-common/blob/master/setup.sh
>>
>> --
>> *Thanks and Regards,*
>> Anuruddha Lanka Liyanarachchi
>> Software Engineer - WSO2
>> Mobile : +94 (0) 712762611
>> Tel  : +94 112 145 345
>> a nurudd...@wso2.com
>>
>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>


-- 
*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] [Puppet] Deep dive into WSO2 Puppet module implementation

[Rushmin Fernando]

Akila I got the following error while I was trying with ESB.


==> esb.dev.wso2.org: Rsyncing folder:
/home/rushmin/wso2/dev/env/puppet/hieradata/ => /puppet/hieradata
There was an error when attempting to rsync a synced folder.
Please inspect the error message below for more info.

Host path: /home/rushmin/wso2/dev/env/puppet/hieradata/
Guest path: /puppet/hieradata
Command: rsync --verbose --archive --delete -z --copy-links --no-owner
--no-group --rsync-path sudo rsync -e ssh -p  -o
StrictHostKeyChecking=no -o IdentitiesOnly=true -o
UserKnownHostsFile=/dev/null -i
'/home/rushmin/wso2/dev/rnd/src/git/puppet-commons/vagrant/.vagrant/machines/
esb.dev.wso2.org/virtualbox/private_key' --exclude .vagrant/
/home/rushmin/wso2/dev/env/puppet/hieradata/ vagrant@127.0.0.1:
/puppet/hieradata
Error: Warning: Permanently added '[127.0.0.1]:' (ECDSA) to the list of
known hosts.
symlink has no referent:
"/home/rushmin/wso2/dev/env/puppet/hieradata/dev/wso2/wso2apim"
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1183) [sender=3.1.0]

What am I doing wrong here ?

Best Regards
Rushmin

On Wed, Sep 7, 2016 at 2:49 PM, Akila Ravihansa Perera 
wrote:

> Hi,
>
> This thread is to raise awareness around some of the implementation level
> decisions that were taken when refactoring Puppet modules and splitting
> them into their own respective GitHub repos.
>
> * - Decouple Hiera from Puppet modules*
> In last Puppet-Modules release Hiera lookups were done in  module>/manifests/init.pp which made it mandatory for users to use Hiera.
> As part of the refactoring Hiera is made optional and configuration
> parameters are defined as class parameters which can be passed by site.pp
>
>
> * - Use Hiera only as a data store*
> There were some discussions about creating hooks in Puppet manifest to
> which Puppet resources can be plugged in via Hiera data. However, going
> forward we have come to a conclusion that Hiera should only be used as a
> data store and nothing more. Any customizations to Puppet manifest can be
> done directly in init.pp.
>
> * - Break Puppet configurations into stages*
> We have identified following stages which can be considered completely
> independent from each other;
> system - set operating system configs, install packages etc.
> clean - remove any existing installation
> install - extract the pack and set user permissions
> configure - populate templates, copy config files, import certs
> service - start the service
>
> Here is a snippet of wso2as/manifests/init.pp
>
> contain wso2base
> contain wso2base::system
> contain wso2base::clean
> contain wso2base::install
> contain wso2base::configure
> contain wso2base::service
>
> Class['::wso2base'] -> Class['::wso2base::system']
> -> Class['::wso2base::clean'] -> Class['::wso2base::install']
> -> Class['::wso2base::configure'] ~> Class['::wso2base::service']
>
> As you can see Puppet class containment [1] is used to ensure the
> dependency ordering. This is useful when users combine WSO2 Puppet modules
> with other modules (for eg: when creating roles and profiles).
>
> * - Remove inter module class inheritance*
> As per official Puppet docs class inheritance is to be avoided whenever
> possible [2]. Considering this we have removed all such relationships
> except for params.pp which contains default values.
>
> * - Move default values to params.pp and remove wso2base/params.pp*
> After giving much thought, we decided to keep default values in
> /manifests/params.pp and only in that place. Having common
> default values in /manifests/params.pp would minimize duplication
> but would be less readable for end users. Therefore we have come to a
> conclusion that wso2base module should only be used as a common
> resources/classes pool. It should not contain any data.
>
> *Try it out!*
>
> 1. Git clone https://github.com/wso2/puppet-common
> 2. Run puppet-common/setup.sh -p as
> 3. Goto puppet-common/vagrant
> 4. Run vagrant up
>
>
> [1] https://docs.puppet.com/puppet/latest/reference/lang_
> containment.html#containing-classes
> [2] https://docs.puppet.com/guides/style_guide.html#class-inheritance
>
> 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
>
>


-- 
*Best Regards*

*Rushmin Fernando*
*Technical Lead*

WSO2 Inc.  - Lean . Enterprise . Middleware

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

Re: [Dev] Create a gadget via REST datasource

[Geesara Prathap]

Hi Amalka,

If you are to use rest data provider, you need to implement a web
application which exposes those two APIs.  This sample implementation[1-2]
will help you to understand how these two APIs are implemented. Responses
of those two APIs should be in the JOSN format as well as response message
should be similar to this.

Sample response: retrieving the schema.

{
"columns": {
"house_id": {
"type": "INTEGER",
"isScoreParam": false,
"isIndex": false
},
"metro_area": {
"type": "STRING",
"isScoreParam": false,
"isIndex": false
},
"state": {
"type": "STRING",
"isScoreParam": false,
"isIndex": false
},
"device_id": {
"type": "INTEGER",
"isScoreParam": false,
"isIndex": false
},
"power_reading": {
"type": "FLOAT",
"isScoreParam": false,
"isIndex": false
},
"is_peak": {
"type": "BOOLEAN",
"isScoreParam": false,
"isIndex": false
}
},
"primaryKeys": []
}

Sample response: retrieving the data.

{

"message": [{
"values": {
"_version": "1.0.0",
"is_peak": true,
"state": "Florida",
"metro_area": "Miami",
"device_id": 4,
"power_reading": 484.4254,
"house_id": 19
}
}, {
"values": {
"_version": "1.0.0",
"is_peak": false,
"state": "Arizona",
"metro_area": "Phoenix",
"device_id": 1,
"power_reading": 92.64153,
"house_id": 13
}
}]
}

1.
https://github.com/wso2/product-iots/blob/master/modules/samples/geolocationTracker/component/api/src/main/java/org.deviceautomation/geolocationTracker/api/GeoLocationTrackerServiceImpl.java#L427
2.
https://github.com/wso2/product-iots/blob/master/modules/samples/geolocationTracker/component/api/src/main/java/org.deviceautomation/geolocationTracker/api/GeoLocationTrackerServiceImpl.java#L499

Thanks,
Geesara

On Wed, Sep 7, 2016 at 1:30 PM, Dunith Dhanushka  wrote:

> +Geesara
>
> On Wed, Sep 7, 2016 at 1:24 PM, Amalka Subasinghe  wrote:
>
>>
>> Hi,
>>
>> I want to create a gadget in DAS via rest datasource
>> What are the urls I need to provide for Data Retrieve URL * and Schema
>> Retrieve URL * ?
>>
>> I want execute following kind of queries
>> curl -GET 'http://wso2.influxdb.com:32086/query?pretty=true'
>> --data-urlencode "db=k8s" --data-urlencode "q=SHOW MEASUREMENTS"
>>
>> Please help
>>
>> Thanks
>> Amalka
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Regards,
>
> Dunith Dhanushka,
> Associate Technical Lead
> WSO2 Inc,
>
> Mobile - +94 71 8615744
> Blog - *https://medium.com/@dunithd *
> Twitter - @dunithd 
>



-- 
Geesara Prathap Kulathunga
Software Engineer
WSO2 Inc; http://wso2.com
Mobile : +940772684174
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [puppet] Setting up puppet home from script

[Imesh Gunaratne]

On Wed, Sep 7, 2016 at 6:24 PM, Anuruddha Liyanarachchi  wrote:

> Hi Imesh,
>
> I have now added the ability to configure multiple products using comma
> separated product list.
> Also included '-p all' option which configures all the products.
>
> Ex: ./setup.sh -p as
> Ex: ./setup.sh -p as,esb,bps
> Ex: ./setup.sh -p all
>

Great!
​Nice to hear that!

>
> On Wed, Sep 7, 2016 at 12:46 AM, Imesh Gunaratne  wrote:
>
>> Great work Anuruddha! The bash script works well!
>>
>> Shall we add the ability to install multiple product modules in one go?
>> Maybe we can use a comma separated product list with -p.
>>
>> Thanks
>>
>> On Tue, Sep 6, 2016 at 6:26 PM, Anuruddha Liyanarachchi <
>> anurudd...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> We have  created separate GitHub repos for Puppet modules so that the
>>> Puppet module can be shipped as part of a product release.
>>>
>>> Since modules are distributed we have introduced a script to generate
>>> PUPPET_HOME. The script will work as following.
>>>
>>>  1. Check puppet_home folder exists.
>>>
>>>  2. Create folder structure required for puppet_home.
>>> ├── hiera.yaml
>>> ├── hieradata
>>> ├── manifests
>>> └── modules
>>>
>>> 3.  Create a symlink to manifest/site.pp file.
>>>
>>> 4. Clone wso2base puppet module into  /modules directory.
>>>
>>> 5. Create a symlink to wso2base common.yaml hiera-file.
>>>
 /modules/wso2base/hieradata/wso2/common.yaml ->
 /hieradata/dev/wso2/
>>>
>>>
>>> 6. Clone wso2 puppet module into  /modules
>>> directory.
>>>
>>> 7. Create a symlink to wso2 hiera-files.
>>>
   /wso2/hieradata/dev/wso2/wso2 ->
 ../hieradata/dev/wso2/
>>>
>>>
>>> Once the setup.sh completes, users can copy product pack and jdk
>>> distribution for relevant folders and run vagrant setup against
>>> above-created puppet home.
>>>
>>> We are planning to automate the copying of product pack, jdk
>>> distribution and starting vagrant setup as well.
>>>
>>> Setup.sh can be found at [1]. Please share your suggestions towards this
>>> approach.
>>>
>>> [1] https://github.com/wso2/puppet-common/blob/master/setup.sh
>>>
>>> --
>>> *Thanks and Regards,*
>>> Anuruddha Lanka Liyanarachchi
>>> Software Engineer - WSO2
>>> Mobile : +94 (0) 712762611
>>> Tel  : +94 112 145 345
>>> a nurudd...@wso2.com
>>>
>>
>>
>>
>> --
>> *Imesh Gunaratne*
>> Software Architect
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057
>> W: https://medium.com/@imesh TW: @imesh
>> lean. enterprise. middleware
>>
>>
>
>
> --
> *Thanks and Regards,*
> Anuruddha Lanka Liyanarachchi
> Software Engineer - WSO2
> Mobile : +94 (0) 712762611
> Tel  : +94 112 145 345
> a nurudd...@wso2.com
>



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

Re: [Dev] [Puppet] Deep dive into WSO2 Puppet module implementation

[Pubudu Gunatilaka]

Hi Rushmin,

We have only completed wso2as puppet module [1]. We have not completed
wso2esb and it is not upto date. Currently we are working on other puppet
modules including wso2esb.

[1] - https://github.com/wso2/puppet-as

Thank you!

On Wed, Sep 7, 2016 at 7:31 PM, Rushmin Fernando  wrote:

> Akila I got the following error while I was trying with ESB.
>
>
> ==> esb.dev.wso2.org: Rsyncing folder: 
> /home/rushmin/wso2/dev/env/puppet/hieradata/
> => /puppet/hieradata
> There was an error when attempting to rsync a synced folder.
> Please inspect the error message below for more info.
>
> Host path: /home/rushmin/wso2/dev/env/puppet/hieradata/
> Guest path: /puppet/hieradata
> Command: rsync --verbose --archive --delete -z --copy-links --no-owner
> --no-group --rsync-path sudo rsync -e ssh -p  -o
> StrictHostKeyChecking=no -o IdentitiesOnly=true -o
> UserKnownHostsFile=/dev/null -i '/home/rushmin/wso2/dev/rnd/
> src/git/puppet-commons/vagrant/.vagrant/machines/esb.
> dev.wso2.org/virtualbox/private_key' --exclude .vagrant/
> /home/rushmin/wso2/dev/env/puppet/hieradata/ vagrant@127.0.0.1:/puppet/
> hieradata
> Error: Warning: Permanently added '[127.0.0.1]:' (ECDSA) to the list
> of known hosts.
> symlink has no referent: "/home/rushmin/wso2/dev/env/
> puppet/hieradata/dev/wso2/wso2apim"
> rsync error: some files/attrs were not transferred (see previous errors)
> (code 23) at main.c(1183) [sender=3.1.0]
>
> What am I doing wrong here ?
>
> Best Regards
> Rushmin
>
> On Wed, Sep 7, 2016 at 2:49 PM, Akila Ravihansa Perera  > wrote:
>
>> Hi,
>>
>> This thread is to raise awareness around some of the implementation level
>> decisions that were taken when refactoring Puppet modules and splitting
>> them into their own respective GitHub repos.
>>
>> * - Decouple Hiera from Puppet modules*
>> In last Puppet-Modules release Hiera lookups were done in > module>/manifests/init.pp which made it mandatory for users to use Hiera.
>> As part of the refactoring Hiera is made optional and configuration
>> parameters are defined as class parameters which can be passed by site.pp
>>
>>
>> * - Use Hiera only as a data store*
>> There were some discussions about creating hooks in Puppet manifest to
>> which Puppet resources can be plugged in via Hiera data. However, going
>> forward we have come to a conclusion that Hiera should only be used as a
>> data store and nothing more. Any customizations to Puppet manifest can be
>> done directly in init.pp.
>>
>> * - Break Puppet configurations into stages*
>> We have identified following stages which can be considered completely
>> independent from each other;
>> system - set operating system configs, install packages etc.
>> clean - remove any existing installation
>> install - extract the pack and set user permissions
>> configure - populate templates, copy config files, import certs
>> service - start the service
>>
>> Here is a snippet of wso2as/manifests/init.pp
>>
>> contain wso2base
>> contain wso2base::system
>> contain wso2base::clean
>> contain wso2base::install
>> contain wso2base::configure
>> contain wso2base::service
>>
>> Class['::wso2base'] -> Class['::wso2base::system']
>> -> Class['::wso2base::clean'] -> Class['::wso2base::install']
>> -> Class['::wso2base::configure'] ~> Class['::wso2base::service']
>>
>> As you can see Puppet class containment [1] is used to ensure the
>> dependency ordering. This is useful when users combine WSO2 Puppet modules
>> with other modules (for eg: when creating roles and profiles).
>>
>> * - Remove inter module class inheritance*
>> As per official Puppet docs class inheritance is to be avoided whenever
>> possible [2]. Considering this we have removed all such relationships
>> except for params.pp which contains default values.
>>
>> * - Move default values to params.pp and remove wso2base/params.pp*
>> After giving much thought, we decided to keep default values in
>> /manifests/params.pp and only in that place. Having
>> common default values in /manifests/params.pp would minimize
>> duplication but would be less readable for end users. Therefore we have
>> come to a conclusion that wso2base module should only be used as a common
>> resources/classes pool. It should not contain any data.
>>
>> *Try it out!*
>>
>> 1. Git clone https://github.com/wso2/puppet-common
>> 2. Run puppet-common/setup.sh -p as
>> 3. Goto puppet-common/vagrant
>> 4. Run vagrant up
>>
>>
>> [1] https://docs.puppet.com/puppet/latest/reference/lang_con
>> tainment.html#containing-classes
>> [2] https://docs.puppet.com/guides/style_guide.html#class-inheritance
>>
>> 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
>>
>>
>
>
> --
> *Best Regards*
>
> *Rushmin Fernando*
> *Technical Lead*
>
> WSO2 Inc.  - Lean . Enterprise . Midd

Re: [Dev] [puppet] Setting up puppet home from script

[Pubudu Gunatilaka]

Hi Anuruddha,

Great work Anuruddha!

I think we need to include the platform as well. If we consider the big
picture, ideally any user should be able to use this script and create a
puppet home for building docker images for Kubernetes, Mesos, or any other
platforms. As we have separate repos for platform hieradata,  we need to
copy those hieradata to the puppet home repo.

Thank you!


On Wed, Sep 7, 2016 at 8:21 PM, Imesh Gunaratne  wrote:

>
>
> On Wed, Sep 7, 2016 at 6:24 PM, Anuruddha Liyanarachchi <
> anurudd...@wso2.com> wrote:
>
>> Hi Imesh,
>>
>> I have now added the ability to configure multiple products using comma
>> separated product list.
>> Also included '-p all' option which configures all the products.
>>
>> Ex: ./setup.sh -p as
>> Ex: ./setup.sh -p as,esb,bps
>> Ex: ./setup.sh -p all
>>
>
> Great!
> ​Nice to hear that!
>
>>
>> On Wed, Sep 7, 2016 at 12:46 AM, Imesh Gunaratne  wrote:
>>
>>> Great work Anuruddha! The bash script works well!
>>>
>>> Shall we add the ability to install multiple product modules in one go?
>>> Maybe we can use a comma separated product list with -p.
>>>
>>> Thanks
>>>
>>> On Tue, Sep 6, 2016 at 6:26 PM, Anuruddha Liyanarachchi <
>>> anurudd...@wso2.com> wrote:
>>>
 Hi,

 We have  created separate GitHub repos for Puppet modules so that the
 Puppet module can be shipped as part of a product release.

 Since modules are distributed we have introduced a script to generate
 PUPPET_HOME. The script will work as following.

  1. Check puppet_home folder exists.

  2. Create folder structure required for puppet_home.
 ├── hiera.yaml
 ├── hieradata
 ├── manifests
 └── modules

 3.  Create a symlink to manifest/site.pp file.

 4. Clone wso2base puppet module into  /modules directory.

 5. Create a symlink to wso2base common.yaml hiera-file.

> /modules/wso2base/hieradata/wso2/common.yaml ->
> /hieradata/dev/wso2/


 6. Clone wso2 puppet module into  /modules
 directory.

 7. Create a symlink to wso2 hiera-files.

>   /wso2/hieradata/dev/wso2/wso2 ->
> ../hieradata/dev/wso2/


 Once the setup.sh completes, users can copy product pack and jdk
 distribution for relevant folders and run vagrant setup against
 above-created puppet home.

 We are planning to automate the copying of product pack, jdk
 distribution and starting vagrant setup as well.

 Setup.sh can be found at [1]. Please share your suggestions towards
 this approach.

 [1] https://github.com/wso2/puppet-common/blob/master/setup.sh

 --
 *Thanks and Regards,*
 Anuruddha Lanka Liyanarachchi
 Software Engineer - WSO2
 Mobile : +94 (0) 712762611
 Tel  : +94 112 145 345
 a nurudd...@wso2.com

>>>
>>>
>>>
>>> --
>>> *Imesh Gunaratne*
>>> Software Architect
>>> WSO2 Inc: http://wso2.com
>>> T: +94 11 214 5345 M: +94 77 374 2057
>>> W: https://medium.com/@imesh TW: @imesh
>>> lean. enterprise. middleware
>>>
>>>
>>
>>
>> --
>> *Thanks and Regards,*
>> Anuruddha Lanka Liyanarachchi
>> Software Engineer - WSO2
>> Mobile : +94 (0) 712762611
>> Tel  : +94 112 145 345
>> a nurudd...@wso2.com
>>
>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>


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

[Dev] Reverting a patch when the original jar is not in patch0000 directory

[Omindu Rathnaweera]

Hi,

Noticed that we cannot revert a patch if the particular jar is not in the
patch directory. Assume that we install a feature to a product which
already has the patch directory created. Then, we patch one of the jars
in that new feature, and later on we remove that patch from the patches
directory. The plugins directory will still have the patched jar even if
the patch is removed. I assume this is because the new jars related to the
feature is not getting copied to patch during feature installation.

In my case I installed the FB authenticator to IS 5.0.0 + SP1 applied and
patched the authenticator. To revert the patch I had to copy the old jar to
the plugins directory. Even reinstalling the feature didn't restore the
jar.

Not sure if it's a buggy behavior, if not is there an alternative way to
revert it ?

Thanks,
Omindu.

-- 
Omindu Rathnaweera
Software Engineer, WSO2 Inc.
Mobile: +94 771 197 211
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [puppet] Setting up puppet home from script

[Imesh Gunaratne]

On Wed, Sep 7, 2016 at 10:09 PM, Pubudu Gunatilaka  wrote:

>
> I think we need to include the platform as well. If we consider the big
> picture, ideally any user should be able to use this script and create a
> puppet home for building docker images for Kubernetes, Mesos, or any other
> platforms. As we have separate repos for platform hieradata,  we need to
> copy those hieradata to the puppet home repo.
>

​+1​


>
> Thank you!
>
>
> On Wed, Sep 7, 2016 at 8:21 PM, Imesh Gunaratne  wrote:
>
>>
>>
>> On Wed, Sep 7, 2016 at 6:24 PM, Anuruddha Liyanarachchi <
>> anurudd...@wso2.com> wrote:
>>
>>> Hi Imesh,
>>>
>>> I have now added the ability to configure multiple products using comma
>>> separated product list.
>>> Also included '-p all' option which configures all the products.
>>>
>>> Ex: ./setup.sh -p as
>>> Ex: ./setup.sh -p as,esb,bps
>>> Ex: ./setup.sh -p all
>>>
>>
>> Great!
>> ​Nice to hear that!
>>
>>>
>>> On Wed, Sep 7, 2016 at 12:46 AM, Imesh Gunaratne  wrote:
>>>
 Great work Anuruddha! The bash script works well!

 Shall we add the ability to install multiple product modules in one go?
 Maybe we can use a comma separated product list with -p.

 Thanks

 On Tue, Sep 6, 2016 at 6:26 PM, Anuruddha Liyanarachchi <
 anurudd...@wso2.com> wrote:

> Hi,
>
> We have  created separate GitHub repos for Puppet modules so that the
> Puppet module can be shipped as part of a product release.
>
> Since modules are distributed we have introduced a script to generate
> PUPPET_HOME. The script will work as following.
>
>  1. Check puppet_home folder exists.
>
>  2. Create folder structure required for puppet_home.
> ├── hiera.yaml
> ├── hieradata
> ├── manifests
> └── modules
>
> 3.  Create a symlink to manifest/site.pp file.
>
> 4. Clone wso2base puppet module into  /modules directory.
>
> 5. Create a symlink to wso2base common.yaml hiera-file.
>
>> /modules/wso2base/hieradata/wso2/common.yaml ->
>> /hieradata/dev/wso2/
>
>
> 6. Clone wso2 puppet module into  /modules
> directory.
>
> 7. Create a symlink to wso2 hiera-files.
>
>>   /wso2/hieradata/dev/wso2/wso2 ->
>> ../hieradata/dev/wso2/
>
>
> Once the setup.sh completes, users can copy product pack and jdk
> distribution for relevant folders and run vagrant setup against
> above-created puppet home.
>
> We are planning to automate the copying of product pack, jdk
> distribution and starting vagrant setup as well.
>
> Setup.sh can be found at [1]. Please share your suggestions towards
> this approach.
>
> [1] https://github.com/wso2/puppet-common/blob/master/setup.sh
>
> --
> *Thanks and Regards,*
> Anuruddha Lanka Liyanarachchi
> Software Engineer - WSO2
> Mobile : +94 (0) 712762611
> Tel  : +94 112 145 345
> a nurudd...@wso2.com
>



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


>>>
>>>
>>> --
>>> *Thanks and Regards,*
>>> Anuruddha Lanka Liyanarachchi
>>> Software Engineer - WSO2
>>> Mobile : +94 (0) 712762611
>>> Tel  : +94 112 145 345
>>> a nurudd...@wso2.com
>>>
>>
>>
>>
>> --
>> *Imesh Gunaratne*
>> Software Architect
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057
>> W: https://medium.com/@imesh TW: @imesh
>> lean. enterprise. middleware
>>
>>
>
>
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>


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

Re: [Dev] [Puppet] Deep dive into WSO2 Puppet module implementation

[Imesh Gunaratne]

What would be the reason for using rsync in the Vagrant setup [2]? Do we
update files inside the VM?

[2]
https://github.com/wso2/puppet-common/blob/56b34c4c2db11f07dca739f0e92bf1d955cfcb46/vagrant/Vagrantfile#L53

Thanks

On Wed, Sep 7, 2016 at 10:01 PM, Pubudu Gunatilaka  wrote:

> Hi Rushmin,
>
> We have only completed wso2as puppet module [1]. We have not completed
> wso2esb and it is not upto date. Currently we are working on other puppet
> modules including wso2esb.
>
> [1] - https://github.com/wso2/puppet-as
>
> Thank you!
>
> On Wed, Sep 7, 2016 at 7:31 PM, Rushmin Fernando  wrote:
>
>> Akila I got the following error while I was trying with ESB.
>>
>>
>> ==> esb.dev.wso2.org: Rsyncing folder: 
>> /home/rushmin/wso2/dev/env/puppet/hieradata/
>> => /puppet/hieradata
>> There was an error when attempting to rsync a synced folder.
>> Please inspect the error message below for more info.
>>
>> Host path: /home/rushmin/wso2/dev/env/puppet/hieradata/
>> Guest path: /puppet/hieradata
>> Command: rsync --verbose --archive --delete -z --copy-links --no-owner
>> --no-group --rsync-path sudo rsync -e ssh -p  -o
>> StrictHostKeyChecking=no -o IdentitiesOnly=true -o
>> UserKnownHostsFile=/dev/null -i '/home/rushmin/wso2/dev/rnd/sr
>> c/git/puppet-commons/vagrant/.vagrant/machines/esb.dev.wso2.
>> org/virtualbox/private_key' --exclude .vagrant/
>> /home/rushmin/wso2/dev/env/puppet/hieradata/ vagrant@127.0.0.1:
>> /puppet/hieradata
>> Error: Warning: Permanently added '[127.0.0.1]:' (ECDSA) to the list
>> of known hosts.
>> symlink has no referent: "/home/rushmin/wso2/dev/env/pu
>> ppet/hieradata/dev/wso2/wso2apim"
>> rsync error: some files/attrs were not transferred (see previous errors)
>> (code 23) at main.c(1183) [sender=3.1.0]
>>
>> What am I doing wrong here ?
>>
>> Best Regards
>> Rushmin
>>
>> On Wed, Sep 7, 2016 at 2:49 PM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> This thread is to raise awareness around some of the implementation
>>> level decisions that were taken when refactoring Puppet modules and
>>> splitting them into their own respective GitHub repos.
>>>
>>> * - Decouple Hiera from Puppet modules*
>>> In last Puppet-Modules release Hiera lookups were done in >> module>/manifests/init.pp which made it mandatory for users to use Hiera.
>>> As part of the refactoring Hiera is made optional and configuration
>>> parameters are defined as class parameters which can be passed by site.pp
>>>
>>>
>>> * - Use Hiera only as a data store*
>>> There were some discussions about creating hooks in Puppet manifest to
>>> which Puppet resources can be plugged in via Hiera data. However, going
>>> forward we have come to a conclusion that Hiera should only be used as a
>>> data store and nothing more. Any customizations to Puppet manifest can be
>>> done directly in init.pp.
>>>
>>> * - Break Puppet configurations into stages*
>>> We have identified following stages which can be considered completely
>>> independent from each other;
>>> system - set operating system configs, install packages etc.
>>> clean - remove any existing installation
>>> install - extract the pack and set user permissions
>>> configure - populate templates, copy config files, import certs
>>> service - start the service
>>>
>>> Here is a snippet of wso2as/manifests/init.pp
>>>
>>> contain wso2base
>>> contain wso2base::system
>>> contain wso2base::clean
>>> contain wso2base::install
>>> contain wso2base::configure
>>> contain wso2base::service
>>>
>>> Class['::wso2base'] -> Class['::wso2base::system']
>>> -> Class['::wso2base::clean'] -> Class['::wso2base::install']
>>> -> Class['::wso2base::configure'] ~> Class['::wso2base::service']
>>>
>>> As you can see Puppet class containment [1] is used to ensure the
>>> dependency ordering. This is useful when users combine WSO2 Puppet modules
>>> with other modules (for eg: when creating roles and profiles).
>>>
>>> * - Remove inter module class inheritance*
>>> As per official Puppet docs class inheritance is to be avoided whenever
>>> possible [2]. Considering this we have removed all such relationships
>>> except for params.pp which contains default values.
>>>
>>> * - Move default values to params.pp and remove wso2base/params.pp*
>>> After giving much thought, we decided to keep default values in
>>> /manifests/params.pp and only in that place. Having
>>> common default values in /manifests/params.pp would minimize
>>> duplication but would be less readable for end users. Therefore we have
>>> come to a conclusion that wso2base module should only be used as a common
>>> resources/classes pool. It should not contain any data.
>>>
>>> *Try it out!*
>>>
>>> 1. Git clone https://github.com/wso2/puppet-common
>>> 2. Run puppet-common/setup.sh -p as
>>> 3. Goto puppet-common/vagrant
>>> 4. Run vagrant up
>>>
>>>
>>> [1] https://docs.puppet.com/puppet/latest/reference/lang_con
>>> tainment.html#containing-classes
>>> [2] https://docs.puppet.com/guides/style_

[Dev] [EMM] WebApp Permission Handling at UI

[Rasika Perera]

Hi All,

With the current migration of EMM webapp from UUF v0.1 to v0.2 (jaggery
based implementation) we are trying to standardize the permission check for
UI bits. We need to check permissions for “pages” level as well as granular
to the “units” level. For example; show/hide a button based on UI
permission. Also should notice that these permissions are not unique to the
front-end, thus can be directly mapped into the respective back-end osgi
services. For example; device enroll permission will be checked on the
enrollment page(front-end), as well as the inside the respective enrollment
osgi service(back-end).

And also there’s a requirement that any third-party application should be
able to write their own UI based on our web apis. Hence we are expecting to
expose isAuthorized() via JAX-RS too. SOAP clients will be able to directly
call admin-service.

[image: Inline image 1]



As per the diagram, when a EMM web app receives a page render request from
the browser, UUF will execute the the method isAuthorized() at the back-end
JavaScript layer. JavaScript will include the “carbon” jaggery module which
will import the RealmService OSGi service. Using RealmService we can invoke
the Authorizer.isRoleAuthorized().

Whenever, third-party application requests for a permission check via
EMM-API(JAX-RS), final result should be given invoking same
Authorizer.isRoleAuthorized() method.

One concern on this design was how to improve the *performance* of OSGi
calls per permission check. One such suggestion is to retrieve all
permissions for the current user and persist it on the “session”. IMO this
would results some unforeseen issues and permission update on the backend
will not immediately applied on the already logged users(eg. longer session
timeouts). For example: users will still see the action buttons when
clicked on it, it will return permission error. On the other hand, managing
caching coherency is an extra effort for this approach. My suggestion is to
utilize the permission check cache(if exists) at the user-core level which
would be consistent across the platform.

WDYT?

@DS/UUF Team: I hope we need the similar permission check feature with the
{{permission}} handlebar helper.

-- 
With Regards,

*Rasika Perera*
Software Engineer
LinkedIn: http://lk.linkedin.com/in/rasika90

[image: wso2-signature-general.png] 

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

Re: [Dev] [Puppet] Deep dive into WSO2 Puppet module implementation

[Akila Ravihansa Perera]

Hi Imesh,


On Thu, Sep 8, 2016 at 3:47 AM, Imesh Gunaratne  wrote:

> What would be the reason for using rsync in the Vagrant setup [2]? Do we
> update files inside the VM?
>
> [2] https://github.com/wso2/puppet-common/blob/
> 56b34c4c2db11f07dca739f0e92bf1d955cfcb46/vagrant/Vagrantfile#L53
>

We ran into an issue when mounting Hieradata folder (which is a symlink
now) to the VM. It seems Vagrant does not fully support mounting symlinks
so we had to rsync it.

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

Re: [Dev] [Puppet] Deep dive into WSO2 Puppet module implementation

[Akila Ravihansa Perera]

Hi,

Adding few more details I'd like to highlight;

* - Removed Java 3rd party Puppet module dependency*
In earlier versions we used an external 3rd party Puppet module for Java
installation which we thought is not necessary anymore. Therefore we have
implemented our own Java class without any dependencies.

The only contract between Java module and WSO2 Puppet modules is it should
install Java JDK on "JAVA_HOME" path. JAVA_HOME is expected as a class
parameter by all WSO2 Puppet modules and defaults to "/opt/java". Usually
this is a symlink and actual JDK installation path may differ.
As a convenience for users we have provided a basic java class in wso2base
module which takes the JDK from Puppet file bucket, extracts it and sets
the JAVA_HOME symlink. Java class is *not *contained in any of the WSO2
Puppet module classes so it has to be added from site.pp. For eg:

## site.pp
class { 'wso2base::java' } -> class { 'wso2as' }

This offers greater flexibility for users to plug-in their own Java module.


* - Use of Puppet file server*
Earlier users had to copy jdk and product packs into respective Puppet
module's files directory. We have improved Puppet scripts to lookup in
Puppet file server path as well. For eg: packs are searched in
/files/packs directory which contains packs for all the
products. This is again a convenience for the users. This applies to
patches and configs files as well.
You can try this feature with Vagrant. By default it takes Puppet file
server path as /files directory and pass that as a Puppet
options parameter [1].


* - Patches structure*
With the introduction of "patch_list" parameter together with Puppet file
server support, now you do not need to copy patches to each and every
Puppet module! Patches are grouped by platform version therefore patches
dir will be as follows;

/files/patches
- 4.2.0
   - patch0001
 ...

- 4.4.0
   - patch0005
 ...

Note that "patch_list" parameter is optional. Meaning, if you keep it empty
or undef, Puppet will copy all the patches you have placed inside
respective Puppet module's files/patches//* directory.
If you set the "patch_list" as an array, it will search the Puppet file
server and Puppet module's files bucket for the specified patches. The
difference is, the latter method will error if any of the specified patches
are missing. This is useful when you want to ensure that all required
patches are copied.


[1]
https://github.com/wso2/puppet-common/blob/56b34c4c2db11f07dca739f0e92bf1d955cfcb46/vagrant/Vagrantfile#L78

Thanks.


On Thu, Sep 8, 2016 at 5:56 AM, Akila Ravihansa Perera 
wrote:

> Hi Imesh,
>
>
> On Thu, Sep 8, 2016 at 3:47 AM, Imesh Gunaratne  wrote:
>
>> What would be the reason for using rsync in the Vagrant setup [2]? Do we
>> update files inside the VM?
>>
>> [2] https://github.com/wso2/puppet-common/blob/56b34c4c2db11f07d
>> ca739f0e92bf1d955cfcb46/vagrant/Vagrantfile#L53
>>
>
> We ran into an issue when mounting Hieradata folder (which is a symlink
> now) to the VM. It seems Vagrant does not fully support mounting symlinks
> so we had to rsync it.
>
> Thanks.
>
> --
> 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] Reverting a patch when the original jar is not in patch0000 directory

[Harsha Thirimanna]

Did you apply any patches before you install the feature ? As you said, it
may be a bug.

On Sep 8, 2016 12:23 AM, "Omindu Rathnaweera"  wrote:

> Hi,
>
> Noticed that we cannot revert a patch if the particular jar is not in the
> patch directory. Assume that we install a feature to a product which
> already has the patch directory created. Then, we patch one of the jars
> in that new feature, and later on we remove that patch from the patches
> directory. The plugins directory will still have the patched jar even if
> the patch is removed. I assume this is because the new jars related to the
> feature is not getting copied to patch during feature installation.
>
> In my case I installed the FB authenticator to IS 5.0.0 + SP1 applied and
> patched the authenticator. To revert the patch I had to copy the old jar to
> the plugins directory. Even reinstalling the feature didn't restore the
> jar.
>
> Not sure if it's a buggy behavior, if not is there an alternative way to
> revert it ?
>
> Thanks,
> Omindu.
>
> --
> Omindu Rathnaweera
> Software Engineer, WSO2 Inc.
> Mobile: +94 771 197 211
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [EMM] WebApp Permission Handling at UI

[Dilan Udara Ariyaratne]

Hi Rasika,

For third-party UIs expecting to use our web APIs, we will also have to
expose an unprotected web API for login-time authentication and login
authorization check.

And when it comes to performance concerns,

[1] Session based approach - "YES", in the session based approach we will
have consistency issues in between Backend and UI, if permissions of the
user get updated during
the valid time of an active session. Yet IMO, this approach stands out as
the fastest permission checking approach in comparison to other methods
that you mention and
one counter-argument that we could make for inconsistency issues is that
this kind of an inconsistency could happen very rarely as permission level
changes for roles
is not that frequent. And even if that happens, since we anyway check the
most updated state of a permission at API layer, we always have the right
level of security guaranteed from our backend.

WDYT?

[2] OSGI Calls from backend javascript layer to user management core - This
stands out as the second fastest since this is an in-JVM call and not a
network call to user management OSGI component.
Yet I believe we should optimize our backend javascript wrapper to support
multiple permission checks in one go, so that it minimizes the
reinitialization of required user management beans for each
permission check. What I exactly mean is to change
.isAuthorized(permission)  .isAuthorized(List permissions), so
that all the permissions to be checked for a page or unit
could be verified in one go.

[3] Web APIs to call user management core - This stands out to be the
slowest as it requires a network call to an API from the UI to do an
authorization check.
Even here I believe that we should support a request body of multiple
permissions, so that we can verify the level of authorization of a user for
a page or unit in one go and most importantly
one network call, instead of a few.

WDYT?

Cheers,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Thu, Sep 8, 2016 at 5:17 AM, Rasika Perera  wrote:

> Hi All,
>
> With the current migration of EMM webapp from UUF v0.1 to v0.2 (jaggery
> based implementation) we are trying to standardize the permission check for
> UI bits. We need to check permissions for “pages” level as well as granular
> to the “units” level. For example; show/hide a button based on UI
> permission. Also should notice that these permissions are not unique to the
> front-end, thus can be directly mapped into the respective back-end osgi
> services. For example; device enroll permission will be checked on the
> enrollment page(front-end), as well as the inside the respective enrollment
> osgi service(back-end).
>
> And also there’s a requirement that any third-party application should be
> able to write their own UI based on our web apis. Hence we are expecting to
> expose isAuthorized() via JAX-RS too. SOAP clients will be able to directly
> call admin-service.
>
> [image: Inline image 1]
>
>
>
> As per the diagram, when a EMM web app receives a page render request from
> the browser, UUF will execute the the method isAuthorized() at the back-end
> JavaScript layer. JavaScript will include the “carbon” jaggery module which
> will import the RealmService OSGi service. Using RealmService we can invoke
> the Authorizer.isRoleAuthorized().
>
> Whenever, third-party application requests for a permission check via
> EMM-API(JAX-RS), final result should be given invoking same
> Authorizer.isRoleAuthorized() method.
>
> One concern on this design was how to improve the *performance* of OSGi
> calls per permission check. One such suggestion is to retrieve all
> permissions for the current user and persist it on the “session”. IMO this
> would results some unforeseen issues and permission update on the backend
> will not immediately applied on the already logged users(eg. longer session
> timeouts). For example: users will still see the action buttons when
> clicked on it, it will return permission error. On the other hand, managing
> caching coherency is an extra effort for this approach. My suggestion is to
> utilize the permission check cache(if exists) at the user-core level which
> would be consistent across the platform.
>
> WDYT?
>
> @DS/UUF Team: I hope we need the similar permission check feature with the
> {{permission}} handlebar helper.
>
> --
> With Regards,
>
> *Rasika Perera*
> Software Engineer
> LinkedIn: http://lk.linkedin.com/in/rasika90
>
> [image: wso2-signature-general.png] 
>
> WSO2 Inc. www.wso2.com
> lean.enterprise.middleware
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [EMM] WebApp Permission Handling at UI

[Charitha Goonetilleke]

Hi All,

I have a concern with the '(1) Session based approach'.

As per our Group implementation, grouping is depending on the permissions
and roles. So when group is shared with a user, the particular sharing role
will assigned to the user and then we need to manipulate UI bits for
grouped devices, based on the permissions which user got though the role.
So it will make inconsistency in UI elements as Rasika explained more
frequently.

Therefore it is needed to implement more consistent way to check
permissions rather than using session based approach. As Dilan explained
'(3) Web APIs to call user management core' could have significant impact
on performance and managing and implementing caching coherency is an extra
effort for this approach, I'm seeing '(2) OSGI Calls from back end
javascript layer to user management core' would be a possible solution for
this.

However if we could utilize permission check cache(if exists) at the
user-core level as Rasika suggested, we can write logic to update that
cache when ever grouping related operations (add/remove devices, change
sharing, create/delete groups) are performed. Also if we could implement
Rasika's suggestion in java level as an OSGi service with logic to update
cache when required, we can reuse the same cache for our APIs and it would
help to improve the performance significantly.

So I'm +1 for the Rasika's suggestion with logic to update cache when ever
needed.

Thanks & Regards,
/charithag

On Thu, Sep 8, 2016 at 8:22 AM, Dilan Udara Ariyaratne 
wrote:

> Hi Rasika,
>
> For third-party UIs expecting to use our web APIs, we will also have to
> expose an unprotected web API for login-time authentication and login
> authorization check.
>
> And when it comes to performance concerns,
>
> [1] Session based approach - "YES", in the session based approach we will
> have consistency issues in between Backend and UI, if permissions of the
> user get updated during
> the valid time of an active session. Yet IMO, this approach stands out as
> the fastest permission checking approach in comparison to other methods
> that you mention and
> one counter-argument that we could make for inconsistency issues is that
> this kind of an inconsistency could happen very rarely as permission level
> changes for roles
> is not that frequent. And even if that happens, since we anyway check the
> most updated state of a permission at API layer, we always have the right
> level of security guaranteed from our backend.
>
> WDYT?
>
> [2] OSGI Calls from backend javascript layer to user management core -
> This stands out as the second fastest since this is an in-JVM call and not
> a network call to user management OSGI component.
> Yet I believe we should optimize our backend javascript wrapper to support
> multiple permission checks in one go, so that it minimizes the
> reinitialization of required user management beans for each
> permission check. What I exactly mean is to change
> .isAuthorized(permission)  .isAuthorized(List permissions), so
> that all the permissions to be checked for a page or unit
> could be verified in one go.
>
> [3] Web APIs to call user management core - This stands out to be the
> slowest as it requires a network call to an API from the UI to do an
> authorization check.
> Even here I believe that we should support a request body of multiple
> permissions, so that we can verify the level of authorization of a user for
> a page or unit in one go and most importantly
> one network call, instead of a few.
>
> WDYT?
>
> Cheers,
> Dilan.
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. 
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Thu, Sep 8, 2016 at 5:17 AM, Rasika Perera  wrote:
>
>> Hi All,
>>
>> With the current migration of EMM webapp from UUF v0.1 to v0.2 (jaggery
>> based implementation) we are trying to standardize the permission check for
>> UI bits. We need to check permissions for “pages” level as well as granular
>> to the “units” level. For example; show/hide a button based on UI
>> permission. Also should notice that these permissions are not unique to the
>> front-end, thus can be directly mapped into the respective back-end osgi
>> services. For example; device enroll permission will be checked on the
>> enrollment page(front-end), as well as the inside the respective enrollment
>> osgi service(back-end).
>>
>> And also there’s a requirement that any third-party application should be
>> able to write their own UI based on our web apis. Hence we are expecting to
>> expose isAuthorized() via JAX-RS too. SOAP clients will be able to directly
>> call admin-service.
>>
>> [image: Inline image 1]
>>
>>
>>
>> As per the diagram, when a EMM web app receives a page render request
>> from the browser, UUF will execute the the method isAuthorized() at the
>> back-end JavaScript layer. JavaScript will include the “carbon” jaggery
>> module which will import the RealmService O

Re: [Dev] [puppet] Setting up puppet home from script

[Anuruddha Liyanarachchi]

Hi Pubudu,

+1 for the platform support.
I will add the platform support once we finalized the platform
hieradata structure.

On Thu, Sep 8, 2016 at 3:44 AM, Imesh Gunaratne  wrote:

>
>
> On Wed, Sep 7, 2016 at 10:09 PM, Pubudu Gunatilaka 
> wrote:
>
>>
>> I think we need to include the platform as well. If we consider the big
>> picture, ideally any user should be able to use this script and create a
>> puppet home for building docker images for Kubernetes, Mesos, or any other
>> platforms. As we have separate repos for platform hieradata,  we need to
>> copy those hieradata to the puppet home repo.
>>
>
> ​+1​
>
>
>>
>> Thank you!
>>
>>
>> On Wed, Sep 7, 2016 at 8:21 PM, Imesh Gunaratne  wrote:
>>
>>>
>>>
>>> On Wed, Sep 7, 2016 at 6:24 PM, Anuruddha Liyanarachchi <
>>> anurudd...@wso2.com> wrote:
>>>
 Hi Imesh,

 I have now added the ability to configure multiple products using comma
 separated product list.
 Also included '-p all' option which configures all the products.

 Ex: ./setup.sh -p as
 Ex: ./setup.sh -p as,esb,bps
 Ex: ./setup.sh -p all

>>>
>>> Great!
>>> ​Nice to hear that!
>>>

 On Wed, Sep 7, 2016 at 12:46 AM, Imesh Gunaratne 
 wrote:

> Great work Anuruddha! The bash script works well!
>
> Shall we add the ability to install multiple product modules in one
> go? Maybe we can use a comma separated product list with -p.
>
> Thanks
>
> On Tue, Sep 6, 2016 at 6:26 PM, Anuruddha Liyanarachchi <
> anurudd...@wso2.com> wrote:
>
>> Hi,
>>
>> We have  created separate GitHub repos for Puppet modules so that the
>> Puppet module can be shipped as part of a product release.
>>
>> Since modules are distributed we have introduced a script to generate
>> PUPPET_HOME. The script will work as following.
>>
>>  1. Check puppet_home folder exists.
>>
>>  2. Create folder structure required for puppet_home.
>> ├── hiera.yaml
>> ├── hieradata
>> ├── manifests
>> └── modules
>>
>> 3.  Create a symlink to manifest/site.pp file.
>>
>> 4. Clone wso2base puppet module into  /modules
>> directory.
>>
>> 5. Create a symlink to wso2base common.yaml hiera-file.
>>
>>> /modules/wso2base/hieradata/wso2/common.yaml ->
>>> /hieradata/dev/wso2/
>>
>>
>> 6. Clone wso2 puppet module into  /modules
>> directory.
>>
>> 7. Create a symlink to wso2 hiera-files.
>>
>>>   /wso2/hieradata/dev/wso2/wso2 ->
>>> ../hieradata/dev/wso2/
>>
>>
>> Once the setup.sh completes, users can copy product pack and jdk
>> distribution for relevant folders and run vagrant setup against
>> above-created puppet home.
>>
>> We are planning to automate the copying of product pack, jdk
>> distribution and starting vagrant setup as well.
>>
>> Setup.sh can be found at [1]. Please share your suggestions towards
>> this approach.
>>
>> [1] https://github.com/wso2/puppet-common/blob/master/setup.sh
>>
>> --
>> *Thanks and Regards,*
>> Anuruddha Lanka Liyanarachchi
>> Software Engineer - WSO2
>> Mobile : +94 (0) 712762611
>> Tel  : +94 112 145 345
>> a nurudd...@wso2.com
>>
>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>


 --
 *Thanks and Regards,*
 Anuruddha Lanka Liyanarachchi
 Software Engineer - WSO2
 Mobile : +94 (0) 712762611
 Tel  : +94 112 145 345
 a nurudd...@wso2.com

>>>
>>>
>>>
>>> --
>>> *Imesh Gunaratne*
>>> Software Architect
>>> WSO2 Inc: http://wso2.com
>>> T: +94 11 214 5345 M: +94 77 374 2057
>>> W: https://medium.com/@imesh TW: @imesh
>>> lean. enterprise. middleware
>>>
>>>
>>
>>
>> --
>> *Pubudu Gunatilaka*
>> Committer and PMC Member - Apache Stratos
>> Software Engineer
>> WSO2, Inc.: http://wso2.com
>> mobile : +94774078049 <%2B94772207163>
>>
>>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>


-- 
*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] [EMM] WebApp Permission Handling at UI

[Udara Rathnayake]

On Thu, Sep 8, 2016 at 5:17 AM, Rasika Perera  wrote:

> Hi All,
>
> With the current migration of EMM webapp from UUF v0.1 to v0.2 (jaggery
> based implementation) we are trying to standardize the permission check for
> UI bits. We need to check permissions for “pages” level as well as granular
> to the “units” level. For example; show/hide a button based on UI
> permission. Also should notice that these permissions are not unique to the
> front-end, thus can be directly mapped into the respective back-end osgi
> services. For example; device enroll permission will be checked on the
> enrollment page(front-end), as well as the inside the respective enrollment
> osgi service(back-end).
>
> And also there’s a requirement that any third-party application should be
> able to write their own UI based on our web apis. Hence we are expecting to
> expose isAuthorized() via JAX-RS too. SOAP clients will be able to directly
> call admin-service.
>
> [image: Inline image 1]
>
>
>
> As per the diagram, when a EMM web app receives a page render request from
> the browser, UUF will execute the the method isAuthorized() at the back-end
> JavaScript layer. JavaScript will include the “carbon” jaggery module which
> will import the RealmService OSGi service. Using RealmService we can invoke
> the Authorizer.isRoleAuthorized().
>
> Whenever, third-party application requests for a permission check via
> EMM-API(JAX-RS), final result should be given invoking same
> Authorizer.isRoleAuthorized() method.
>
> One concern on this design was how to improve the *performance* of OSGi
> calls per permission check. One such suggestion is to retrieve all
> permissions for the current user and persist it on the “session”. IMO this
> would results some unforeseen issues and permission update on the backend
> will not immediately applied on the already logged users(eg. longer session
> timeouts). For example: users will still see the action buttons when
> clicked on it, it will return permission error. On the other hand, managing
> caching coherency is an extra effort for this approach. My suggestion is to
> utilize the permission check cache(if exists) at the user-core level which
> would be consistent across the platform.
>
> WDYT?
>
> @DS/UUF Team: I hope we need the similar permission check feature with the
> {{permission}} handlebar helper.
>
​Isn't this similar to what we are trying to solve with secured helper with
permission?​


>
> --
> With Regards,
>
> *Rasika Perera*
> Software Engineer
> LinkedIn: http://lk.linkedin.com/in/rasika90
>
> [image: wso2-signature-general.png] 
>
> WSO2 Inc. www.wso2.com
> lean.enterprise.middleware
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


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

[Dev] Dependency issue for carbon-appmgt master branch

[Dulitha Wijewantha]

Hi guys,
Getting build issue on master for carbon-appmgt

Cheers~
[ERROR] Failed to execute goal on project org.wso2.carbon.appmgt.impl:
Could not resolve dependencies for project
org.wso2.carbon.appmgt:org.wso2.carbon.appmgt.impl:bundle:1.2.3-SNAPSHOT:
The following artifacts could not be resolved:
org.wso2.carbon.identity:org.wso2.carbon.identity.core:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.identity.application.mgt:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.user.mgt.stub:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.idp.mgt.stub:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.identity.application.mgt.stub:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.identity.entitlement.stub:jar:5.2.1-SNAPSHOT:
Failure to find
org.wso2.carbon.identity:org.wso2.carbon.identity.core:jar:5.2.1-SNAPSHOT
in http://maven.wso2.org/nexus/content/groups/wso2-public/ was cached in
the local repository, resolution will not be reattempted until the update
interval of wso2-nexus has elapsed or updates are forced -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal on project org.wso2.carbon.appmgt.impl: Could not resolve dependencies
for project
org.wso2.carbon.appmgt:org.wso2.carbon.appmgt.impl:bundle:1.2.3-SNAPSHOT:
The following artifacts could not be resolved:
org.wso2.carbon.identity:org.wso2.carbon.identity.core:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.identity.application.mgt:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.user.mgt.stub:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.idp.mgt.stub:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.identity.application.mgt.stub:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.identity.entitlement.stub:jar:5.2.1-SNAPSHOT:
Failure to find
org.wso2.carbon.identity:org.wso2.carbon.identity.core:jar:5.2.1-SNAPSHOT
in http://maven.wso2.org/nexus/content/groups/wso2-public/ was cached in
the local repository, resolution will not be reattempted until the update
interval of wso2-nexus has elapsed or updates are forced
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.project.DependencyResolutionException: Could
not resolve dependencies for project
org.wso2.carbon.appmgt:org.wso2.carbon.appmgt.impl:bundle:1.2.3-SNAPSHOT:
The following artifacts could not be resolved:
org.wso2.carbon.identity:org.wso2.carbon.identity.core:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.identity.application.mgt:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.user.mgt.stub:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.idp.mgt.stub:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.identity.application.mgt.stub:jar:5.2.1-SNAPSHOT,
org.wso2.carbon.identity:org.wso2.carbon.identity.entitlement.stub:jar:5.2.1-SNAPSHOT:
Failure to find
org.wso2.carbon.identity:org.wso2.carbon.identity.core:jar:5.2.1-SNAPSHOT
in http://maven.wso2.org/nexus/content/groups/wso2-public/ was cached in
the local repositor

Re: [Dev] [EMM] WebApp Permission Handling at UI

[Harshan Liyanage]

Hi all,

AFAIK user-core already has a permission cache. So implementing another
cache on session will be a just unnecessary optimization. Only performance
issue will be the OSGi call to check the permission. I don't think that'll
be a huge issue since it's a in-JVM call. My only concern is will there be
any scenarios (clustered environment) where we'll web apps in a separate
carbon server without backend components?

Thanks,

Harshan Liyanage
Senior Software Engineer
WSO2

On Sep 8, 2016 10:12 AM, "Udara Rathnayake"  wrote:

>
>
> On Thu, Sep 8, 2016 at 5:17 AM, Rasika Perera  wrote:
>
>> Hi All,
>>
>> With the current migration of EMM webapp from UUF v0.1 to v0.2 (jaggery
>> based implementation) we are trying to standardize the permission check for
>> UI bits. We need to check permissions for “pages” level as well as granular
>> to the “units” level. For example; show/hide a button based on UI
>> permission. Also should notice that these permissions are not unique to the
>> front-end, thus can be directly mapped into the respective back-end osgi
>> services. For example; device enroll permission will be checked on the
>> enrollment page(front-end), as well as the inside the respective enrollment
>> osgi service(back-end).
>>
>> And also there’s a requirement that any third-party application should be
>> able to write their own UI based on our web apis. Hence we are expecting to
>> expose isAuthorized() via JAX-RS too. SOAP clients will be able to directly
>> call admin-service.
>>
>> [image: Inline image 1]
>>
>>
>>
>> As per the diagram, when a EMM web app receives a page render request
>> from the browser, UUF will execute the the method isAuthorized() at the
>> back-end JavaScript layer. JavaScript will include the “carbon” jaggery
>> module which will import the RealmService OSGi service. Using RealmService
>> we can invoke the Authorizer.isRoleAuthorized().
>>
>> Whenever, third-party application requests for a permission check via
>> EMM-API(JAX-RS), final result should be given invoking same
>> Authorizer.isRoleAuthorized() method.
>>
>> One concern on this design was how to improve the *performance* of OSGi
>> calls per permission check. One such suggestion is to retrieve all
>> permissions for the current user and persist it on the “session”. IMO this
>> would results some unforeseen issues and permission update on the backend
>> will not immediately applied on the already logged users(eg. longer session
>> timeouts). For example: users will still see the action buttons when
>> clicked on it, it will return permission error. On the other hand, managing
>> caching coherency is an extra effort for this approach. My suggestion is to
>> utilize the permission check cache(if exists) at the user-core level which
>> would be consistent across the platform.
>>
>> WDYT?
>>
>> @DS/UUF Team: I hope we need the similar permission check feature with
>> the {{permission}} handlebar helper.
>>
> ​Isn't this similar to what we are trying to solve with secured helper
> with permission?​
>
>
>>
>> --
>> With Regards,
>>
>> *Rasika Perera*
>> Software Engineer
>> LinkedIn: http://lk.linkedin.com/in/rasika90
>>
>> [image: wso2-signature-general.png] 
>>
>> WSO2 Inc. www.wso2.com
>> lean.enterprise.middleware
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Regards,
> UdaraR
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] ISSUE IN CREATING PROXY SERVICE FOR HL7 IN ESB 5.0.0

[Jagath Sisirakumara Ariyarathne]

Hi,

Could you please attach your proxy configuration and the complete carbon
log file. By looking at the error, it is due to a missing class.

Thanks,

On Wed, Sep 7, 2016 at 1:31 PM, Amutheezan Sivagnanam 
wrote:

> Hi,
> I am doing HL7 Monitoring Solution Project, for part of initial study I
> need to configure HL7 for DAS. For this I tried ESB 4.8.1 and ESB 4.9.0, it
> successfully publish data to DAS, but when I tried with ESB 5.0.0, It makes
> the proxy-service  which I used for other version(ESB 4.8.1, ESB 4.9.0) to
> disabled. I have attached the "error log" which I received while creating
> proxy-service.
>
> Regards,
> S.Amutheezan
> --
> S.Amutheezan
> *Software Engineering Intern*
> Mobile : +94 76 771 1924
> amuthee...@wso2.com
> Public Profile : 
> 
> 
> 
>
> 
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Jagath Ariyarathne
Technical Lead
WSO2 Inc.  http://wso2.com/
Email: jaga...@wso2.com
Mob  : +94 77 386 7048

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

Re: [Dev] [Puppet] Deep dive into WSO2 Puppet module implementation

[Pubudu Gunatilaka]

Hi Akila,

In puppet modules 2.1.0 release we had the capability to create directories
for a given folder structure [1] and it has used in some products [2]. In
latest puppet changes I could not find that option except the directory
list value [3]. Did we remove that feature on purpose? If not shall we add
that?

[1] -
https://github.com/wso2/puppet-modules/blob/master/modules/wso2base/manifests/configure.pp#L19
[2] -
https://github.com/wso2/puppet-modules/blob/master/hieradata/dev/wso2/wso2das/3.0.1/mesos/default.yaml#L44
[3] -
https://github.com/wso2/puppet-base/blob/master/manifests/configure.pp#L21

Thank you!

On Thu, Sep 8, 2016 at 6:23 AM, Akila Ravihansa Perera 
wrote:

> Hi,
>
> Adding few more details I'd like to highlight;
>
> * - Removed Java 3rd party Puppet module dependency*
> In earlier versions we used an external 3rd party Puppet module for Java
> installation which we thought is not necessary anymore. Therefore we have
> implemented our own Java class without any dependencies.
>
> The only contract between Java module and WSO2 Puppet modules is it should
> install Java JDK on "JAVA_HOME" path. JAVA_HOME is expected as a class
> parameter by all WSO2 Puppet modules and defaults to "/opt/java". Usually
> this is a symlink and actual JDK installation path may differ.
> As a convenience for users we have provided a basic java class in wso2base
> module which takes the JDK from Puppet file bucket, extracts it and sets
> the JAVA_HOME symlink. Java class is *not *contained in any of the WSO2
> Puppet module classes so it has to be added from site.pp. For eg:
>
> ## site.pp
> class { 'wso2base::java' } -> class { 'wso2as' }
>
> This offers greater flexibility for users to plug-in their own Java module.
>
>
> * - Use of Puppet file server*
> Earlier users had to copy jdk and product packs into respective Puppet
> module's files directory. We have improved Puppet scripts to lookup in
> Puppet file server path as well. For eg: packs are searched in
> /files/packs directory which contains packs for all the
> products. This is again a convenience for the users. This applies to
> patches and configs files as well.
> You can try this feature with Vagrant. By default it takes Puppet file
> server path as /files directory and pass that as a Puppet
> options parameter [1].
>
>
> * - Patches structure*
> With the introduction of "patch_list" parameter together with Puppet file
> server support, now you do not need to copy patches to each and every
> Puppet module! Patches are grouped by platform version therefore patches
> dir will be as follows;
>
> /files/patches
> - 4.2.0
>- patch0001
>  ...
>
> - 4.4.0
>- patch0005
>  ...
>
> Note that "patch_list" parameter is optional. Meaning, if you keep it
> empty or undef, Puppet will copy all the patches you have placed inside
> respective Puppet module's files/patches//* directory.
> If you set the "patch_list" as an array, it will search the Puppet file
> server and Puppet module's files bucket for the specified patches. The
> difference is, the latter method will error if any of the specified patches
> are missing. This is useful when you want to ensure that all required
> patches are copied.
>
>
> [1] https://github.com/wso2/puppet-common/blob/
> 56b34c4c2db11f07dca739f0e92bf1d955cfcb46/vagrant/Vagrantfile#L78
>
> Thanks.
>
>
> On Thu, Sep 8, 2016 at 5:56 AM, Akila Ravihansa Perera  > wrote:
>
>> Hi Imesh,
>>
>>
>> On Thu, Sep 8, 2016 at 3:47 AM, Imesh Gunaratne  wrote:
>>
>>> What would be the reason for using rsync in the Vagrant setup [2]? Do we
>>> update files inside the VM?
>>>
>>> [2] https://github.com/wso2/puppet-common/blob/56b34c4c2db11f07d
>>> ca739f0e92bf1d955cfcb46/vagrant/Vagrantfile#L53
>>>
>>
>> We ran into an issue when mounting Hieradata folder (which is a symlink
>> now) to the VM. It seems Vagrant does not fully support mounting symlinks
>> so we had to rsync it.
>>
>> Thanks.
>>
>> --
>> 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
>



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

Re: [Dev] Dependency issue for carbon-appmgt master branch

[Dinusha Senanayaka]

+Jena

On Thu, Sep 8, 2016 at 10:27 AM, Dulitha Wijewantha 
wrote:

> Hi guys,
> Getting build issue on master for carbon-appmgt
>
> Cheers~
> [ERROR] Failed to execute goal on project org.wso2.carbon.appmgt.impl:
> Could not resolve dependencies for project org.wso2.carbon.appmgt:org.
> wso2.carbon.appmgt.impl:bundle:1.2.3-SNAPSHOT: The following artifacts
> could not be resolved: org.wso2.carbon.identity:org.
> wso2.carbon.identity.core:jar:5.2.1-SNAPSHOT,
> org.wso2.carbon.identity:org.wso2.carbon.identity.
> application.mgt:jar:5.2.1-SNAPSHOT, org.wso2.carbon.identity:org.
> wso2.carbon.user.mgt.stub:jar:5.2.1-SNAPSHOT,
> org.wso2.carbon.identity:org.wso2.carbon.idp.mgt.stub:jar:5.2.1-SNAPSHOT,
> org.wso2.carbon.identity:org.wso2.carbon.identity.
> application.mgt.stub:jar:5.2.1-SNAPSHOT, org.wso2.carbon.identity:org.
> wso2.carbon.identity.entitlement.stub:jar:5.2.1-SNAPSHOT: Failure to find
> org.wso2.carbon.identity:org.wso2.carbon.identity.core:jar:5.2.1-SNAPSHOT
> in http://maven.wso2.org/nexus/content/groups/wso2-public/ was cached in
> the local repository, resolution will not be reattempted until the update
> interval of wso2-nexus has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project org.wso2.carbon.appmgt.impl: Could not resolve dependencies
> for project 
> org.wso2.carbon.appmgt:org.wso2.carbon.appmgt.impl:bundle:1.2.3-SNAPSHOT:
> The following artifacts could not be resolved: org.wso2.carbon.identity:org.
> wso2.carbon.identity.core:jar:5.2.1-SNAPSHOT,
> org.wso2.carbon.identity:org.wso2.carbon.identity.
> application.mgt:jar:5.2.1-SNAPSHOT, org.wso2.carbon.identity:org.
> wso2.carbon.user.mgt.stub:jar:5.2.1-SNAPSHOT,
> org.wso2.carbon.identity:org.wso2.carbon.idp.mgt.stub:jar:5.2.1-SNAPSHOT,
> org.wso2.carbon.identity:org.wso2.carbon.identity.
> application.mgt.stub:jar:5.2.1-SNAPSHOT, org.wso2.carbon.identity:org.
> wso2.carbon.identity.entitlement.stub:jar:5.2.1-SNAPSHOT: Failure to find
> org.wso2.carbon.identity:org.wso2.carbon.identity.core:jar:5.2.1-SNAPSHOT
> in http://maven.wso2.org/nexus/content/groups/wso2-public/ was cached in
> the local repository, resolution will not be reattempted until the update
> interval of wso2-nexus has elapsed or updates are forced
> at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.
> getDependencies(LifecycleDependencyResolver.java:210)
> at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.
> resolveProjectDependencies(LifecycleDependencyResolver.java:117)
> at org.apache.maven.lifecycle.internal.MojoExecutor.
> ensureDependenciesAreResolved(MojoExecutor.java:258)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:201)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
> buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.
> buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.
> singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.
> execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> 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.codehaus.plexus.classworlds.launcher.Launcher.
> launchEnhanced(Launcher.java:290)
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> launch(Launcher.java:230)
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.
> main(Launcher.java:352)
> Caused by: org.apache.maven.project.DependencyResolutionException: Could
> not resolve dependencies for project org.wso2.carbon.appmgt:org.
> wso2.carbon.appmgt.impl:bundle:1.2.3-SNAPSHOT: The following artifacts
> could not be resolved: org.wso2.carbon.identity:org.
> wso2.carbon.identity.core:jar:5.2.1-SNAPSHOT,
> org.wso2.carbon.identity:org.wso2.carbon.identity.
> application.mgt:jar:5.2.1-SNAPSHOT, org.wso2.carbon.identity:org.
> wso2.carbon.user.mgt.stub:jar:5.2.1-SNAPSHOT,
> org.wso2.carbon.identity:org.wso2.carbon.idp.mgt.stub:jar:5.2.1-SNAPSHOT,
> org.wso2.carbon.identity:org.wso2.carbon.identity.
> application.mgt.stub:jar:5.2.1-SNAPS

Re: [Dev] Reverting a patch when the original jar is not in patch0000 directory

[Omindu Rathnaweera]

Yeah. SP1 was there.

On Thu, Sep 8, 2016 at 8:19 AM, Harsha Thirimanna  wrote:

> Did you apply any patches before you install the feature ? As you said, it
> may be a bug.
>
> On Sep 8, 2016 12:23 AM, "Omindu Rathnaweera"  wrote:
>
>> Hi,
>>
>> Noticed that we cannot revert a patch if the particular jar is not in the
>> patch directory. Assume that we install a feature to a product which
>> already has the patch directory created. Then, we patch one of the jars
>> in that new feature, and later on we remove that patch from the patches
>> directory. The plugins directory will still have the patched jar even if
>> the patch is removed. I assume this is because the new jars related to the
>> feature is not getting copied to patch during feature installation.
>>
>> In my case I installed the FB authenticator to IS 5.0.0 + SP1 applied and
>> patched the authenticator. To revert the patch I had to copy the old jar to
>> the plugins directory. Even reinstalling the feature didn't restore the
>> jar.
>>
>> Not sure if it's a buggy behavior, if not is there an alternative way to
>> revert it ?
>>
>> Thanks,
>> Omindu.
>>
>> --
>> Omindu Rathnaweera
>> Software Engineer, WSO2 Inc.
>> Mobile: +94 771 197 211
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>


-- 
Omindu Rathnaweera
Software Engineer, WSO2 Inc.
Mobile: +94 771 197 211
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] ISSUE IN CREATING PROXY SERVICE FOR HL7 IN ESB 5.0.0

[Amutheezan Sivagnanam]

Hi,
I have attached the files for Error Occured While Creating the Proxy
Service and the corresponding proxy service file.
Thanks,

On Thu, Sep 8, 2016 at 10:43 AM, Jagath Sisirakumara Ariyarathne <
jaga...@wso2.com> wrote:

> Hi,
>
> Could you please attach your proxy configuration and the complete carbon
> log file. By looking at the error, it is due to a missing class.
>
> Thanks,
>
> On Wed, Sep 7, 2016 at 1:31 PM, Amutheezan Sivagnanam  > wrote:
>
>> Hi,
>> I am doing HL7 Monitoring Solution Project, for part of initial study I
>> need to configure HL7 for DAS. For this I tried ESB 4.8.1 and ESB 4.9.0, it
>> successfully publish data to DAS, but when I tried with ESB 5.0.0, It makes
>> the proxy-service  which I used for other version(ESB 4.8.1, ESB 4.9.0) to
>> disabled. I have attached the "error log" which I received while creating
>> proxy-service.
>>
>> Regards,
>> S.Amutheezan
>> --
>> S.Amutheezan
>> *Software Engineering Intern*
>> Mobile : +94 76 771 1924
>> amuthee...@wso2.com
>> Public Profile : 
>> 
>> 
>> 
>>
>> 
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Jagath Ariyarathne
> Technical Lead
> WSO2 Inc.  http://wso2.com/
> Email: jaga...@wso2.com
> Mob  : +94 77 386 7048
> 
>



-- 
S.Amutheezan
*Software Engineering Intern*
Mobile : +94 76 771 1924
amuthee...@wso2.com
Public Profile : 







error_log
Description: Binary data

http://ws.apache.org/ns/synapse";
   name="hl7testproxy"
   transports="https,http,hl7"
   statistics="enable"
   trace="enable"
   startOnLoad="true">
   
  
 
  
  
 
 
  
  
 
  
   
   admin
   admin
   true
   tcp://10.100.4.201:7611
   ssl://10.100.4.201:7711
   proxy
   9292
   true
   


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

Re: [Dev] [EMM] WebApp Permission Handling at UI

[Rasika Perera]

Hi Harshan/Udara,

Please find my inline comments.

Isn't this similar to what we are trying to solve with secured helper with
> permission?​

​Yes. Only difference is we don't use a helper for this since it doesn't
add much value in this case.​ Instead we are setting a flag at the Backend
JavaScript layer so templating layer can change rendering based on that
flag.

AFAIK user-core already has a permission cache. So implementing another
> cache on session will be a just unnecessary optimization. Only performance
> issue will be the OSGi call to check the permission. I don't think that'll
> be a huge issue since it's a in-JVM call.

​+1​.

My only concern is will there be any scenarios (clustered environment)
> where we'll web apps in a separate carbon server without backend components?
>

Currently login process is done through OSGi calls(via jaggery "carbon"
module). UserCore OSGi services are available with carbon platform for any
given carbon server. Hence, it won't be an issue. But we might need to
share user store across nodes.

Thanks,
Rasika


On Thu, Sep 8, 2016 at 10:34 AM, Harshan Liyanage  wrote:

> Hi all,
>
> AFAIK user-core already has a permission cache. So implementing another
> cache on session will be a just unnecessary optimization. Only performance
> issue will be the OSGi call to check the permission. I don't think that'll
> be a huge issue since it's a in-JVM call. My only concern is will there be
> any scenarios (clustered environment) where we'll web apps in a separate
> carbon server without backend components?
>
> Thanks,
>
> Harshan Liyanage
> Senior Software Engineer
> WSO2
>
> On Sep 8, 2016 10:12 AM, "Udara Rathnayake"  wrote:
>
>>
>>
>> On Thu, Sep 8, 2016 at 5:17 AM, Rasika Perera  wrote:
>>
>>> Hi All,
>>>
>>> With the current migration of EMM webapp from UUF v0.1 to v0.2 (jaggery
>>> based implementation) we are trying to standardize the permission check for
>>> UI bits. We need to check permissions for “pages” level as well as granular
>>> to the “units” level. For example; show/hide a button based on UI
>>> permission. Also should notice that these permissions are not unique to the
>>> front-end, thus can be directly mapped into the respective back-end osgi
>>> services. For example; device enroll permission will be checked on the
>>> enrollment page(front-end), as well as the inside the respective enrollment
>>> osgi service(back-end).
>>>
>>> And also there’s a requirement that any third-party application should
>>> be able to write their own UI based on our web apis. Hence we are expecting
>>> to expose isAuthorized() via JAX-RS too. SOAP clients will be able to
>>> directly call admin-service.
>>>
>>> [image: Inline image 1]
>>>
>>>
>>>
>>> As per the diagram, when a EMM web app receives a page render request
>>> from the browser, UUF will execute the the method isAuthorized() at the
>>> back-end JavaScript layer. JavaScript will include the “carbon” jaggery
>>> module which will import the RealmService OSGi service. Using RealmService
>>> we can invoke the Authorizer.isRoleAuthorized().
>>>
>>> Whenever, third-party application requests for a permission check via
>>> EMM-API(JAX-RS), final result should be given invoking same
>>> Authorizer.isRoleAuthorized() method.
>>>
>>> One concern on this design was how to improve the *performance* of OSGi
>>> calls per permission check. One such suggestion is to retrieve all
>>> permissions for the current user and persist it on the “session”. IMO this
>>> would results some unforeseen issues and permission update on the backend
>>> will not immediately applied on the already logged users(eg. longer session
>>> timeouts). For example: users will still see the action buttons when
>>> clicked on it, it will return permission error. On the other hand, managing
>>> caching coherency is an extra effort for this approach. My suggestion is to
>>> utilize the permission check cache(if exists) at the user-core level which
>>> would be consistent across the platform.
>>>
>>> WDYT?
>>>
>>> @DS/UUF Team: I hope we need the similar permission check feature with
>>> the {{permission}} handlebar helper.
>>>
>> ​Isn't this similar to what we are trying to solve with secured helper
>> with permission?​
>>
>>
>>>
>>> --
>>> With Regards,
>>>
>>> *Rasika Perera*
>>> Software Engineer
>>> LinkedIn: http://lk.linkedin.com/in/rasika90
>>>
>>> [image: wso2-signature-general.png] 
>>>
>>> WSO2 Inc. www.wso2.com
>>> lean.enterprise.middleware
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Regards,
>> UdaraR
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>


-- 
With Regards,

*Rasika Perera*
Software Engineer
LinkedIn: http://lk.linkedin.com/in/rasika90

[image: wso2-signature-general.png] 

Re: [Dev] Reverting a patch when the original jar is not in patch0000 directory

[Niranjan Karunanandham]

Hi Omindu,

As per the offline discussion we had yesterday, it looks like after the
initial backup of the jars into patch, it does not backup the new jars
which are installed via features. In-order to revert the jar, you would
need to download the jar (from the feature) and copy it to the plugins
directory. Please create a JIRA for this in Kernal.

Regards,
Nira

On Thu, Sep 8, 2016 at 11:16 AM, Omindu Rathnaweera  wrote:

> Yeah. SP1 was there.
>
> On Thu, Sep 8, 2016 at 8:19 AM, Harsha Thirimanna 
> wrote:
>
>> Did you apply any patches before you install the feature ? As you said,
>> it may be a bug.
>>
>> On Sep 8, 2016 12:23 AM, "Omindu Rathnaweera"  wrote:
>>
>>> Hi,
>>>
>>> Noticed that we cannot revert a patch if the particular jar is not in
>>> the patch directory. Assume that we install a feature to a product
>>> which already has the patch directory created. Then, we patch one of
>>> the jars in that new feature, and later on we remove that patch from the
>>> patches directory. The plugins directory will still have the patched jar
>>> even if the patch is removed. I assume this is because the new jars related
>>> to the feature is not getting copied to patch during feature
>>> installation.
>>>
>>> In my case I installed the FB authenticator to IS 5.0.0 + SP1 applied
>>> and patched the authenticator. To revert the patch I had to copy the old
>>> jar to the plugins directory. Even reinstalling the feature didn't restore
>>> the jar.
>>>
>>> Not sure if it's a buggy behavior, if not is there an alternative way to
>>> revert it ?
>>>
>>> Thanks,
>>> Omindu.
>>>
>>> --
>>> Omindu Rathnaweera
>>> Software Engineer, WSO2 Inc.
>>> Mobile: +94 771 197 211
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>
>
> --
> Omindu Rathnaweera
> Software Engineer, WSO2 Inc.
> Mobile: +94 771 197 211
>



-- 


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

Re: [Dev] ISSUE IN CREATING PROXY SERVICE FOR HL7 IN ESB 5.0.0

[Amutheezan Sivagnanam]

Hi,
I redo every tasks from beginning and same error occurs as previous case. I
have attached the errorlog and modified Axis2.xml file (for enabling HL7
transport).
Thanks,

On Thu, Sep 8, 2016 at 11:42 AM, Amutheezan Sivagnanam 
wrote:

> Hi,
> I have attached the files for Error Occured While Creating the Proxy
> Service and the corresponding proxy service file.
> Thanks,
>
> On Thu, Sep 8, 2016 at 10:43 AM, Jagath Sisirakumara Ariyarathne <
> jaga...@wso2.com> wrote:
>
>> Hi,
>>
>> Could you please attach your proxy configuration and the complete carbon
>> log file. By looking at the error, it is due to a missing class.
>>
>> Thanks,
>>
>> On Wed, Sep 7, 2016 at 1:31 PM, Amutheezan Sivagnanam <
>> amuthee...@wso2.com> wrote:
>>
>>> Hi,
>>> I am doing HL7 Monitoring Solution Project, for part of initial study I
>>> need to configure HL7 for DAS. For this I tried ESB 4.8.1 and ESB 4.9.0, it
>>> successfully publish data to DAS, but when I tried with ESB 5.0.0, It makes
>>> the proxy-service  which I used for other version(ESB 4.8.1, ESB 4.9.0) to
>>> disabled. I have attached the "error log" which I received while creating
>>> proxy-service.
>>>
>>> Regards,
>>> S.Amutheezan
>>> --
>>> S.Amutheezan
>>> *Software Engineering Intern*
>>> Mobile : +94 76 771 1924
>>> amuthee...@wso2.com
>>> Public Profile : 
>>> 
>>> 
>>> 
>>>
>>> 
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Jagath Ariyarathne
>> Technical Lead
>> WSO2 Inc.  http://wso2.com/
>> Email: jaga...@wso2.com
>> Mob  : +94 77 386 7048
>> 
>>
>
>
>
> --
> S.Amutheezan
> *Software Engineering Intern*
> Mobile : +94 76 771 1924
> amuthee...@wso2.com
> Public Profile : 
> 
> 
> 
>
> 
>



-- 
S.Amutheezan
*Software Engineering Intern*
Mobile : +94 76 771 1924
amuthee...@wso2.com
Public Profile : 







errorlog
Description: Binary data










true

true


false

false


false

work/mtom

4000


false


inmemory




services


axis2services


axis2modules


WSO2 ESB 5.0.0
WSO2 ESB 5.0.0



false






false


true


3


repository/deployment/server/synapse-configs

.

.

localhost

true


















































http://www.w3.org/ns/wsdl/in-only";
 class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"/>
http://www.w3.org/ns/wsdl/robust-in-only";
 class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"/>
http://www.w3.org/ns/wsdl/in-out";
 class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>

























	



















	















 
8280
true


org.wso2.carbon.mediation.transport.handlers.PassThroughNHttpGetProcessor



 
8243
true
TLSv1,TLSv1.1,TLSv1.2


org.wso2.carbon.mediation.transport.handlers.PassThroughNHttpGetProcessor


repository/resources/security/wso2carbon.jks
JKS
wso2carbon
wso2carbon




repository/resources/security/client-truststore.jks
JKS
wso2carbon































   






true







true


repository/resou