Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 344491

Summary: make AbstractSoapClient an AbstractClient
Product: z_Archived Reporter: Thomas Ehrnhoefer <thomas.ehrnhoefer>
Component: MylynAssignee: Mylyn Inbox <mylyn-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: steffen.pingel
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Attachments:
Description Flags
patch v1
none
mylyn/context/zip none

Description Thomas Ehrnhoefer CLA 2011-05-02 13:20:19 EDT 
Seems like the abstractSoapClient contains nothing Soap specific, just login / session specific. This can apply to non-soap clients as well (e.g. when connecting to an SDK that has expiring logins).
I would propose creating an AbstractClient, move everything from AbstractSoapClient in there, and have AbstractSoapClient inherit from AbstractClient (for future soap specific stuff, plus API compatibility).
Comment 1 Thomas Ehrnhoefer CLA 2011-05-02 13:41:38 EDT 
Created attachment 194517 [details]
patch v1

something like this, with the AbstractSoapClient (and potentially a client implementation) overriding the callOnce for some specific behaviout (e.g. handling special exception differently)
Comment 2 Thomas Ehrnhoefer CLA 2011-05-02 13:41:39 EDT 
Created attachment 194518 [details]
mylyn/context/zip
Comment 3 Steffen Pingel CLA 2011-05-07 19:50:19 EDT 
I see your point but given the simple logic in AbstractSoapClient there is very little code reuse and unless the abstract class is used as a common abstraction in other contexts there is not sufficient value to make this API.
Comment 4 Thomas Ehrnhoefer CLA 2011-05-08 12:39:13 EDT 
Well, it is (can be) used as common abstraction in pretty much every client that is not SOAP, but has session based login. I think we at Tasktop have currently at least 3 connectors that could consume this abstraction, probably more. I agree it's not much at this point, but it's code duplication nevertheless.