Let's take baby steps. Let's assume that we are dealing with Bean-like exceptions that don't
need
AxisFault and get that working first with changes to just org.apache.axis.wsdl.*. Is this
ok?
-- dims
--- Gary L Peskin <garyp@firstech.com> wrote:
> It won't solve my entire problem. But it's a definite start. We still need
> an ExceptionDeserializer. And we need Axis to understand when an AxisFault
> is just a wrapper for an ordinary exception and when it's actually an
> AxisFault. Currently, I see if getCause() is null but I'm not sure that
> this is good enough for actual work.
>
> In addition, we need to fix the generated stubs to catch an AxisFault and
> throw the real exception if AxisFault is just acting as a wrapper. Probably
> need to fix this for AxisClientProxy as well to handle the case where
> someone is using Dynamic Proxy as well. Due to the signatures on the
> Call.invoke(...) classes, the DII Call Interface cannot support this
> feature. I think this is a shortcoming of the definition of the
> Call.invoke(...) methods in JAX-RPC but that is what we have to live with.
> Hopefully, this will be fixed on the next go around with JAX-RPC and the
> signatures will be changed to "throws Throwable". But that is for another
> day.
>
> Gary
>
> > -----Original Message-----
> > From: Davanum Srinivas [mailto:dims@yahoo.com]
> > Sent: Monday, September 08, 2003 1:36 AM
> > To: axis-dev@ws.apache.org
> > Subject: RE: Soap Fault Explanation (long)
> >
> >
> > +1 to "have wsdl2java generate exception classes that do not extend
> > +AxisFault" - BUT will that
> > solve ur problem?
> >
> > -- dims
> >
> > --- Gary L Peskin <garyp@firstech.com> wrote:
> > > Hi, Dims --
> > >
> > > I do have time to work up some patches. However, I'm unclear as to
> > > what part of wsdl2java you're referring. Are you referring to the
> > > generation of the Exception classes or the Stubs? I
> > already have my
> > > exception classes so, as I said, I just throw this part of the
> > > generated code away. However, I'm happy to tackle the
> > issue and have
> > > wsdl2java generate exception classes that do not extend AxisFault.
> > >
> > > Is this what you mean?
> > >
> > > Thanks,
> > > Gary
> > >
> > > > -----Original Message-----
> > > > From: Davanum Srinivas [mailto:dims@yahoo.com]
> > > > Sent: Friday, September 05, 2003 11:15 PM
> > > > To: axis-user@ws.apache.org
> > > > Cc: axis-dev@ws.apache.org
> > > > Subject: RE: Soap Fault Explanation (long)
> > > >
> > > >
> > > > Great thread for the axis-dev@ mailing list. Please post this
> > > > there. Please note that Axis passes the JAX-RPC TCK, so we
> > > > are JAX-RPC compliant.
> > > >
> > > > First step is to revamp wsdl2java to generate code that does
> > > > not depend on AxisFault when it finds a wsdl:fault. Do you
> > > > have patches that can do this? The catch would be to run "ant
> > > > clean all-tests" and make sure that none of the existing test
> > > > harness breaks. Do you have a few cycles to do this? Any help
> > > > is much appreciated.
> > > >
> > > > Thanks,
> > > > dims
> > > >
> > > > --- Gary L Peskin <garyp@firstech.com> wrote:
> > > > > I am developing a product that can run in two modes. It can run
> > > > > on-platform, where classes A and B are on the same
> > > > platform, in which
> > > > > case Axis is uninvolved. An object of class A calls an
> > object of
> > > > > class B and that's all there is to it. However, it can
> > also run
> > > > > off-platform where class B sits on an Axis server and class
> > > > A sits on
> > > > > a client. In this case, class A invokes a method on class
> > > > B via Axis
> > > > > using an RPC service.
> > > > >
> > > > > Class A uses a small loader that I wrote. If it is running
> > > > > on-platform, it loads the service class directly. When
> > running off
> > > > > platform, it loads the stub generated by wsdl2java.
> > > > >
> > > > > Class B throws a service specific exception (MyException)
> > > > that is not
> > > > > a RuntimeException and not a RemoteException. It doesn't extend
> > > > > AxisFault since Axis is not present when running
> > > > on-platform. I don't
> > > > > want Axis to be required when running on-platform.
> > > > >
> > > > > MyException is pretty much a regular old java exception. It is
> > > > > immutable so all of the parameters needed are contained in the
> > > > > constructors for the exception. As I read JAX-RPC
> > section 4.3.6,
> > > > > MyException conforms to the requirements set forth there.
> > > > >
> > > > > The problem is that, when I use wsdl2java, Axis wants to
> > > > deserialize
> > > > > this exception with a BeanDeserializer and MyException is not an
> > > > > Axis-compatible bean. It doesn't have a no-argument
> > > > constructor. And
> > > > > it doesn't have any setXXX methods. As I said, MyException
> > > > is used in
> > > > > regular java processing and I want it to look like a
> > regular java
> > > > > exception. So BeanDeserializer won't work for me.
> > > > >
> > > > > Reading the JAX-RPC spec, section 4.3.6, it seems awfully
> > > > vague about
> > > > > how Service Specific Exceptions are supposed to be
> > constructed.
> > > > > It
> > > > > requires getXXX methods for each field as well as a
> > > > constructor that
> > > > > contains all of the fields. However, you can't find out from
> > > > > reflection what order the various parameters are supposed
> > > > to be fed to
> > > > > the constructor. So, you need some sort of metadata for
> > > > this for each
> > > > > constructor. Unfortunately, this is not currently
> > > > supported by Axis,
> > > > > to my knowledge. It creates a FieldDesc for each field but
> > > > > doesn't
> > > > > have create OperationDescs for the constructors.
> > > > >
> > > > > I have found that, by making certain assumptions and a few
> > > > > modifications, I can get Axis to generate MyException just
> > > > as I'd like
> > > > > it. It works for me but it is not entirely satisfactory for the
> > > > > general case. I realize that this is boring for most
> > > > people who never
> > > > > want to throw MyException and are content to subclass AxisFault
> > > > > and
> > > > > make their exception classes bean-like. However, if anyone
> > > > is really
> > > > > interested in bouncing ideas back and forth, I'd be happy
> > > > to work up
> > > > > the patches to Axis to implement a view of Service Specific
> > > > Exceptions
> > > > > more in keeping with the JAX-RPC ideas. What follows is what
> > > > > works
> > > > > for me and is a starting point for discussion, if
> > anyone but me is
> > > > > interested.
> > > > >
> > > > > To keep my exception classes as vanilla as possible, I
> > used the -H
> > > > > option of wsdl2java to generate Helper classes. This
> > means that
> > > > > wsdl2java generates a MyException_Helper class to contain
> > > > all of the
> > > > > metadata and leaves MyException itself alone. The metadata is
> > > > > important because it controls the order in which the
> > fields will be
> > > > > serialized when running in off-platform mode. wsdl2java also
> > > > > generates a new MyException class that extends
> > AxisFault and has a
> > > > > no-argument constructor and setXXX methods for each
> > field. I throw
> > > > > that generated class away. Then, I manually edit the
> > > > > getDeserializer() method in the _Helper class to return an
> > > > > ExceptionDeserializer which is a deserializer that I wrote.
> > > > > ExceptionDeserializer collects the various fields into a
> > > > List and then uses
> > > > > that List to find the appropriate constructor and invoke it in
> > > > > ExceptionDeserializer.onEndElement(...).
> > > > >
> > > > > This allows me to create MyException provided I follow
> > > > certain rules.
> > > > > The fields in the exception are serialized on the server
> > > > side in the
> > > > > order that the FieldDescs appear in the metadata. So,
> > I need to
> > > > > be
> > > > > sure that I have a constructor that takes the fields in the
> > > > same order
> > > > > as the metadata (ie the same order in which the fields were
> > > > > serialized). JAX-RPC is pretty weak in describing how
> > the JAX-RPC
> > > > > implementation is supposed to invoke the constructor.
> > I suppose I
> > > > > could add in OperationDescs for each constructor but that
> > > > seemed too
> > > > > much like work. And what if I had two constructors taking the
> > > > > same
> > > > > parameters in a different order. How would I choose
> > which one to
> > > > > invoke? It seems like someone needs to come up with
> > > > various use cases
> > > > > for throwing Service Specific Exceptions and follow
> > those out when
> > > > > revising the JAX-RPC spec.
> > > > >
> > > > > If I want to include the message in my constructor, I
>
=== message truncated ===
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
|