Yes ,Punnadi. I get the point that all the methods are moved to ApplicationInfoService.Given that all the methods are moved to ApplicationInfoService and whoever wants to consume those methods can use ApplicationInfoService. But why ApplicationManagementService is going to be a SOAP service, if all the methods were in this class moved to another class why can't it cannot just deprecated ? What is the goal trying to achieve by making it only a SOAP service.
On Sat, Mar 28, 2015 at 1:27 PM, Punnadi Gunarathna <[email protected]> wrote: > Hi Asanka, > > Yes, ApplicationManagementService will become a simple axis2 device and > it's osginess will be removed. Why we needed this refactoring is, currently > it contains large number of the methods despite their actual place. We have > a separate class called ApplicationInfoService, which should contain all > the application specific methods and ApplicationUserMgtService which > should contain the user specific methods. Those classes are OSGi services. > On Mar 28, 2015 9:25 PM, "Mahesh Chinthaka" <[email protected]> wrote: > >> Hi Asanka, >> >> This is not reverting back what was done early. These methods will be >> called via OSGI calls in future too. >> Only change will be these methods will be moved from >> ApplicationManagementService to ApplicationInfoService. >> So no osgi methods will be available in ApplicationManagementService. >> Instead all application related osgi methods will be in >> ApplicationInfoService. >> >> Did I clear your doubt ? >> >> On Sat, Mar 28, 2015 at 9:13 PM, Asanka Dissanayake <[email protected]> >> wrote: >> >>> 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* >>> >> >> >> >> -- >> *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
