[J2EE and AXIS-SOAP] Stack-trace bij foutafhandeling.

[bvp]

Ik ben bezig met het maken van webservices op basis van Axis-soap.

De foutafhandeling wordt in de businesslaag netjes afgevangen en/of doorgegooid naar de wsejb-laag.
Hier map ik de business-exceptions naar de overeenkomstige AxisFault.
Dit gaat allemaal goed en de AxisFault wordt dus ook netjes doorgegeven.

Ondanks dat de exceptions netjes worden gegooid, wordt er toch een stack-trace in de Bea-weblogic console gegeven.

Na flink zoeken heb ergens gelezen dat dit op te lossen is door de AxisFault specifiek met waardes te vullen op de volgende manier:

Java:

soapFault.setFaultCodeAsString( fullClassName );
soapFault.setFaultReason( className );
soapFault.setFaultDetailString( message );

Hierin is "fullClassName" dus de volledige classname met package: bla.bla.bla.BlaException
"className" dan dus alleen maar BlaException.

Nu krijg ik de exception wel netter gevuld terug dat dus <faultcode> en <faultstring> gevuld zijn, maar de stackTrace zie ik dus nog steeds terug in de console.

Heeft iemand dit eerder gehad en op weten te lossen?

aanvullende info:
Server: Bea Weblogic 8.1
Soap: Axis soap 1.3 (ook geprobeerd met 1.1 en 1.2)
Java: 1.4

[bvp]

/me Schop...

Helemaal niemand die een idee heeft?
Al is het maar een mega-dom antwoord, misschien helpt het me toch in de juiste richting te zoeken dan

[Janoz]

Ten eerste vraag ik me af wat het probleem is van een stacktrace in je logs. Lijkt mij erg handig mocht er een keer wat mis gaan. Ten tweede vermoed ik dat het wel of niet afdrukken van de stacktrace best ingesteld zou kunnen worden mbv de log level, ik zit echter niet zo goed in axis en bea om daar harde uitspraken over te doen.

[bvp]

Janoz schreef op woensdag 22 maart 2006 @ 10:39:
Ten eerste vraag ik me af wat het probleem is van een stacktrace in je logs. Lijkt mij erg handig mocht er een keer wat mis gaan. Ten tweede vermoed ik dat het wel of niet afdrukken van de stacktrace best ingesteld zou kunnen worden mbv de log level, ik zit echter niet zo goed in axis en bea om daar harde uitspraken over te doen.

Al het in de logging zou zijn, zou het zeker niet erg zijn -> sterker nog daar wil ik hem ook terug zien
Het is juist het probleem dat de stacktrace in de console terugkomt. Daar waar je de BEA-weblogic server opstart en server-gerelateerde zaken terugziet.
Als je bijv. een null-pointer in je code krijgt, knalt deze er ook in de console in als je hem niet afvangt. Dan is het dus zaak om je code aan te passen dat dat niet gebeurt.

Nu is het dus zo dat deze exception wel afgevangen wordt en dus ook een bekende exception doorgegooid wordt, maar toch wordt er door de server een stacktrace gegenereerd.
Alsof de server deze dus niet kent.

[JKVA]

bvp schreef op woensdag 22 maart 2006 @ 10:47:
[...]
Als je bijv. een null-pointer in je code krijgt, knalt deze er ook in de console in als je hem niet afvangt. Dan is het dus zaak om je code aan te passen dat dat niet gebeurt.

Ik misbruik jouw voorbeeld even. Een NullPointerException is een RuntimeException, ofwel helemaal veroorzaakt door de programmeur. Als het goed is, komt die maar één keer in je logs te staan, want daarna is de fout opgelost. Ik zou juist blij zijn met die stacktrace.

Het slechtste wat je kunt doen is exceptions verdoezelen, zelfs zo slecht dat je bijvoorbeeld voor het Sun Certified Developer examen zomaar kunt zakken, als je het doet, bijvoorbeeld een lege catch.

