Bug 5991 - Fault type cause has incorrect xsi:type
: Fault type cause has incorrect xsi:type
Status: RESOLVED FIXED
: Java WS Core
globus_wsrf_core
: unspecified
: PC Windows XP
: P1 blocker
: 4.2.0
Assigned To:
:
:
:
: 5922
  Show dependency treegraph
 
Reported: 2008-04-08 09:25 by
Modified: 2008-05-21 15:59 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-04-08 09:25:21
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.
------- Comment #1 From 2008-04-08 09:59:38 -------
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.
------- Comment #2 From 2008-05-07 16:13:55 -------
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.
------- Comment #3 From 2008-05-07 17:33:19 -------
updated schemas, FaultHelper and serializers
------- Comment #4 From 2008-05-21 15:38:09 -------
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.]]
------- Comment #5 From 2008-05-21 15:59:52 -------
Fixed and committed