Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@axis.apache.org
Date: Fri, 20 May 2011 16:14:47 +0000 (UTC)
From: "Artur Linhart (JIRA)" <jira@apache.org>
To: java-dev@axis.apache.org
Message-ID: 
 <1724889021.30902.1305908087360.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1881051123.30893.1305907848710.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (AXIS2-5051) wsdl2java Stub generation shoudl be
 optimized to allow better customization of exception mappings
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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