Als er namelijk een keer iets echt fout gaat en je hebt geen stacktrace ofzo in je logs, ga dan maar lekker zoeken.

[Janoz]

Mwah, dingen die naar de stdout geschreven worden zie ik zelf ook als logging, maar dat kan een interpretatie verschil zijn. Wat je eventueel nog zou kunnen doen is met een debugger door de code stappen om te kijken waar exact die stacktrace wordt geprint. Aangezien axis open source is kun je ook gewoon door die code heen lopen.

[momania]

Ik neem aan dat BEA-Weblogic ook gewoon iets van log4j gebruikt?
Zo ja: die beter configureren

[bvp]

JKVA schreef op woensdag 22 maart 2006 @ 11:01:
[...]


Ik misbruik jouw voorbeeld even. Een NullPointerException is een RuntimeException, ofwel helemaal veroorzaakt door de programmeur. Als het goed is, komt die maar één keer in je logs te staan, want daarna is de fout opgelost. Ik zou juist blij zijn met die stacktrace.

Het slechtste wat je kunt doen is exceptions verdoezelen, zelfs zo slecht dat je bijvoorbeeld voor het Sun Certified Developer examen zomaar kunt zakken, als je het doet, bijvoorbeeld een lege catch.

Als er namelijk een keer iets echt fout gaat en je hebt geen stacktrace ofzo in je logs, ga dan maar lekker zoeken.

Zoals ik net dus al zei, gaat het hier niet om een stacktrace in de logs maar in de console.

Uiteraard mag een NullPointer maar één keer voorkomen op een bepaald punt, want daarna moet ie meteen opgelost zijn. Dit voorbeeld haalde ik slechts aan omdat dit de enige exception is die ik wel es in de console tegenkom tijdens het ontwikkelen. Ook zei ik dit hiervoor al.

Voor de duidelijkheid gaat het hier dus om een exception (Axis) die juist bekend zou moeten zijn en dus expliciet gegooid wordt naar de aanroepende partij. En toch veroorzaakt dit een exception in de console.

[JKVA]

Sorry, dan weet ik het niet. Ik ben verder niet met Axis bekend.

[bvp]

momania schreef op woensdag 22 maart 2006 @ 11:07:
Ik neem aan dat BEA-Weblogic ook gewoon iets van log4j gebruikt?
Zo ja: die beter configureren

Yep, log4j wordt ook netjes intensief gebruikt maar heeft hier verder niets mee te maken


Misschien handig om zo'n console stack-trace hier neer te plempen, is misschien duidelijker:

code:

<22-mrt-2006 11:22:08 uur CET> <Info> <HTTP> <BEA-101047> <[ServletContext(id=16655481,name=consoleext,context-path=/consoleext)] Generated java file: c:\projec
ts\bla\.\config\bla\bla01\.wlnotdelete\extract\bla01__appsdir_consoleext_ear_consoleext\jsp_servlet\_logviewer\__viewlog.java>
<22-mrt-2006 11:22:23 uur CET> <Info> <HTTP> <BEA-101047> <[ServletContext(id=7911795,name=businessportal_ws,context-path=/businessportal_ws)] AxisServlet: init
>
<22-mrt-2006 11:22:23 uur CET> <Info> <EJB> <BEA-010051> <EJB Exception occurred during invocation from home: bla.businessportal.wsejb.businessportalserviceada
pter.BusinessPortalServiceAdapterBean_uykjmz_HomeImpl@11733a5 threw exception: UsernameAlreadyExists
AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}nl.blabla.webservices.bla.businessportal._1_0.UsernameAlreadyExists
 faultSubcode:
 faultString: UsernameAlreadyExists
 faultActor:
 faultNode:
 faultDetail:
        {}:User blabla already exists in the BLA.

