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 14:56:47 GMT
Dims --

I've looked briefly at this.  The NoSuchEmployeeFault still extends
RemoteException so the Call.invoke(...) signature allows the
NoSuchEmployeeFault to be directly thrown.  I'm trying to solve the general
case where the exception does -not- extend RemoteException or AxisFault.

The javadoc for RemoteException indicates that it is for
communication-related exceptions.  If you look at the JDK-provided
subclasses, they are all related to the RMI mechanism itself.  I don't think
it's appropriate for application exceptions like NoSuchEmployeeFault to have
to extend RemoteException.

I'll work my stuff up and open a bugzilla and post things.  It may take a
little time to get all of the pieces in a row but I'll keep at it.

Gary

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