Hi Mahesh, Please find my comments inline. On Wed, Mar 18, 2015 at 10:58 AM, Mahesh Chinthaka <[email protected]> wrote:
> Hi all, > Im working on [a] > > At the moment we have > 1. ApplicationManagementService > 2. ApplicationInfoService > 3. ApplicationUserMgtService > > All the tasks/methods that UI needs to do related with users will be in > ApplicationUserMgtService (IMO ideally this service should be renamed as > UserManagementService). > All the tasks/methods that UI needs to related with applications will be > in ApplicationInfoService. > +1 for refactoring the names > > At the moment ApplicationManagementService has both user related tasks as > well as application related tasks. > What I'm going to do is identify those methods and move accordingly to > either ApplicationUserMgtService or ApplicationInfoService. In that way > ApplicationManagementService will no longer be a osgi service and it will > only be a soap service. > Could you please explain the rationale behind the decision of removing the OSGInes ? AFAIK, these services are called by Jaggery App and some other components too. AFAIR, we did a refactoring once in Jaggery App , removing all the web service calls and made them OSGI service calls .Reason behind that was, when there is a web service call it consumes a 1 thread in the connection pool just to call to a service in the same server. So we did that to save some connections and call something that is available during the runtime. What is the reason to revert that back ? Is that something related to clustering? > Here are the methods that I have identified, > > [1] - getApplication(applicationKey) > > [2] - deleteApplication(applicationKey) > > [3] - getApplicationUrl(applicationKey, version, stage, tenantDomain); > > [4] - getApplicationStatus(applicationKey, version, stage, tenantDomain); > > [5] - > getAllVersionsOfApplicationPerUser(modManager.getTenantDomain(),applicationKey, > userName); > > [6] - getAllVersionsOfApplication(tenantDomain, applicationKey); > > [7] - getBuildandDelpoyedStatus(applicationKey,tenantDomain,version); > > [8] - updateRxtWithPromoteState(appKey,nextStage,version,"Promote",state); > > [9] - publishSetApplicationAutoBuild(applicationKey, stageName, version, > isBuild); > > [10] - publishSetApplicationAutoDeploy(applicationKey, stageName, version, > isDeploy); > > > IMO all above methods should be moved to ApplicationInfoService. WDYT ? > > > [a] - https://wso2.org/jira/browse/APPFAC-3011 > > -- > *Mahesh Chinthaka Vidanagama* | Software Engineer > WSO2, Inc | lean. enterprise. middleware. > #20, Palm Grove, Colombo 03, Sri Lanka > Mobile: +94 71 63 63 083 | Work: +94 112 145 345 > Email: [email protected] | Web: www.wso2.com > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *Asanka DissanayakeSoftware Engineer* *WSO2 Inc. - lean . enterprise . middleware | wso2.com <http://wso2.com/>* *email: [email protected] <[email protected]>, blog: cyberwaadiya.blogspot.com <http://cyberwaadiya.blogspot.com>, asankastechtalks.wordpress.com <http://asankastechtalks.wordpress.com> mobile: +94 71 8373821*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
