wsdl2java Stub generation shoudl be optimized to allow better customization of
exception mappings
-------------------------------------------------------------------------------------------------
Key: AXIS2-5051
URL: https://issues.apache.org/jira/browse/AXIS2-5051
Project: Axis2
Issue Type: Improvement
Components: wsdl
Affects Versions: 1.5.4, 1.4.1
Environment: java
Reporter: Artur Linhart
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. 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 maps,
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 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).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
