You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Artur Linhart (JIRA)" <ji...@apache.org> on 2011/05/20 17:46:47 UTC
[jira] [Created] (AXIS2-5050) wsdl2java generated exceptions do not
display the received fault messages if created with constructor without
parameters (f.e. if received and thrown in Stub)
wsdl2java generated exceptions do not display the received fault messages if created with constructor without parameters (f.e. if received and thrown in Stub)
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: AXIS2-5050
URL: https://issues.apache.org/jira/browse/AXIS2-5050
Project: Axis2
Issue Type: Improvement
Components: wsdl
Affects Versions: 1.5.4, 1.4.1
Environment: all
Reporter: Artur Linhart
If the exceptions generated from wsdl/xsd are used with the constructor without parameters, then they just contain as a exception message the name of the class and ignore the complete content of the exception, even if there is much more information available. This is especially problem in Stubs, where wsdl2java generates the received exception instantiation with exceptionClass.newInstance(); what leads to the fact in stub is effectively no exception message available. So, for example in the Unit-tests results normally the stacktrace of some exceltion ExceptionClassName with exception message is shown without any detail, You have always to go into the debugger and figure out what is the real fault behind the exception messsage "ExceptionClassName" is. This is very time consuming. Sure, one can take the exception generated by Axis and extend it, but then if the wsdl changes, it has to be regenerated, resynchronized, etc. etc.
So, my proposal is to override in the generated exception the method getMessage() by something similar to:
/**
* @see java.lang.Throwable#getMessage()
*/
@Override
public String getMessage() {
String locMessage = super.getMessage();
if (getFaultMessage() != null && getFaultMessage().getXXXXFaultMessageContent() != null && (locMessage == null || this.getClass().this.getClass().getName().endsWith("." + locMessage))) {
locMessage = getFaultMessage().getXXXXFaultMessageContent().getFaultMessage()
}
return locMessage;
}
where getXXXXFaultMessageContent is the name, generated according to the name convention already used in the wsdl2java tool.
With similar construct there would be no necessity to change the generated code and would be very helpful for the devault usage of the Axis2 tools.
--
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
[jira] [Updated] (AXIS2-5050) wsdl2java generated exceptions do not
display the received fault messages if created with constructor without
parameters (f.e. if received and thrown in Stub)
Posted by "Artur Linhart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Artur Linhart updated AXIS2-5050:
---------------------------------
Description:
If the exceptions generated from wsdl/xsd are used with the constructor without parameters, then they just contain as a exception message the name of the class and ignore the complete content of the exception, even if there is much more information available. This is especially problem in Stubs, where wsdl2java generates the received exception instantiation with exceptionClass.newInstance(); what leads to the fact in stub is effectively no exception message available. So, for example in the Unit-tests results normally the stacktrace of some exceltion ExceptionClassName with exception message is shown without any detail, You have always to go into the debugger and figure out what is the real fault behind the exception messsage "ExceptionClassName" is. This is very time consuming. Sure, one can take the exception generated by Axis and extend it, but then if the wsdl changes, it has to be regenerated, resynchronized, etc. etc.
So, my proposal is to override in the generated exception the method getMessage() by something similar to:
/**
* @see java.lang.Throwable#getMessage()
*/
@Override
public String getMessage() {
String locMessage = super.getMessage();
if (getFaultMessage() != null && getFaultMessage().getXXXXFaultMessageContent() != null && (locMessage == null || this.getClass().this.getClass().getName().endsWith("." + locMessage))) {
locMessage = getFaultMessage().getXXXXFaultMessageContent().getFaultMessage()
}
return locMessage;
}
where getXXXXFaultMessageContent is the name of the access method to fault content, generated according to the name convention already used in the wsdl2java tool.
With similar construct there would be no necessity to change the generated code and would be very helpful for the default usage of the Axis2 tools.
was:
If the exceptions generated from wsdl/xsd are used with the constructor without parameters, then they just contain as a exception message the name of the class and ignore the complete content of the exception, even if there is much more information available. This is especially problem in Stubs, where wsdl2java generates the received exception instantiation with exceptionClass.newInstance(); what leads to the fact in stub is effectively no exception message available. So, for example in the Unit-tests results normally the stacktrace of some exceltion ExceptionClassName with exception message is shown without any detail, You have always to go into the debugger and figure out what is the real fault behind the exception messsage "ExceptionClassName" is. This is very time consuming. Sure, one can take the exception generated by Axis and extend it, but then if the wsdl changes, it has to be regenerated, resynchronized, etc. etc.
So, my proposal is to override in the generated exception the method getMessage() by something similar to:
/**
* @see java.lang.Throwable#getMessage()
*/
@Override
public String getMessage() {
String locMessage = super.getMessage();
if (getFaultMessage() != null && getFaultMessage().getXXXXFaultMessageContent() != null && (locMessage == null || this.getClass().this.getClass().getName().endsWith("." + locMessage))) {
locMessage = getFaultMessage().getXXXXFaultMessageContent().getFaultMessage()
}
return locMessage;
}
where getXXXXFaultMessageContent is the name, generated according to the name convention already used in the wsdl2java tool.
With similar construct there would be no necessity to change the generated code and would be very helpful for the devault usage of the Axis2 tools.
> wsdl2java generated exceptions do not display the received fault messages if created with constructor without parameters (f.e. if received and thrown in Stub)
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AXIS2-5050
> URL: https://issues.apache.org/jira/browse/AXIS2-5050
> Project: Axis2
> Issue Type: Improvement
> Components: wsdl
> Affects Versions: 1.4.1, 1.5.4
> Environment: all
> Reporter: Artur Linhart
> Labels: wsdl2java
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> If the exceptions generated from wsdl/xsd are used with the constructor without parameters, then they just contain as a exception message the name of the class and ignore the complete content of the exception, even if there is much more information available. This is especially problem in Stubs, where wsdl2java generates the received exception instantiation with exceptionClass.newInstance(); what leads to the fact in stub is effectively no exception message available. So, for example in the Unit-tests results normally the stacktrace of some exceltion ExceptionClassName with exception message is shown without any detail, You have always to go into the debugger and figure out what is the real fault behind the exception messsage "ExceptionClassName" is. This is very time consuming. Sure, one can take the exception generated by Axis and extend it, but then if the wsdl changes, it has to be regenerated, resynchronized, etc. etc.
> So, my proposal is to override in the generated exception the method getMessage() by something similar to:
>
> /**
> * @see java.lang.Throwable#getMessage()
> */
> @Override
> public String getMessage() {
> String locMessage = super.getMessage();
> if (getFaultMessage() != null && getFaultMessage().getXXXXFaultMessageContent() != null && (locMessage == null || this.getClass().this.getClass().getName().endsWith("." + locMessage))) {
> locMessage = getFaultMessage().getXXXXFaultMessageContent().getFaultMessage()
> }
> return locMessage;
> }
> where getXXXXFaultMessageContent is the name of the access method to fault content, generated according to the name convention already used in the wsdl2java tool.
> With similar construct there would be no necessity to change the generated code and would be very helpful for the default usage of the Axis2 tools.
--
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