AW: AxisFault or Exception are always printing stack trace

[Se...@wettschereck-partner.de]

BTW a happy new year to all of you!!!

Hi Toshi,

I ensured to have the log4j (1.2.4) everywhere in classpathes and
directories of client and server. For my client thjis does work now. No
stacktrace is printed and with this working also my problem with the
stopping of the process in handled. If something goes wrong, e.g. no valid
database-connection, I throw an AxisFault, can set the FaultCode and with
this I know on the client-side whats up.

But: In my Tomcat the stacktrace is still printed. I think that means, that
on server-side he still does not have the log4j correctly. I read about,
that you should place some jars inside the Tomcat/common/lib. But this I
would not not like, so I have all the jars in web-inf/lib. Do I have to put
log4j to common/lib? If yes, could anybody tell me why? And which jars else
are absolutely neede in that directory?

thanks in advance Seppo


-----Ursprüngliche Nachricht-----
Von: Toshiyuki Kimura [mailto:kimuratsy@nttdata.co.jp] 
Gesendet: Mittwoch, 25. Dezember 2002 10:42
An: axis-user@xml.apache.org
Betreff: RE: AxisFault or Exception are always printing stack trace


Hi Sepo,

  AXIS uses Log4j library as a log appender.
Could you make sure of the following things?

 - Log4J library (Log4j-???.jar) is in your axis/lib/ directory.
 - The file is listed in your CLASSPATH.

  BTW, did you solve your problem with Handlers what you said in "Stopping
the process of invocation by a Handler" ? Could you make a follow-up for
everyone.

Best regards,

  Toshiyuki Kimura <ki...@nttdata.co.jp>
  R&D Headquarters
  NTT DATA Corp.

-----Original Message-----
From: Sebastian.Beyer@wettschereck-partner.de
[mailto:Sebastian.Beyer@wettschereck-partner.de]
Sent: Thursday, December 19, 2002 9:59 PM
To: axis-user@xml.apache.org
Subject: AxisFault or Exception are always printing stack trace

Hi there,

my problem is, that if I am throwing an Exception inside a remote called
method, the stack trace is always printed on client side. That happens with
my own client files, but also with the ones generated by wsdl2java. After
the stack trace is printed my catch-blocks are performed as well. Who
initialzes this stack trace printing on the client side and how can I
prevent it from doing so?

On server side I tried to throw java.lang.Exception,
java.rmi.RemoteException and org.apache.axis.AxisFault. Its always the same.
on client side I got the following stack trace printed: 19.12.2002 13:46:36
org.apache.axis.client.Call invoke
INFO: Mapping Exception to AxisFault
AxisFault
 faultCode: {http://xml.apache.org/axis/}Server.generalException
 faultString: exception from remote-method...
 faultActor: null
 faultDetail:
 stackTrace: AxisFault
 faultCode: {http://xml.apache.org/axis/}Server.generalException
 faultString: exception from remote-method...
 faultActor: null
 faultDetail:

exception from remote-method...
 at <mypackage>.<myservice>.<mymethod>(myservice.java:67)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
.
.
.
After some stack trace there starts another one:
exception from remote-method...
 at
org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:13
5)
 at
org.apache.axis.encoding.DeserializationContextImpl.endElement(Deserializati
onContextImpl.java:942)
 at
org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1403)
 at
org.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator
.java:1550)
 at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XM
LDocumentScanner.java:1204)
.
.
.

And after the end of the second one I see the result of my catch-block,
which, using the stub from wsdl2java, looks like:
  try
  {
   <myservice>ServiceLocator loc = new
<myservice>ServiceLocator();
   loc.setMaintainSession(true);
   <myservice>Service service =
(<myservice>Service)loc;
   URL endpoint = new URL("<pathToMyWebservice>");
   <myservice> port = service.get<myservice>(endpoint);
   System.out.println(port.<mymethod>());
  }
  catch(Exception e)
  {
   System.out.println("catched inside the client");
  }

Inside my Tomcat window there is also printed the same stack trace, but the
result of the catch-block.

Am I doing something wrong? Is that behaviour maybe known and welcome? How
can prevent from doing this? help is highly appreciated. Greetings from
Hamburg/Germany Sepo

Re: AxisFault or Exception are always printing stack trace

[Steve Loughran <st...@iseran.com>]

1. you just need log4j in the classpath where axis.jar can see it. The stack
traces are not caused
by log4 being missing so much as axis being too verbose

2. the latest CVS version of axis prints a lot less faults

3. the latest docs also cover how to set up log4j to print less

http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/docs/reference.ht
ml#axis_logging



----- Original Message -----
From: <Se...@wettschereck-partner.de>
To: <ax...@xml.apache.org>
Sent: Monday, January 06, 2003 00:49
Subject: AW: AxisFault or Exception are always printing stack trace


BTW a happy new year to all of you!!!

Hi Toshi,

I ensured to have the log4j (1.2.4) everywhere in classpathes and
directories of client and server. For my client thjis does work now. No
stacktrace is printed and with this working also my problem with the
stopping of the process in handled. If something goes wrong, e.g. no valid
database-connection, I throw an AxisFault, can set the FaultCode and with
this I know on the client-side whats up.

But: In my Tomcat the stacktrace is still printed. I think that means, that
on server-side he still does not have the log4j correctly. I read about,
that you should place some jars inside the Tomcat/common/lib. But this I
would not not like, so I have all the jars in web-inf/lib. Do I have to put
log4j to common/lib? If yes, could anybody tell me why? And which jars else
are absolutely neede in that directory?

thanks in advance Seppo