axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <d...@yahoo.com>
Subject RE: Soap Fault Explanation
Date Mon, 08 Sep 2003 09:53:48 GMT
scroll down to bottom of on http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19682 page

-- dims

--- Gary L Peskin <garyp@firstech.com> wrote:
> 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.
> > > > > > > 
> 
=== message truncated ===


=====
Davanum Srinivas - http://webservices.apache.org/~dims/

Mime
View raw message