You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsif-user@ws.apache.org by "Brand, Olivier" <Ol...@vodafone.com> on 2003/04/02 18:58:00 UTC
Exception issue in WSIF
I think that this is an Axis bug then (or a feature...)
Obviously, Axis is not fully JAX-RPC compliant. A soap:fault must be translated to a java.rmi.RemoteException.
The same framework cannot be used then for SOAP (Axis) and EJB !! Breaking then the concept that WSIF brings to the table.
This exception problem is even more annoying on the client side:
A raised exception in the Bean class will be passed as a java.rmi.ServerException which is wrapped in a java.rmi.RemoteException which is wrapped in a WSIFException.
In order to decode an EJB exception, you have to go through all these levels.
In the java binding, you need to traverse only 2 levels: WSIFException which wraps the final exception
In the SOAP/Axis binding: you must traverse 3 levels: WSIFException --> AxisFault --> exception
WSIF is supposed to hide protocols and technology to the client but it is not true when dealing with exceptions !!!
What should be done in the WSIF stub is drilling down to the business exception and throw it back to the caller.
For instance the EJB stub knows that it needs to go 4 levels in order to extract the final exception.
I think that my prototype shows that WSIF is not mature enough in order to fully hide protocols integration, but I am sure that the amount of work to achieve this is minimal.
Is there a clear roadmap for solving this issue ?
Cheers
Olivier
-----Original Message-----
From: Owen D Burroughs [mailto:OWENB@uk.ibm.com]
Sent: Wednesday, April 02, 2003 4:23 PM
To: wsif-user@ws.apache.org
Subject: Re: Exception handling - part 1 -> java binding
Olivier,
If you are using stubs with WSIF, faults come out as WSIFExceptions,
regardless of what the SEI says. This code is quite old and obviously needs
to be looked at and updated. Thanks for highlighting it! Would you mind
raising a bugzilla to record the problem?
With regards to the problem you are having with the EJB provider and
exceptions, the stack trace shows that org.apache.crimson.tree.ElementNode2
is not Serializable. It's not clear exactly where the
org.apache.crimson.tree.ElementNode2 class is being used, but since the
WSDL2Java tool generates exception classes that extend AxisFault, and
AxisFault objects contain vectors of org.w3c.dom.Element objects, this
seems like the probable cause. org.w3c.dom.Element is not marked as
Serializable even though many implementations of it are (e.g. Xerces). It
would appear that the Crimson implementation is not Serializable.
Regards,
Owen
|---------+---------------------------->
| | "Brand, Olivier" |
| | <Olivier.Brand@vo|
| | dafone.com> |
| | |
| | 02/04/2003 09:39 |
| | Please respond to|
| | wsif-user |
| | |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: <ws...@ws.apache.org> |
| cc: |
| Subject: Exception handling - part 1 -> java binding |
| |
| |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
How does exception handling work in WSIF ? Are all exception wrapped in a
WSIFException ???
I have generated the java object model using WSDL2java from Axis, some
exceptions extending the AxisFault (ChargingServiceException)
got generated and being used.
In one of my test case, I am throwing an exception but this exception is
being caught as a WSIFException on the client side.
Here is the trace on the client:
<system-err><![CDATA[org.apache.wsif.WSIFException: Operation failed!;
nested exception is:
AxisFault
faultCode: {http://xml.apache.org/axis/}Server.generalException
faultString:
faultActor: null
faultDetail:
exceptionName:
com.vodafone.global.charging.ChargingServiceException
stackTrace: AxisFault
faultCode: {http://xml.apache.org/axis/}Server.generalException
faultString:
faultActor: null
faultDetail:
exceptionName:
com.vodafone.global.charging.ChargingServiceException
at
com.vodafone.global.charging.SOAPChargingServiceImpl.getClearance(SOAPChargingServiceImpl.java:47)
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.wsif.providers.java.WSIFOperation_Java.executeRequestResponseOperation(Unknown
Source)
at org.apache.wsif.base.WSIFClientProxy.invoke(Unknown Source)
at $Proxy0.getClearance(Unknown Source)
at
com.vodafone.global.charging.client.ChargingGenericStubTest.testException(ChargingGenericStubTest.java:149)
at java.lang.reflect.Method.invoke(Native Method)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at
junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:524)
at
com.vodafone.global.charging.SOAPChargingServiceImpl.getClearance(SOAPChargingServiceImpl.java:47)
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.wsif.providers.java.WSIFOperation_Java.executeRequestResponseOperation(Unknown
Source)
at org.apache.wsif.base.WSIFClientProxy.invoke(Unknown Source)
at $Proxy0.getClearance(Unknown Source)
at
com.vodafone.global.charging.client.ChargingGenericStubTest.testException(ChargingGenericStubTest.java:149)
at java.lang.reflect.Method.invoke(Native Method)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at
junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:524)
]]></system-err>
Olivier Brand
Senior Java Architect - Mobile Services and Integration
Global IT & Technology Management
Vodafone AG
Mannesmannufer 3 - 40213 Dusseldorf - Germany
Mobile: +49 172 2094646
E-Mail: olivier.brand@vodafone.com