axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Artur Linhart (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AXIS2-5051) wsdl2java Stub generation shoudl be optimized to allow better customization of exception mappings
Date Fri, 20 May 2011 16:14:47 GMT

     [ 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 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).


  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. 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).


    Remaining Estimate: 8h  (was: 24h)
     Original Estimate: 8h  (was: 24h)

> 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.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 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).

--
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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message