Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
From: "Gary L Peskin" <garyp@firstech.com>
To: <axis-dev@ws.apache.org>
Subject: RE: Soap Fault Explanation 
Date: Mon, 8 Sep 2003 07:56:47 -0700
Message-ID: <077001c37619$6d2d2140$0200a8c0@Gary005>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Importance: Normal
In-Reply-To: <20030908095348.58647.qmail@web12807.mail.yahoo.com>

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]=20
> Sent: Monday, September 08, 2003 2:54 AM
> To: Gary L Peskin; axis-dev@ws.apache.org
> Subject: RE: Soap Fault Explanation=20
>=20
>=20
> scroll down to bottom of on=20
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3D19682 page
>=20
> -- dims
>=20
> --- Gary L Peskin <garyp@firstech.com> wrote:
> > I think baby steps is a good approach.  However, once the=20
> exception no=20
> > longer extends AxisFault, we'll need to make sure that it's=20
> wrapped in=20
> > an AxisFault.  This should not be a problem using=20
> > AxisFault.makeException(). However, it does mean that the=20
> caller will=20
> > now see an AxisFault wrapper rather than the original exception. =20
> > Under the current situation, the caller sees the actual exception=20
> > because it extends AxisFault.  Does this explanation make sense?
> >=20
> > Gary
> >=20
> > > -----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=20
> > >=20
> > >=20
> > > Let's take baby steps. Let's assume that we are dealing with
> > > Bean-like exceptions that don't need AxisFault and get that=20
> > > working first with changes to just=20
> org.apache.axis.wsdl.*. Is this ok?
> > >=20
> > > -- dims
> > >=20
> > > --- Gary L Peskin <garyp@firstech.com> wrote:
> > > > It won't solve my entire problem.  But it's a definite=20
> start.  We
> > > > still need an ExceptionDeserializer.  And we need Axis to=20
> > > 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=20
> > > > null
> > > > but I'm not sure that this is good enough for actual work.
> > > >=20
> > > > 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=20
> > > > the
> > > > case where someone is using Dynamic Proxy as well.  Due to the=20
> > > > signatures on the
> > > > Call.invoke(...) classes, the DII Call Interface cannot=20
> 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=20
> > > 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.
> > > >=20
> > > > Gary
> > > >=20
> > > > > -----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)
> > > > >=20
> > > > >=20
> > > > > +1 to "have wsdl2java generate exception classes that do
> > > not extend
> > > > > +AxisFault" - BUT will that
> > > > > solve ur problem?
> > > > >=20
> > > > > -- dims
> > > > >=20
> > > > > --- Gary L Peskin <garyp@firstech.com> wrote:
> > > > > > Hi, Dims --
> > > > > >=20
> > > > > > 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=20
> part of the=20
> > > > > > generated code away.  However, I'm happy to tackle the
> > > > > issue and have
> > > > > > wsdl2java generate exception classes that do not extend
> > > AxisFault.
> > > > > >=20
> > > > > > Is this what you mean?
> > > > > >=20
> > > > > > Thanks,
> > > > > > Gary
> > > > > >=20
> > > > > > > -----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)
> > > > > > >=20
> > > > > > >=20
> > > > > > > Great thread for the axis-dev@ mailing list. Please post=20
> > > > > > > this
> > > > > > > there. Please note that Axis passes the JAX-RPC TCK,=20
> > > so we are
> > > > > > > JAX-RPC compliant.
> > > > > > >=20
> > > > > > > First step is to revamp wsdl2java to generate code
> > > that does not
> > > > > > > depend on AxisFault when it finds a wsdl:fault.=20
> Do you have
> > > > > > > patches that can do this? The catch would be to run=20
> > > "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=20
> > > > > > > much
> > > > > > > appreciated.
> > > > > > >=20
> > > > > > > Thanks,
> > > > > > > dims
> > > > > > >=20
> > > > > > > --- 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=20
> > > > > > > > class
> > > > > > > A sits on
> > > > > > > > a client.  In this case, class A invokes a=20
> method on class
> > > > > > > B via Axis
> > > > > > > > using an RPC service.
> > > > > > > >=20
> > > > > > > > Class A uses a small loader that I wrote.  If it is=20
> > > > > > > > running
> > > > > > > > on-platform, it loads the service class directly.  When
> > > > > running off
> > > > > > > > platform, it loads the stub generated by wsdl2java.
> > > > > > > >=20
> > > > > > > > Class B throws a service specific exception=20
> (MyException)
> > > > > > > that is not
> > > > > > > > a RuntimeException and not a RemoteException. =20
> 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.
> > > > > > > >=20
> > > > > > > > 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=20
> forth there.
> > > > > > > >=20
> > > > > > > > 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,=20
> > > > > > > > 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.
> > > > > > > >=20
> > > > > > > > Reading the JAX-RPC spec, section 4.3.6, it=20
> 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=20
> 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=20
> > > > > > > > but doesn't have create OperationDescs for the=20
> > > > > > > > constructors.
> > > > > > > >=20
> > > > > > > > I have found that, by making certain=20
> assumptions and a few
> > > > > > > > modifications, I can get Axis to generate=20
> 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=20
> boring for most
> > > > > > > people who never
> > > > > > > > want to throw MyException and are content to subclass
> > > > > > > > AxisFault
> > > > > > > > and
> > > > > > > > make their exception classes bean-like.=20
> However, if anyone=20
> > > > > > > is really
> > > > > > > > interested in bouncing ideas back and forth,=20
> I'd be happy
> > > > > > > to work up
> > > > > > > > the patches to Axis to implement a view of Service=20
> > > > > > > > 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.
> > > > > > > >=20
> >=20
> =3D=3D=3D message truncated =3D=3D=3D
>=20
>=20
> =3D=3D=3D=3D=3D
> Davanum Srinivas - http://webservices.apache.org/~dims/
>=20