[ http://issues.apache.org/jira/browse/BEEHIVE-717?page=comments#action_12312937 ]
daryoush mehrtash commented on BEEHIVE-717: ------------------------------------------- > > 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. > minor non-conformance of exceptions to JSR-181 / JAX-RPC 1.1 > ------------------------------------------------------------ > > Key: BEEHIVE-717 > URL: http://issues.apache.org/jira/browse/BEEHIVE-717 > Project: Beehive > Type: Bug > Components: Web Services (181) > Versions: V1Beta > Environment: Beehive SVN 169852 > Reporter: Jeremiah Johnson > Assignee: daryoush mehrtash > Priority: Minor > Fix For: TBD > Attachments: BEEHIVE-133.tar.gz, BEEHIVE-133.wsdl, faultpatch.txt > > 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> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
