Bugzilla – Bug 5991
Fault type cause has incorrect xsi:type
Last modified: 2008-05-21 15:59:52
You need to log in before you can comment on or make changes to this bug.
Fault type cause is set set to have xsi:type=BaseFaultType. This type is declared to xsd:any in the the specification. Interop tests show that some tools (GENESIS II) use the xsi:type and attempt to deserialize the content. Their validation fails, since schema has a different type.
Initial patches committed to bug_5922_branch_1. Most changes are in FaultHelper.java. Code is not complete and some pieces have to be cleaned up. Although current fault helper tests work, I suspect chained faults need more work.
Updated codebase to encode FaultCause>BaseFault with the specific type declared in the xsi:type for the BaseFault element. Passes all tests both embedded and external container.
updated schemas, FaultHelper and serializers
I've been getting NPEs in some calls to FaultHelper.printStackTrace(). One way to reproduce this is to modify wsrf-query, replacing: if (client.isDebugMode()) { FaultHelper.printStackTrace(e); with: if (client.isDebugMode()) { if (e instanceof BaseFaultType) { FaultHelper helper = new FaultHelper((BaseFaultType)e); helper.printStackTrace(System.out); and then run a command that will generate a server-side fault, such as: wsrf-query -debug -s <server_url> "//[" When I do this, I get this stack trace: Exception in thread "main" Error during startup processing. Caused by java.lang.NullPointerException at org.globus.wsrf.utils.FaultHelper.getStackTrace(FaultHelper.java:473) at org.globus.wsrf.utils.FaultHelper.getStackTrace(FaultHelper.java:477) at org.globus.wsrf.utils.FaultHelper.printStackTrace(FaultHelper.java:372) at org.globus.wsrf.client.Query.main(Query.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.globus.bootstrap.BootstrapBase.launch(BootstrapBase.java:114) at org.globus.bootstrap.Bootstrap.main(Bootstrap.java:41) However, running without the -debug (and thus skipping the stack trace code) shows that server sent a reasonable-looking fault: Error: org.oasis.wsrf.properties.QueryEvaluationErrorFaultType caused by [0: org.oasis.wsrf.faults.BaseFaultType: [Caused by: A location step was expected following the '/' or '//' token.]]
Fixed and committed