UsernameAlreadyExists
        at bla.businessportal.wsejb.businessportalserviceadapter.BusinessPortalServiceAdapterBean.handleException(BusinessPortalServiceAdapterBean.java:211)
        at bla.businessportal.wsejb.businessportalserviceadapter.BusinessPortalServiceAdapterBean.createUser(BusinessPortalServiceAdapterBean.java:87)
        at mosa.businessportal.wsejb.businessportalserviceadapter.BusinessPortalServiceAdapterBean_uykjmz_EOImpl.createUser(BusinessPortalServiceAdapterBean_uyk
jmz_EOImpl.java:46)
        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)
        at org.apache.axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:397)
        at org.apache.axis.providers.java.EJBProvider.invokeMethod(EJBProvider.java:459)
        at org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:186)
        at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323)
        at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
        at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
        at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
        at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:453)
        at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)
        at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:699)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
        at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1006)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:419)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:315)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6718)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
        at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3764)
        at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2644)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
>

[momania]

bvp schreef op woensdag 22 maart 2006 @ 11:28:
[...]


Yep, log4j wordt ook netjes intensief gebruikt maar heeft hier verder niets mee te maken

Heeft er denk ik alles mee te maken
Een exception wordt via log4j bijna altijd op error level gelogd en daarmee ook de stacktrace

Ik zie alleen hier dat de exception op info level wordt gelogd. Hij wordt aangemerkt als EJB Exception (waarschijnlijk door het doorgooien naar boven) waardoor de exception dus uiteindelijk bij je server uit komt en ook gelogd wordt.

Ik denk dus dat je je exception ergens iets te ver door gooit naar boven

[bvp]

momania schreef op woensdag 22 maart 2006 @ 11:35:
[...]

Heeft er denk ik alles mee te maken
Een exception wordt via log4j bijna altijd op error level gelogd en daarmee ook de stacktrace

Ik zie alleen hier dat de exception op info level wordt gelogd. Hij wordt aangemerkt als EJB Exception (waarschijnlijk door het doorgooien naar boven) waardoor de exception dus uiteindelijk bij je server uit komt en ook gelogd wordt.

Ik denk dus dat je je exception ergens iets te ver door gooit naar boven

Nope, zoals je in de TS kunt lezen wordt juist op wsejb-niveau de business-laag exception vertaald naar een Webservice (Axis) exception om naar de client te gooien.
Deze moet immers toch ook weten dat deze gebruiker al bestaat
Het probleem is hier dus zeker niet de logging maar dat je een "bekende" exception naar de client gooit (d.m.v. AxisFault) en dat deze door de container gewoon niet herkend lijkt te worden?

[momania]

bvp schreef op woensdag 22 maart 2006 @ 11:42:
[...]


Nope, zoals je in de TS kunt lezen wordt juist op wsejb-niveau de business-laag exception vertaald naar een Webservice (Axis) exception om naar de client te gooien.
Deze moet immers toch ook weten dat deze gebruiker al bestaat

Ok, ik zie nu idd dat je een UsernameAlreadyExists exception door gooit.

Het probleem is hier dus zeker niet de logging maar dat je een "bekende" exception naar de client gooit (d.m.v. AxisFault) en dat deze door de container gewoon niet herkend lijkt te worden?

Toch blijft het probleem wel de settings van logging denk ik, maar dan op niveau van je webservice laag van Weblogic. Lijkt mij niet dat deze exception trace zomaar naar de console dumpt, dat zal wel 'by design' zijn en waarschijnlijk dus ook wel configureerbaar

[Janoz]

Heb je mijn debug voorstel al geprobeerd?

[bvp]

Janoz schreef op woensdag 22 maart 2006 @ 12:36:
Heb je mijn debug voorstel al geprobeerd?

Eeeehhhum helemaal overheen gelezen, sorry

Dit ga ik nu meteen doen, laat het zo weten.


