[
https://issues.apache.org/jira/browse/AXIS2-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artur Linhart updated AXIS2-5051:
---------------------------------
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).
was:
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 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 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).
Summary: wsdl2java Stub generation should be optimized to allow better
customization of exception mappings (was: wsdl2java Stub generation shoudl be
optimized to allow better customization of exception mappings)
> wsdl2java Stub generation should 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.4.1, 1.5.4
> Environment: java
> Reporter: Artur Linhart
> Labels: wsdl2java
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> 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).
--
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
