axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary L Peskin" <ga...@firstech.com>
Subject RE: Soap Fault Explanation
Date Mon, 08 Sep 2003 09:08:57 GMT
I think baby steps is a good approach.  However, once the exception no
longer extends AxisFault, we'll need to make sure that it's wrapped in an
AxisFault.  This should not be a problem using AxisFault.makeException().
However, it does mean that the caller will now see an AxisFault wrapper
rather than the original exception.  Under the current situation, the caller
sees the actual exception because it extends AxisFault.  Does this
explanation make sense?

Gary

> -----Original Message-----
> From: Davanum Srinivas [mailto:dims@yahoo.com] 
> Sent: Monday, September 08, 2003 2:01 AM
> To: axis-dev@ws.apache.org
> Subject: RE: Soap Fault Explanation 
> 
> 
> 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/
> 


Mime
View raw message