Edit:
Server gestart in debug-mode ( -debug).
Gekoppeld aan Eclipse en breakpoints gezet.
Zie mooi tot op het niveau dat hij de webservice verlaat welke exception het is met stacktrace: null.
In de AxisFaults kan ik dus geen breakpoints zetten dus daar zie ik verder niets meer, wordt hierna gewoon door de container / server afgehandeld?

Of kan dit op een andere manier?

[ Voor 45% gewijzigd door bvp op 22-03-2006 13:13 ]

[Janoz]

Als je vlak voor het gooien van de exception een breakpoint zet dan kun je zo de code van axis in steppen. Zorg wel dat je de juiste versie van de sourcecode van axis hebt.

[ Voor 6% gewijzigd door Janoz op 22-03-2006 15:13 ]

[-FoX-]

Wat je in eclipse ook kan doen, is een breakpoint op een exceptie zetten. Op het moment dat die dan gegooid wordt, ga je er via de debugger automatisch naartoe. Op die manier kan je weten waar en hoe deze gegooid worden.

(DEBUG view, tabblad 'breakpoints', meest rechtse optie in tabblad title "add java exception breakpoint")

[bvp]

-FoX- schreef op woensdag 22 maart 2006 @ 15:19:
Wat je in eclipse ook kan doen, is een breakpoint op een exceptie zetten. Op het moment dat die dan gegooid wordt, ga je er via de debugger automatisch naartoe. Op die manier kan je weten waar en hoe deze gegooid worden.

(DEBUG view, tabblad 'breakpoints', meest rechtse optie in tabblad title "add java exception breakpoint")

Is een mooie optie, had ik nog niet eerder gezien, thnx
Helaas werkt dit alleen niet met Axis exceptions, deze zitten namelijk niet in je business-logic maar worden gedefinieerd door je WSDL waar vervolgens weer een Java-jar van gemaakt is.

@Janoz:
Ook in de code van Axis stappen wil ik maar niet voor elkaar krijgen
Waar moet ik die source precies neerzetten zodat ie hierin stapt? In de codebase ergens bij? In de code verwijst hij nu namelijk (uiteraard) gewoon naar de gecompileerde code in de jar ?

[Janoz]

In eclipse krijg ik altijd een melding wanneer de source bij een sepcifiek stuk code niet beschikbaar is. Ik kan in dat scherm dan op iets als 'attach code' drukken en vervolgens een map toevoegen aan het lijstje met sourcecodes. Zit je wel in debug view?

[bvp]

Janoz schreef op donderdag 23 maart 2006 @ 10:47:
In eclipse krijg ik altijd een melding wanneer de source bij een sepcifiek stuk code niet beschikbaar is. Ik kan in dat scherm dan op iets als 'attach code' drukken en vervolgens een map toevoegen aan het lijstje met sourcecodes. Zit je wel in debug view?

Bij mij gaat ie gewoon standaard naar de debug view en ik kan inderdaad gewoon overal instappen etc.
Ik krijg alleen die melding dus niet maar bij mij gaat hij dan gewoon rechtstreeks naar de .class file en dan krijg ik in eclipse dus gewoon de "Class File Editor" te zien...

[-FoX-]

Ga naar je project properties, kies build path, en ga dan naar je libraries.
Daar zie je een oplijsting van alle gebruikte libraries. Klik de gewenste library open, daar zie je dan source location. Selecteer deze en klik op edit.

Overigens kan je je sources gewoon op een willekeurige plaats opslaan.

[bvp]

-FoX- schreef op donderdag 23 maart 2006 @ 11:32:
Ga naar je project properties, kies build path, en ga dan naar je libraries.
Daar zie je een oplijsting van alle gebruikte libraries. Klik de gewenste library open, daar zie je dan source location. Selecteer deze en klik op edit.

Overigens kan je je sources gewoon op een willekeurige plaats opslaan.

Thnx, weer wat geleerd
Probleem alleen nog steeds niet opgelost...