#282 CustomCallingConvention improvements
Here is a list of suggested improvements for the CustomCallingConvention class.
#1: The convertRequestImpl method can currently only throw InvalidRequestException and FunctionNotSpecifiedException. What needs to be done when the implementation needs to deal with a different error situation is undefined.
I propose adding ConvertRequestException to the throws clause.
ConvertRequestException should probably just extend Exception.
I propose introducing this in XINS 2.x, since it would not break existing code.
#2. Currently, convertResultImpl can only throw an IOException. However, the method may fail for many reasons other than an I/O error. For example a calling convention that calls a back-end API (CallException) or performs an RMI call (RemoteException).
I propose adding ConvertRequestException to the throws clause. ConvertRequestException should probably just extend Exception.
Internally, in the CallingConvention.convertResult method, this IOException should then be wrapped inside a ConvertResultException. And it should be noted in the Javadoc documentation that throwing an IOException is not advised. It will work for now, but the IOException is expected to be removed in the future (see #3)
#3. After implementing #2, I propose that at some point convertResultImpl is changed so it no longer allows throwing IOException, only ConvertResultException. The ConvertResultException may contain a cause exception, which could be an IOException.
I propose introducing this in XINS 3.0, since it would break existing code.
#4. I propose making matches(HttpServletRequest) abstract, as it was intended to be.
I propose introducing this in XINS 3.0, since it would break existing code.
I will probably implement this in my own repository (at least #1 and #2), since I need to have something like this for my project.
Logged In: YES
user_id=11053
Originator: YES
#5. In convertRequest and convertResult, then behaviour of the convertResultImpl method is checked. When that is considered invalid, then Utils.logProgrammingError is called. However, the detecting class/method and subject class/method are not specified, causing the logProgrammingError method to produce an incorrect log message.
The detecting class/method and subject class/method should be specified explicitly.
This change would not introduce any incompatibilities.