Major Description
The Stub generates the processing methods with the help of the internal variables for exception mappings
//hashmaps to keep the fault mapping
private java.util.HashMap faultExceptionNameMap = new java.util.HashMap();
private java.util.HashMap faultExceptionClassNameMap = new java.util.HashMap();
private java.util.HashMap faultMessageMap = new java.util.HashMap();
which are populate in private method populateFaults.
All internal access to the internal mappings is done through the direct call of the methods of the given maps, like:
faultExceptionNameMap.containsKey(faultElt.getQName())
it makes to the user of the generated classes impossible to define some own exception mappings without the change of the generated code, so after the regeneration it has to be again resynced, etc. - a lot of unnecessary work. Also the split of the data into three lists is not very systematic.
Solution for this would be to define the methods, hiding the concrete implementation of the retrieving of the meppings and use them everywhere instead of calling the methods of faultExceptionNameMap, faultExceptionClassNameMap and faultMessageMap directly. They could be created similary to following proposal:
protected boolean exceptionQNameRegistered(QName)
protected String getFaultExceptionName(QName)
protected String getFaultExceptionClassName(QName)
protected String getFaultMessageName(QName)
The default implementation could simply hide the same maps into the given methods, but everybody could redefine the methods in inherited stub class without the necessity to change the generated class and append some own exception, which could be also inherited from the generated one.
This would be with a small amount of work a great improvement the possibility to use the generated stub classes without modifications.
Also, today, because of the impossibility to redefine simply the exception mappings, nobody can see the fault messages by the faults thrown in client (see the issue AXIS2-5050).
