Beehive
  1. Beehive
  2. BEEHIVE-717

minor non-conformance of exceptions to JSR-181 / JAX-RPC 1.1

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: V1Beta
    • Fix Version/s: 1.0
    • Component/s: Web Services (181)
    • Labels:
      None
    • Environment:
      Beehive SVN 169852

      Description

      While testing BEEHIVE-133, we ran into an issue with user-defined Exceptions. The example provided in the JAX-RPC v1.1 spec shows the problem, so I will attach that as the repro. The WSDL looks accurate according to the JAX-RPC spec (which is referenced by JSR 181), but the response message looks incorrect.

      I will attach the WSDL; the incorrect looking response is below:

      <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <soapenv:Body>
      <soapenv:Fault>
      <faultcode>soapenv:Server.userException</faultcode>
      <faultstring>web.InvalidTickerException</faultstring>
      <detail>
      <ns1:hostname xmlns:ns1="http://xml.apache.org/axis/">localhost.localdomain</ns1:hostname>
      </detail>

      </soapenv:Fault>
      </soapenv:Body>
      </soapenv:Envelope>

      1. faultpatch.txt
        18 kB
        daryoush mehrtash
      2. faultpatch.txt
        22 kB
        daryoush mehrtash
      3. BEEHIVE-717.tar
        70 kB
        Jeremiah Johnson
      4. BEEHIVE-133.wsdl
        3 kB
        Jeremiah Johnson
      5. BEEHIVE-133.tar.gz
        4 kB
        Jeremiah Johnson

        Activity

        Hide
        Jeremiah Johnson added a comment -

        This is a Beehive WSM application that will reproduce this bug.

        Uncompress and untar and then use standard wsm procedures to build and deploy. Actually - this expects CATALINA_HOME and BEEHIVE_HOME, so you'll need to have those defined to use 'ant clean build deploy'. Deploy puts the war in $CATALINA_HOME/webapps.

        Show
        Jeremiah Johnson added a comment - This is a Beehive WSM application that will reproduce this bug. Uncompress and untar and then use standard wsm procedures to build and deploy. Actually - this expects CATALINA_HOME and BEEHIVE_HOME, so you'll need to have those defined to use 'ant clean build deploy'. Deploy puts the war in $CATALINA_HOME/webapps.
        Hide
        Jeremiah Johnson added a comment -

        Here is the current WSDL that I think looks correct.

        Show
        Jeremiah Johnson added a comment - Here is the current WSDL that I think looks correct.
        Hide
        Jeremiah Johnson added a comment -

        attempting to get assigned to correct Daryoush user

        Show
        Jeremiah Johnson added a comment - attempting to get assigned to correct Daryoush user
        Hide
        daryoush mehrtash added a comment -

        Faults are not being correctly processed, I need to examine this further.

        Show
        daryoush mehrtash added a comment - Faults are not being correctly processed, I need to examine this further.
        Hide
        Jeremiah Johnson added a comment -

        I realized that I attached the bad looking SOAP response, but not what I expected to see. Here is the SOAP response that I was expecting:

        <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <soapenv:Body>
        <soapenv:Fault>
        <faultcode>soapenv:Server.userException</faultcode>
        <faultstring>server.InvalidTickerException</faultstring>
        <detail>
        <ns1:InvalidTickerException xmlns:ns1="http://web">
        <tickerSymbol>MSFT</tickerSymbol>
        </ns1:InvalidTickerException>
        </detail>
        </soapenv:Fault>
        </soapenv:Body>
        </soapenv:Envelope>

        The contents of the Fault/detail that are currently a problem. Whether the hostname is included in the Fault/detail or not, I don't care.

        Show
        Jeremiah Johnson added a comment - I realized that I attached the bad looking SOAP response, but not what I expected to see. Here is the SOAP response that I was expecting: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <soapenv:Fault> <faultcode>soapenv:Server.userException</faultcode> <faultstring>server.InvalidTickerException</faultstring> <detail> <ns1:InvalidTickerException xmlns:ns1="http://web"> <tickerSymbol>MSFT</tickerSymbol> </ns1:InvalidTickerException> </detail> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope> The contents of the Fault/detail that are currently a problem. Whether the hostname is included in the Fault/detail or not, I don't care.
        Hide
        daryoush mehrtash added a comment -

        There are two problems with Faults.

        If the JWS is called from the URL, Axis would not serialize the fault properly and you get a bogus message. I have send a patch for axis to fix this problem.

        The other issue is when you send a soap request (e.g. via application) to the JWS, JWS was not sending the correct infomration in the detail. I fixed the JWS based on this exchange. http://marc.theaimsgroup.com/?t=111775697800004&r=1&w=2

        The fixes are attached shortly.

        Show
        daryoush mehrtash added a comment - There are two problems with Faults. If the JWS is called from the URL, Axis would not serialize the fault properly and you get a bogus message. I have send a patch for axis to fix this problem. The other issue is when you send a soap request (e.g. via application) to the JWS, JWS was not sending the correct infomration in the detail. I fixed the JWS based on this exchange. http://marc.theaimsgroup.com/?t=111775697800004&r=1&w=2 The fixes are attached shortly.
        Hide
        daryoush mehrtash added a comment -

        This patch contains the fix for the Fault serialization and also the unit test for the fault messages.

        Show
        daryoush mehrtash added a comment - This patch contains the fix for the Fault serialization and also the unit test for the fault messages.
        Hide
        Eddie O'Neil added a comment -

        Daryoush – Hey; thanks for the patch! A couple of comments:

        • the AxisFaultAdaptor seems to be missing the ASF copyright / license header. Could you add it?
        • just curious, but why do we need to override the RPCProvider.invoke(MessageContext) method? This just wraps the super call with error handling; does that imply that we're throwing the wrong type of exceptions out of ControlProvider.makeNewServiceObject(...) and that we should be throwing AxisFault? Guess I'm asking if the ControlProvider needs to be rewritten to throw an AxisFault since we're just using AxisFaultAdapter to handle errors from the ControlProvider.
        • in the ControlProvider.invoke(...) method, why is the original AxisFault not thrown? The original exception is often useful when diagnosing errors (though I'm likely just missing some subtelty of the AxisFault infrastructure).
        • even if an AxisFaultAdapter is serialized, wouldn't the AxisFaultAdapter.writeDetails(...) method still throw an NPE because the MessageContext is null at this line:

        fd = msgContext.getOperation().getFaultByClass(origExp.getClass());

        • could the two class-level fields in AxisFaultAdapter be private?

        Also, feel free to use JDK 1.4 asserts liberally – this tends to document the developer's expectations of the code at runtime. For example, from AxisFaultAdapter.writeDetails(...) this:

        fd = msgContext.getOperation().getFaultByClass(origExp.getClass());
        ArrayList parameters = fd.getParameters();

        could become this:

        fd = msgContext.getOperation().getFaultByClass(origExp.getClass());
        assert fd != null : "Encountered null FaultDesc";
        ArrayList parameters = fd.getParameters();

        Show
        Eddie O'Neil added a comment - Daryoush – Hey; thanks for the patch! A couple of comments: the AxisFaultAdaptor seems to be missing the ASF copyright / license header. Could you add it? just curious, but why do we need to override the RPCProvider.invoke(MessageContext) method? This just wraps the super call with error handling; does that imply that we're throwing the wrong type of exceptions out of ControlProvider.makeNewServiceObject(...) and that we should be throwing AxisFault? Guess I'm asking if the ControlProvider needs to be rewritten to throw an AxisFault since we're just using AxisFaultAdapter to handle errors from the ControlProvider. in the ControlProvider.invoke(...) method, why is the original AxisFault not thrown? The original exception is often useful when diagnosing errors (though I'm likely just missing some subtelty of the AxisFault infrastructure). even if an AxisFaultAdapter is serialized, wouldn't the AxisFaultAdapter.writeDetails(...) method still throw an NPE because the MessageContext is null at this line: fd = msgContext.getOperation().getFaultByClass(origExp.getClass()); could the two class-level fields in AxisFaultAdapter be private? Also, feel free to use JDK 1.4 asserts liberally – this tends to document the developer's expectations of the code at runtime. For example, from AxisFaultAdapter.writeDetails(...) this: fd = msgContext.getOperation().getFaultByClass(origExp.getClass()); ArrayList parameters = fd.getParameters(); could become this: fd = msgContext.getOperation().getFaultByClass(origExp.getClass()); assert fd != null : "Encountered null FaultDesc"; ArrayList parameters = fd.getParameters();
        Hide
        daryoush mehrtash added a comment -

        >
        > Daryoush – Hey; thanks for the patch! A couple of comments:
        >
        > - the AxisFaultAdaptor seems to be missing the ASF copyright / license
        > header. Could you add it?
        >

        Yes.

        > - just curious, but why do we need to override the
        > RPCProvider.invoke(MessageContext) method? This just wraps the super call
        > with error handling; does that imply that we're throwing the wrong type of
        > exceptions out of ControlProvider.makeNewServiceObject(...) and that we
        > should be throwing AxisFault? Guess I'm asking if the ControlProvider
        > needs to be rewritten to throw an AxisFault since we're just using
        > AxisFaultAdapter to handle errors from the ControlProvider.
        >

        I am not sure I understand this comment. I don't think you have a correct view of this class. Your confusion might be because the ControlProvider is not a good name for this class. It should be renamed to something like BeehiveProvier, or WSMProvider. Its goal is to do the runtime pre- and post processing for JWS method calls, essentially to gap the Beehive JWS with Axis model when methods are being called on the JWS.

        If this is not clearing up the confusion you might want to be more specific with some code example on this, may be I am missing what you are saying.

        > - in the ControlProvider.invoke(...) method, why is the original AxisFault
        > not thrown? The original exception is often useful when diagnosing errors
        > (though I'm likely just missing some subtelty of the AxisFault
        > infrastructure).
        >

        The provider needs to do additional work if the source of the fault is a user exception as oppose to a full fledged Axis fault. The RPCProvider converts all Application faults to an AxisFault (derived from RemoteException). If the original fault was an AxisFault RPCPRovider would let it pass through, if the original fault was an Application Exception it creates an AxisFault with the original exception as detail. Axis wont serialize the fault properly but the Adaptor is designed to "do the right" thing in serializing the fault. So it is the "correct" wrapping if you will.

        A real AxisFault is not serialized properly there is a bug on this with Axis: http://issues.apache.org/jira/browse/AXIS-2039 but this wont affect the Adaptor as it controls the serialization.

        With this patch we should be able to deal with Application faults now and once Axis fixes in AxisFault serialization we can work with it also.

        > - even if an AxisFaultAdapter is serialized, wouldn't the
        > AxisFaultAdapter.writeDetails(...) method still throw an NPE because the
        > MessageContext is null at this line:
        >
        > fd = msgContext.getOperation().getFaultByClass(origExp.getClass());

        >
        > - could the two class-level fields in AxisFaultAdapter be private?
        >

        Yes.

        > Also, feel free to use JDK 1.4 asserts liberally – this tends to document
        > the developer's expectations of the code at runtime. For example, from
        > AxisFaultAdapter.writeDetails(...) this:
        >
        > fd = msgContext.getOperation().getFaultByClass(origExp.getClass());
        > ArrayList parameters = fd.getParameters();
        >
        > could become this:
        >
        > fd = msgContext.getOperation().getFaultByClass(origExp.getClass());
        > assert fd != null : "Encountered null FaultDesc";
        > ArrayList parameters = fd.getParameters();

        It should not be possible to have a null, since all of the declared fault must have been configured for the JWS in the first place. Anomalies should have been detected and asserted at build and deployment time. You do have a good point in that we do need to have a test case to make sure we deal properly with non-declared one (runtime), I will add the test case for that in the patch.

        Show
        daryoush mehrtash added a comment - > > Daryoush – Hey; thanks for the patch! A couple of comments: > > - the AxisFaultAdaptor seems to be missing the ASF copyright / license > header. Could you add it? > Yes. > - just curious, but why do we need to override the > RPCProvider.invoke(MessageContext) method? This just wraps the super call > with error handling; does that imply that we're throwing the wrong type of > exceptions out of ControlProvider.makeNewServiceObject(...) and that we > should be throwing AxisFault? Guess I'm asking if the ControlProvider > needs to be rewritten to throw an AxisFault since we're just using > AxisFaultAdapter to handle errors from the ControlProvider. > I am not sure I understand this comment. I don't think you have a correct view of this class. Your confusion might be because the ControlProvider is not a good name for this class. It should be renamed to something like BeehiveProvier, or WSMProvider. Its goal is to do the runtime pre- and post processing for JWS method calls, essentially to gap the Beehive JWS with Axis model when methods are being called on the JWS. If this is not clearing up the confusion you might want to be more specific with some code example on this, may be I am missing what you are saying. > - in the ControlProvider.invoke(...) method, why is the original AxisFault > not thrown? The original exception is often useful when diagnosing errors > (though I'm likely just missing some subtelty of the AxisFault > infrastructure). > The provider needs to do additional work if the source of the fault is a user exception as oppose to a full fledged Axis fault. The RPCProvider converts all Application faults to an AxisFault (derived from RemoteException). If the original fault was an AxisFault RPCPRovider would let it pass through, if the original fault was an Application Exception it creates an AxisFault with the original exception as detail. Axis wont serialize the fault properly but the Adaptor is designed to "do the right" thing in serializing the fault. So it is the "correct" wrapping if you will. A real AxisFault is not serialized properly there is a bug on this with Axis: http://issues.apache.org/jira/browse/AXIS-2039 but this wont affect the Adaptor as it controls the serialization. With this patch we should be able to deal with Application faults now and once Axis fixes in AxisFault serialization we can work with it also. > - even if an AxisFaultAdapter is serialized, wouldn't the > AxisFaultAdapter.writeDetails(...) method still throw an NPE because the > MessageContext is null at this line: > > fd = msgContext.getOperation().getFaultByClass(origExp.getClass()); > > - could the two class-level fields in AxisFaultAdapter be private? > Yes. > Also, feel free to use JDK 1.4 asserts liberally – this tends to document > the developer's expectations of the code at runtime. For example, from > AxisFaultAdapter.writeDetails(...) this: > > fd = msgContext.getOperation().getFaultByClass(origExp.getClass()); > ArrayList parameters = fd.getParameters(); > > could become this: > > fd = msgContext.getOperation().getFaultByClass(origExp.getClass()); > assert fd != null : "Encountered null FaultDesc"; > ArrayList parameters = fd.getParameters(); It should not be possible to have a null, since all of the declared fault must have been configured for the JWS in the first place. Anomalies should have been detected and asserted at build and deployment time. You do have a good point in that we do need to have a test case to make sure we deal properly with non-declared one (runtime), I will add the test case for that in the patch.
        Hide
        Eddie O'Neil added a comment -

        Daryoush--

        Gotcha – one question I have is about whether the ControlProvider would ever throw an AxisFault and if it did why we would ever need to catch it. The bridge between WSM and Axis seems to be tied up in AxisHook.createServiceDesc(...), so it seemed weird to catch AxisFault in ControlProvider when that's just used to initialize @Control references.

        If the goal is to catch application exceptions, can we just re-throw all AxisFault(s) and wrap the rest? Might simplify the catch logic.

        The other changes sound great. I'll watch for a new patch.

        Show
        Eddie O'Neil added a comment - Daryoush-- Gotcha – one question I have is about whether the ControlProvider would ever throw an AxisFault and if it did why we would ever need to catch it. The bridge between WSM and Axis seems to be tied up in AxisHook.createServiceDesc(...), so it seemed weird to catch AxisFault in ControlProvider when that's just used to initialize @Control references. If the goal is to catch application exceptions, can we just re-throw all AxisFault(s) and wrap the rest? Might simplify the catch logic. The other changes sound great. I'll watch for a new patch.
        Hide
        daryoush mehrtash added a comment -

        As I said the name ControlProvider is not a good name for this class. Setting up the @Control is one of the things it does, which happens when the JWS gets initialized. BeehiveProvider is a better name for this class. This maps between beehive programming model and the Axis model at run time.

        Invoke is when the methods are called on JWS and that is where AxisFaults happen. RPCProvider wrapps *every * exception into a RemoteException (AxisFault). The catch code in the ControlProvider examines the original exception to see if it needs to repleace the default AxisFault wrapper with the Adaptor which looks like AxisFault but knows how to serailize the Application Specific faults..

        This is the comment I had on the code:

        // Before we get to here, Axis has converted all exceptions to the
        // AxisFaults.
        // A standard AxisFault wont serialize the exception correctly.
        // AxisFaultAdaptor is used to intercept the serialization process
        // and
        // "do the right thing"

        Doesn't that explain the catch logic?

        There was one flaw in the catch, that it should have used the AxisFault mechansiem for RuntimeExceptions (as oppose to the Adaptor) I am going to add this to the next patch.

        Show
        daryoush mehrtash added a comment - As I said the name ControlProvider is not a good name for this class. Setting up the @Control is one of the things it does, which happens when the JWS gets initialized. BeehiveProvider is a better name for this class. This maps between beehive programming model and the Axis model at run time. Invoke is when the methods are called on JWS and that is where AxisFaults happen. RPCProvider wrapps *every * exception into a RemoteException (AxisFault). The catch code in the ControlProvider examines the original exception to see if it needs to repleace the default AxisFault wrapper with the Adaptor which looks like AxisFault but knows how to serailize the Application Specific faults.. This is the comment I had on the code: // Before we get to here, Axis has converted all exceptions to the // AxisFaults. // A standard AxisFault wont serialize the exception correctly. // AxisFaultAdaptor is used to intercept the serialization process // and // "do the right thing" Doesn't that explain the catch logic? There was one flaw in the catch, that it should have used the AxisFault mechansiem for RuntimeExceptions (as oppose to the Adaptor) I am going to add this to the next patch.
        Hide
        daryoush mehrtash added a comment -

        updated patch for the fixed to this bug.

        Show
        daryoush mehrtash added a comment - updated patch for the fixed to this bug.
        Hide
        daryoush mehrtash added a comment -

        Thanks eddie for the commit and the Asserts you added improved the code, well except this one (line 82 on Control Provider)

        assert !(origExp instanceof AxisFault) : "Unexpected: found AxisFault as detail of AxisFault";

        To have AxisFault in the detail is unexpected, we don't expect one to wrap AxisFault inside another. But if they do, well that means they can deal with the serailzation also, which means we don't need our Adaptor. I think the original code:

        if (origExp instanceof AxisFault)
        throw e; // Should not happen, just being paranoid.
        // AxisFaults are not wrapped in another, but just in case!

        Is a better representation of the reality than an Assert.

        Show
        daryoush mehrtash added a comment - Thanks eddie for the commit and the Asserts you added improved the code, well except this one (line 82 on Control Provider) assert !(origExp instanceof AxisFault) : "Unexpected: found AxisFault as detail of AxisFault"; To have AxisFault in the detail is unexpected, we don't expect one to wrap AxisFault inside another. But if they do, well that means they can deal with the serailzation also, which means we don't need our Adaptor. I think the original code: if (origExp instanceof AxisFault) throw e; // Should not happen, just being paranoid. // AxisFaults are not wrapped in another, but just in case! Is a better representation of the reality than an Assert.
        Hide
        Eddie O'Neil added a comment -

        Daryoush--

        Hey, so the reason I changed that is because of the comment "Should not happen, just being paranoid".

        In general, if something shouldn't happen, we should add code to deal with those cases.

        If we believe that it is possible / reasonable to have AxisFaults inside of AxisFaults, then this isn't a paranoid check – it's the right check. If that's the case, then I completely agree with you and I'll add the code back and remove the comment.

        If not, it seems we should avoid the defensive code.

        Thoughts?

        Show
        Eddie O'Neil added a comment - Daryoush-- Hey, so the reason I changed that is because of the comment "Should not happen, just being paranoid". In general, if something shouldn't happen, we should add code to deal with those cases. If we believe that it is possible / reasonable to have AxisFaults inside of AxisFaults, then this isn't a paranoid check – it's the right check. If that's the case, then I completely agree with you and I'll add the code back and remove the comment. If not, it seems we should avoid the defensive code. Thoughts?
        Hide
        daryoush mehrtash added a comment -

        In this case I think we should not do assert. You do have a good point on Asserts in general.

        Show
        daryoush mehrtash added a comment - In this case I think we should not do assert. You do have a good point on Asserts in general.
        Hide
        Eddie O'Neil added a comment -

        Okay, so, we'll remove the check (assert and conditional) entirely then? Or is this an expected case that needs to be explicitly handled with the conditional?

        Show
        Eddie O'Neil added a comment - Okay, so, we'll remove the check (assert and conditional) entirely then? Or is this an expected case that needs to be explicitly handled with the conditional?
        Hide
        daryoush mehrtash added a comment -

        my suggestion is to remove the assert leave the code in.

        Show
        daryoush mehrtash added a comment - my suggestion is to remove the assert leave the code in.
        Hide
        Eddie O'Neil added a comment -

        I've fixed the catch(...) to remove the assert and the "paranoid" comment as this is a common use-case.

        Resolving as fixed...

        Show
        Eddie O'Neil added a comment - I've fixed the catch(...) to remove the assert and the "paranoid" comment as this is a common use-case. Resolving as fixed...
        Hide
        Jeremiah Johnson added a comment -

        I'll test and close this one.

        Show
        Jeremiah Johnson added a comment - I'll test and close this one.
        Hide
        Jeremiah Johnson added a comment -

        BEEHIVE-717.tar is a new repro for this bug since the only valid success path if via a real client. The tarball contains two Web apps: one for the WS and one for the client Web app.

        cd BEEHIVE-717
        ant -f ws/WEB-INF/src/build.xml clean build deploy
        ant -f webapp/WEB-INF/src/build.xml clean build deploy

        http://localhost:8080/BEEHIVE-717/

        Then click on the last link. If all is well, then the page doesn't look like anything happened You can look in the log to verify that the SOAP Fault looks as expected. Here is the SOAP Fault that I got (and the detail gives what I had expected when filing this bug):
        <?xml version="1.0" encoding="UTF-8"?>
        <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <soapenv:Body>
        <soapenv:Fault>
        <faultcode>soapenv:Server.generalException</faultcode>
        <faultstring/>
        <detail>
        <ns1:InvalidTickerExceptionFault xmlns:ns1="http://web">
        <ns1:tickerSymbol>MSFT</ns1:tickerSymbol>
        </ns1:InvalidTickerExceptionFault>
        <ns2:stackTrace xmlns:ns2="http://xml.apache.org/axis/">at org.apache.beehive.wsm.axis.ControlProvider.invoke(ControlProvider.java:81)
        at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
        at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
        at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
        at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:453)
        at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)
        at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:699)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
        at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
        at org.apache.beehive.controls.runtime.servlet.ControlFilter.doFilter(ControlFilter.java:131)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
        at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
        at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
        at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
        at java.lang.Thread.run(Thread.java:595)</ns2:stackTrace>
        <ns3:hostname xmlns:ns3="http://xml.apache.org/axis/">localhost.localdomain</ns3:hostname>
        <ns4:exceptionName xmlns:ns4="http://xml.apache.org/axis/">web.InvalidTickerException</ns4:exceptionName>
        </detail>
        </soapenv:Fault>
        </soapenv:Body>
        </soapenv:Envelope>

        Show
        Jeremiah Johnson added a comment - BEEHIVE-717 .tar is a new repro for this bug since the only valid success path if via a real client. The tarball contains two Web apps: one for the WS and one for the client Web app. cd BEEHIVE-717 ant -f ws/WEB-INF/src/build.xml clean build deploy ant -f webapp/WEB-INF/src/build.xml clean build deploy http://localhost:8080/BEEHIVE-717/ Then click on the last link. If all is well, then the page doesn't look like anything happened You can look in the log to verify that the SOAP Fault looks as expected. Here is the SOAP Fault that I got (and the detail gives what I had expected when filing this bug): <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <soapenv:Fault> <faultcode>soapenv:Server.generalException</faultcode> <faultstring/> <detail> <ns1:InvalidTickerExceptionFault xmlns:ns1="http://web"> <ns1:tickerSymbol>MSFT</ns1:tickerSymbol> </ns1:InvalidTickerExceptionFault> <ns2:stackTrace xmlns:ns2="http://xml.apache.org/axis/">at org.apache.beehive.wsm.axis.ControlProvider.invoke(ControlProvider.java:81) at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32) at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:453) at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281) at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:699) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.beehive.controls.runtime.servlet.ControlFilter.doFilter(ControlFilter.java:131) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:595)</ns2:stackTrace> <ns3:hostname xmlns:ns3="http://xml.apache.org/axis/">localhost.localdomain</ns3:hostname> <ns4:exceptionName xmlns:ns4="http://xml.apache.org/axis/">web.InvalidTickerException</ns4:exceptionName> </detail> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope>
        Hide
        Jeremiah Johnson added a comment -

        Verified in dist built from SVN 191559.

        The detail element, when called from an application client, now looks as expected.

        Show
        Jeremiah Johnson added a comment - Verified in dist built from SVN 191559. The detail element, when called from an application client, now looks as expected.

          People

          • Assignee:
            Jeremiah Johnson
            Reporter:
            Jeremiah Johnson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development