Community
Participate
Working Groups
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).
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)
Created attachment 194518 [details] mylyn/context/zip
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.
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.