[Dev] [SS] [IS] Programmatically Creating Service Providers at Server Start Up
Hi, When I was working on $Subject, found that this can't be done due to not having an OSGi service from IS level but only admin service. AFAIK, it's not recommend to call admin service unless server boot up. Use Case: SS has static/system resources (environments, instances and databases), so we need to assign defaults permissions (if not already assigned) for these at server start up. For that we need to first create service provider and then store permissions according to available resources. Approaches tried out: 1. Used application management configuration (repository/conf/identity/service-provider/default.xml). By doing that it's not got persisted into database/registry instead it keeps all the service provider information in a static hash map (in memory). Since changes done to in memory not got persisted it will be lost at server reboot. 2. Called admin service programmatically , this is not recommended since carbon context and other services may not already activated. At this moment solution what we can see is, implementing an OSGi service for application management operations. @Johann, WDYT? Cheers, Dhanuka *Dhanuka Ranasinghe* Senior Software Engineer WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 715381915 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [SS] [IS] Programmatically Creating Service Providers at Server Start Up
PING.. :-) *Dhanuka Ranasinghe* Senior Software Engineer WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 715381915 On Wed, Sep 3, 2014 at 5:27 PM, Dhanuka Ranasinghe dhan...@wso2.com wrote: Hi, When I was working on $Subject, found that this can't be done due to not having an OSGi service from IS level but only admin service. AFAIK, it's not recommend to call admin service unless server boot up. Use Case: SS has static/system resources (environments, instances and databases), so we need to assign defaults permissions (if not already assigned) for these at server start up. For that we need to first create service provider and then store permissions according to available resources. Approaches tried out: 1. Used application management configuration (repository/conf/identity/service-provider/default.xml). By doing that it's not got persisted into database/registry instead it keeps all the service provider information in a static hash map (in memory). Since changes done to in memory not got persisted it will be lost at server reboot. 2. Called admin service programmatically , this is not recommended since carbon context and other services may not already activated. At this moment solution what we can see is, implementing an OSGi service for application management operations. @Johann, WDYT? Cheers, Dhanuka *Dhanuka Ranasinghe* Senior Software Engineer WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 715381915 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [SS] [IS] Programmatically Creating Service Providers at Server Start Up
+1. We do not recommend to invoke admin services programmatically. Thanks, Sameera. On Thu, Sep 4, 2014 at 10:54 AM, Prabath Abeysekera praba...@wso2.com wrote: Hi Guys, On Wed, Sep 3, 2014 at 5:27 PM, Dhanuka Ranasinghe dhan...@wso2.com wrote: Hi, When I was working on $Subject, found that this can't be done due to not having an OSGi service from IS level but only admin service. AFAIK, it's not recommend to call admin service unless server boot up. Use Case: SS has static/system resources (environments, instances and databases), so we need to assign defaults permissions (if not already assigned) for these at server start up. For that we need to first create service provider and then store permissions according to available resources. Approaches tried out: 1. Used application management configuration (repository/conf/identity/service-provider/default.xml). By doing that it's not got persisted into database/registry instead it keeps all the service provider information in a static hash map (in memory). Since changes done to in memory not got persisted it will be lost at server reboot. 2. Called admin service programmatically , this is not recommended since carbon context and other services may not already activated. At this moment solution what we can see is, implementing an OSGi service for application management operations. +1. The only cleaner approach available for us to achieve this would be to have an OSGi API exposed from the application management component. I believe, this is going to be useful not only for us, but also for anyone else who may come across the same need as this appears to be a pretty common use-case across the platform. Can we please have this implemented sometime soon? Cheers, Prabath @Johann, WDYT? Cheers, Dhanuka *Dhanuka Ranasinghe* Senior Software Engineer WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 715381915 -- Prabath Abeysekara Associate Technical Lead, Data TG. WSO2 Inc. Email: praba...@wso2.com Mobile: +94774171471 -- Sameera Jayasoma, Software Architect, WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://sameera.adahas.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [SS] [IS] Programmatically Creating Service Providers at Server Start Up
Hi Guys, On Wed, Sep 3, 2014 at 5:27 PM, Dhanuka Ranasinghe dhan...@wso2.com wrote: Hi, When I was working on $Subject, found that this can't be done due to not having an OSGi service from IS level but only admin service. AFAIK, it's not recommend to call admin service unless server boot up. Use Case: SS has static/system resources (environments, instances and databases), so we need to assign defaults permissions (if not already assigned) for these at server start up. For that we need to first create service provider and then store permissions according to available resources. Approaches tried out: 1. Used application management configuration (repository/conf/identity/service-provider/default.xml). By doing that it's not got persisted into database/registry instead it keeps all the service provider information in a static hash map (in memory). Since changes done to in memory not got persisted it will be lost at server reboot. 2. Called admin service programmatically , this is not recommended since carbon context and other services may not already activated. At this moment solution what we can see is, implementing an OSGi service for application management operations. +1. The only cleaner approach available for us to achieve this would be to have an OSGi API exposed from the application management component. I believe, this is going to be useful not only for us, but also for anyone else who may come across the same need as this appears to be a pretty common use-case across the platform. Can we please have this implemented sometime soon? Cheers, Prabath @Johann, WDYT? Cheers, Dhanuka *Dhanuka Ranasinghe* Senior Software Engineer WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 715381915 -- Prabath Abeysekara Associate Technical Lead, Data TG. WSO2 Inc. Email: praba...@wso2.com Mobile: +94774171471 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
