Guys
No one is stopping changing the BPELs. I don't like the idea of keeping it
because bpels are using it. Who said you cannot change the bpels. If you are
saying this is a soap api for users +1. But -1 for the idea that it’s used by
the bpels reasoning.
Thanks & Regards
Danushka Fernando
Software Engineer
WSO2 inc. http://wso2.com/
Mobile : +94716332729
From: Mahesh Chinthaka
Sent: Sunday, March 29, 2015 11:09 AM
To: Punnadi Gunarathna
Cc: WSO2 Developers' List
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 Dissanayake
Software Engineer
WSO2 Inc. - lean . enterprise . middleware | wso2.com
email: [email protected], blog: cyberwaadiya.blogspot.com,
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 Dissanayake
Software Engineer
WSO2 Inc. - lean . enterprise . middleware | wso2.com
email: [email protected], blog: cyberwaadiya.blogspot.com,
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
