AW: AW: [JBoss-user] How to throw AxisFault in JBoss.net?

2003-02-06 Thread Jung , Dr. Christoph
So would it be possible to write a special request handler in the bean´s
transport chain that takes your 
(non-Axis-Fault, means that the container will let it through unchanged)
application exception and wraps it into an appropriately massaged axis fault
such that the name of the original exception will appear in the response
envelope?

Then you can have a client-side stub that reconstructs the exception for you


CGJ 

-Ursprüngliche Nachricht-
Von: Kevin Conner [mailto:[EMAIL PROTECTED]] 
Gesendet: Donnerstag, 6. Februar 2003 17:59
An: '[EMAIL PROTECTED]'
Betreff: RE: AW: [JBoss-user] How to throw AxisFault in JBoss.net?


Sorry to take so long in responding but I've just been going through this
issue in our code, stand alone axis 1.0 + jboss (not jbossnet).

 This approach is outdated, because the best way, IMHO, is to take the 
 server-generated wsdl and pre-generate client stubs using the 
 wsdl2java toolkit. They should have some exception support there ready
 to remap the
 AxisFault to 
 ordinary java exceptions, shouldn´t they? Classname is there, 
 message is
 there, maybe not the stack trace.

The 1.0 code only adds the exception name if it is a subclass of AxisFault
so only the axis faults can be reproduced on the client side.  All other
exceptions get translated into an AxisFault containing only the message and
stack trace.

I have had to extend the wsdl2java to include my own type mapping hierarchy
and exception handling (the type mapping for some custom DTOs that are not
java beans).  The exception gets serialised into XML on the server side and
placed into the soap fault detail by my own EJB provider.  The new generated
proxy code catches the AxisFault on the client and, if the exception detail
is present, regenerates the original exception and throws it instead.

This has required a very big hack to get it working but it does work. The
changes are very fragile so I would be loathed to change to another version
of Axis without a lot of work.  It is certainly safer to stick with the Axis
implementation but unfortunately that was not an option open to me.

Kev

Kevin Conner
This is a personal e-mail. Any views or opinions presented are 
solely those of the author and do not necessarily represent those 
of Orchard Information Systems Ltd.


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com ___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
###

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user



AW: AW: [JBoss-user] How to throw AxisFault in JBoss.net?

2003-01-30 Thread Jung , Dr. Christoph
Jonas,

I´m not sure what I did there, but there should be some (hmm, outdated) code
in jboss.net that implements
a client-side java.lang.reflect.InvocationHandler for transparently calling
remote web services through
ordinary remote interfaces/dynamic proxies. 

It may as well be that I left exception handling out of the game.

This approach is outdated, because the best way, IMHO, is to take the
server-generated wsdl and pre-generate client stubs using the wsdl2java
toolkit. They should have some exception support there ready to remap the
AxisFault to 
ordinary java exceptions, shouldn´t they? Classname is there, message is
there, maybe not the stack trace.

If they do not do that, parsing the AxisFault string is still ok, IMHO,
inside the generic proxy or the generated client stub, because then your
application still is clean from those dirty hacks and you can change that
code whenever axis changes just by tweaking the proxy code or the code
generator. In that case, would you volunteer implementing that when I
support you in finding the right place in jboss.net to place it?

Best,
CGJ


-Ursprüngliche Nachricht-
Von: Jonas Engman [mailto:[EMAIL PROTECTED]] 
Gesendet: Donnerstag, 30. Januar 2003 15:55
An: '[EMAIL PROTECTED]'
Betreff: Re: AW: [JBoss-user] How to throw AxisFault in JBoss.net?


Thank you for answer and it's probably best not to throw any custom
AxisFault inside a bean. If I create a CustomApplicationException that
inherits from for example java.lang.Exception and throw that from the
session bean it's all being wrapped up inside a AxisFault that contains the
full classname of the exception followed by the error-message as the
faultMessage. The errorCode of the message is:

xmlns:ns1=http://xml.apache.org/axis/;ns1:Server.userException

The problem, as I see it, is that is should somehow be examine the
exception/fault on the client-side. If a do a try/catch statement like

try {
} catch (AxisFault af) {

}

it's possible to catch the exception but how am I supposed to tell different
server-exceptions apart? The only unique identifier I have is the
faultMessage and I don't think parsing that string is convenient. Shouldn't
I be able to somehow set the faultCode? Or how should the client handle
different faults?

Thanks again
/Jonas

On Thu, 2003-01-30 at 14:05, Jung , Dr. Christoph wrote:
 The custom exception that you throw should be ideally mapped by 
 axis/jboss.net into the soapfault. (Your bean should not know whether 
 it is published as a web-service).
 
 What if you declare and throw a CustomApplicationException? How does 
 the returned soap-message look like?
 
 If I remember right, axis will include the stack trace into the detail 
 section of a soap-fault ...
 
 AxisFault is the axis-internal exception if something goes wrong in 
 the web service engine (not the application), therefore it has the 
 same status as a java.rmi.ServerException, java.rmi.RemoteException 
 ... But that is used only outside the application in the container.
 
 
 CGJ
 
 
 -Ursprüngliche Nachricht-
 Von: Jonas Engman [mailto:[EMAIL PROTECTED]]
 Gesendet: Donnerstag, 30. Januar 2003 11:44
 An: '[EMAIL PROTECTED]'
 Betreff: RE: [JBoss-user] How to throw AxisFault in JBoss.net?
 
 
 Thanks for your reply but AxisFault is a checked exception. It 
 inherits from java.rmi.RemoteException. The point is that JBoss.net 
 should be able to report faults from the EJB-tier to the client-side 
 and to wrap the fault inside another fault doesn't make any sense.
 
 Jonas
 
 
 On Wed, 2003-01-29 at 22:54, JD Brennan wrote:
  AxisFault is probably unchecked so it gets
  wrapped.  I bet the spec says that only
  checked exceptions have to get passed back
  intact.
  
  You could wrap AxisFault in a checked exception,
  maybe...
  
  JD
  
  -Original Message-
  From: Jonas Engman [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, January 29, 2003 1:21 PM
  To: [EMAIL PROTECTED]
  Subject: [JBoss-user] How to throw AxisFault in JBoss.net?
  
  
  I'm using JBoss 3.2beta1/JBoss.net and I'm trying to throw an
  AxisFault from a SessionBean but the exception seems somehow be 
  wrapped inside a javax.ejb.EJBException.
  
  I'm throwing the fault using
  
  throw new AxisFault(a fault has occurred);
  
  but the faultString that appears on the client-side is
  javax.ejb.EJBException: null; CausedByException is: a fault has
  occurred.
  
  A closer look at the detail-body using TCPMon shows that the it
  contains the full stacktrace followed by the original faultString but 
  it's all wrapped inside the detail-tag.
  
  The same thing goes for the original faultCode, faultActor and
  faultDetail.
  
  Is it somehow possible to throw an AxisFault that doesn't get 
  wrapped
  inside a SOAPFault that contains the javax.ejb.EJBException?
  
  Without the ability to throw a user-defined AxisFault I don't see 
  how
  a fault should be reported to the client-side.
  
  Thanks
  Jonas