Hi Asanka, we cannot just deprecate that service at the moment since BPELs are using it. If we do, we have to change BPELs and other stuff where its going to be a huge refactoring :)
On Sat, Mar 28, 2015 at 11:28 PM, Punnadi Gunarathna <[email protected]> wrote: > Hi, > > And of course the BPELs will invoke the methods in > ApplicationManagementService. > Hi Asanka, > > Think of a scenario where jenkins plugin or other service which is hosted > outside AF runtime wanted to perform Application operations; then exposing > them as a web service is the way. I think that's the rationale behind > making ApplicationManagementService a SOAP one. > > Regards, > Anuruddha. > > On Sat, Mar 28, 2015 at 10:37 AM, Asanka Dissanayake <[email protected]> > wrote: > >> 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 >> >> > > > -- > *Anuruddha Premalal* > Software Eng. | WSO2 Inc. > Mobile : +94710461070 > Web site : www.regilandvalley.com > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *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
