[JAVA & Struts] Onsoortige 500 error die niet gelogd wordt

[Verwijderd]

Lokaal op een Resin 2.1.1 server heb ik een JAVA webapp draaien die gebruik maakt van een Struts framework(met TILES) en de daarbij behordende Message Resource Properies. Alles loopt perfect.

Dit alles gaat als WAR naar een test server waar ik de volgende error krijg bij het submitten van een Struts ActionForm die ik niet kan verklaren:

code:

500 Servlet Exception
java.lang.VerifyError: (class: com/utils/MailArticle, method: execute
signature: (Lorg/apache/struts/action/ActionMapping;Lorg/apache/struts/action/ActionForm;Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)Lorg/apache/struts/action/ActionF
    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:1610)
    at java.lang.Class.getConstructor0(Class.java:1922)
    at java.lang.Class.newInstance0(Class.java:278)
    at java.lang.Class.newInstance(Class.java:261)
    at org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:231)
    at org.apache.struts.action.RequestProcessor.processActionCreate(RequestProcessor.java:326)
    at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:268)
    at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
    at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:165)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:103)
    at com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.java:96)
    at com.caucho.server.http.Invocation.service(Invocation.java:315)
    at com.caucho.server.http.CacheInvocation.service(CacheInvocation.java:135)
    at com.caucho.server.http.RunnerRequest.handleRequest(RunnerRequest.java:346)
    at com.caucho.server.http.RunnerRequest.handleConnection(RunnerRequest.java:274)
    at com.caucho.server.TcpConnection.run(TcpConnection.java:139)
    at java.lang.Thread.run(Thread.java:534)


--------------------------------------------------------------------------------
Resin 2.1.11 (built Mon Sep 8 09:36:19 PDT 2003)

Zoals je ziet wordt de foutmelding op de 3e regel niet afgemaakt na "Lorg/apache/struts/action/ActionF", dit moet ActionForm zijn waarschijnlijk, de vraag is echter wat daarna nog komt.

Validering van het ActionForm werkt wel, maar direct na het submitten gaat het fout in class: com/utils/MailArticle. Als eerste heb ik daar, evenals in alle imports, een Log4j log.info("start <class>") staan, maar die vind ik niet terug in de log. Alles is ingesteld om paranoia veel te loggen, maar niets.... (btw. hoe log je de actions die in struts-config worden aangeroepen?) Ook via de Exception catcher class wordt niets gelogd.

MailArticle wordt zo aangeroepen in struts-config.xml

code:

<action path="/sendArticle" name="sendArticleForm" scope="request" input="/press.send.service" type="com.utils.MailArticle" validate="true">
    <forward name="ok" path="popupPressArticle"/>
</action>

In andere ActionForms verloopt alles ok, de ActionMap klopt ook. Nogmaals, lokaal met dezelfde WAR: geen enkel probleem. De Resin server op de testserver is gelijk en gebruikt dezelfde lib files, het enige verschil is het OS: Win2k vs. Suse.

Heeft iemdnd enig idee waar de fout kan liggen?

Alvast bedankt

[ Voor 15% gewijzigd door Verwijderd op 27-05-2004 13:49 ]

[bigbeng]

Bij het zoeken op Google naar java.lang.VerifyError kwam ik vooral voorbeelden tegen van versieconflicten.

Zou het dus kunnen zijn dat je testserver:
1) Gebruik maakt van een andere versie van struts?
2) Gebruik maakt van een andere versie van Resin?
3) Gebruik maakt van een andere JVM?

En probeer ook eens het resterende deel van de foutmelding boven water te krijgen (ik heb geen idee of dat kan), want nu wordt het middenin afgekapt, terwijl het interessante deel wegvalt.

[ACM]

Je kan Struts expliciet op debugging zetten door in de log4j.xml/properties te spelen met de org.apache.struts-settings, zelf had ik daar ook wat problemen mee om uit te zoeken waarom ie nou niets wilde loggen.
't Lijkt overigens haast wel een probleem binnen de reflection van Java, wellicht kan je daarin uitzoeken hoe een VerifyError opgegooid kan worden. Als je de jdk hebt, is er ergens een src.zip, daar kan je evt de source van Class.java bekijken om die specifieke regel te beoordelen.

[Verwijderd]

bigbeng schreef op 27 mei 2004 @ 14:02:
Bij het zoeken op Google naar java.lang.VerifyError kwam ik vooral voorbeelden tegen van versieconflicten.

Zou het dus kunnen zijn dat je testserver:
1) Gebruik maakt van een andere versie van struts?
2) Gebruik maakt van een andere versie van Resin?
3) Gebruik maakt van een andere JVM?

En probeer ook eens het resterende deel van de foutmelding boven water te krijgen (ik heb geen idee of dat kan), want nu wordt het middenin afgekapt, terwijl het interessante deel wegvalt.

1. Struts.jar ligt in de WAR file, dus gelijk
2. Zelfde Resin, maar verschillend OS
3. Zelfde JVM

Het moet ergens eeen versieconflict zijn, maar alles lijkt gelijk te zijn.
De resterende foutmelding... tsja, dat is een probleem op zich.

Je kan Struts expliciet op debugging zetten door in de log4j.xml/properties te spelen met de org.apache.struts-settings, zelf had ik daar ook wat problemen mee om uit te zoeken waarom ie nou niets wilde loggen.
't Lijkt overigens haast wel een probleem binnen de reflection van Java, wellicht kan je daarin uitzoeken hoe een VerifyError opgegooid kan worden. Als je de jdk hebt, is er ergens een src.zip, daar kan je evt de source van Class.java bekijken om die specifieke regel te beoordelen.

code:

    <category name="org.apache" priority="INFO">
        <appender-ref ref="FRONTEND"/>
    </category>

    <category name="org.apache.struts" priority="INFO">
        <appender-ref ref="FRONTEND"/>
    </category>

    <category name="org.apache.struts-settings" priority="INFO">
        <appender-ref ref="FRONTEND"/>
    </category>

    <root>
        <priority value="INFO"/>
        <appender-ref ref="FRONTEND"/>
    </root>

zo staat het in mijn Log4j.xml, maar alleen de root is al voldoende. Moet nu maar source browsen... bah!

[ Voor 40% gewijzigd door Verwijderd op 27-05-2004 14:29 ]

[momania]

Ik zou iig even org.apache.struts.util.RequestUtils opnemen in je logging, of iig de package org.apache.struts.util en die op debug zetten.
Daar lijkt het fout te gaan en dan je even zien wat die org.apache.struts.util.RequestUtils allemaal voor input krijgt.

[Verwijderd]

Ok, in log4j DEBUG gebruiken helpt. Ben onbekend met Log4j dus dag je met INFO wel alles zou krijgen te zien, niet dus.

--edit--
Uiteindelijk ligt het probleem hier
jakarta-struts-1.1-src\src\share\org\apache\struts\action\RequestUtils.java:

code:

    public static Object applicationInstance(String className)
        throws ClassNotFoundException, IllegalAccessException, InstantiationException {

        return (applicationClass(className).newInstance());

    }

Opgeroepen in jakarta-struts-1.1-src\src\share\org\apache\struts\action\RequestProcessor.java:

code:

       try {
                instance = (Action) RequestUtils.applicationInstance(className);
                // TODO Maybe we should propagate this exception instead of returning
                // null.
            } catch (Exception e) {
                log.error(
                    getInternal().getMessage("actionCreate", mapping.getPath()),
                    e);
                    
                response.sendError(
                    HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
                    getInternal().getMessage("actionCreate", mapping.getPath()));
                    
                return (null);
            }

...en er komt geen error in de log

[ Voor 92% gewijzigd door Verwijderd op 01-06-2004 16:09 . Reden: volgende probleem ]

[The - DDD]

Hoe je het op kan lossen weet ik niet, maar de bron van je probleem kan liggen aan de hoeveelheid taglibs die je gebruikt. De Java JVM heeft een limiet op de code lengte van een methode body, de JVM lat dit weten middels een verifyerror. Je kan hieromheen door jsp:include te gebruiken of tiles te gebruiken.

Wel heb ik iets kunnen vinden over het meerdere keren voorkomen van servlet.jar op een classpath, dit kun je checken door gebruik te maken van de -verbose command switch. http://www.caucho.com/support/resin-interest/0007/0005.html

[Verwijderd]

The - DDD schreef op 01 juni 2004 @ 18:00:
Hoe je het op kan lossen weet ik niet, maar de bron van je probleem kan liggen aan de hoeveelheid taglibs die je gebruikt. De Java JVM heeft een limiet op de code lengte van een methode body, de JVM lat dit weten middels een verifyerror. Je kan hieromheen door jsp:include te gebruiken of tiles te gebruiken.

Wel heb ik iets kunnen vinden over het meerdere keren voorkomen van servlet.jar op een classpath, dit kun je checken door gebruik te maken van de -verbose command switch. http://www.caucho.com/support/resin-interest/0007/0005.html

Nogmaals: lokaal gaat alles ok met dezelfde JVM, dus ik denk niet dat het daar aan ligt. Ook Tiles gebruik ik al, maar het betreft hier een class die door een Struts ActionMapping wordt aangeroepen en moet worden aangeroepen ivm Struts' Message Resources die alleen op een dergelijke manier kunnen worden benaderd.

In m'n classpath komt niets dubbel voor.

[The - DDD]

Verwijderd schreef op 02 juni 2004 @ 09:55:
[...]

In m'n classpath komt niets dubbel voor.

Weet je het zeker?

Je krijgt de error immers wel in een andere omgeving dan je eigen systeem. Er zit dus een verschil in die omgeving. Als het goed is kun je een optie als -verbose meegeven aan een JVM en zodoende alle classpaden nakijken.

[No offense mode]
Je zult niet de eerste zijn die de mist in gaat met classloaders en aanverwant gedoe in Java. (zoals ikzelf bijvoorbeeld)
[/No offense mode]

[Verwijderd]

Weet je het zeker?

Je krijgt de error immers wel in een andere omgeving dan je eigen systeem. Er zit dus een verschil in die omgeving. Als het goed is kun je een optie als -verbose meegeven aan een JVM en zodoende alle classpaden nakijken.

Zeker weten doe je het nooit. Ik gebruik onderstande code, heb jij misschien een beter idee? Beetje naadje is dat m'n netwerkbeheerder geen versie details kan geven van de jar's op de server.

code:

String cp = System.getProperty("java.class.path");
cp = cp.replace(';', '\n');
System.out.println("\n---------\nSystem classpath:\n" + cp +"\n---------\n\n");

[ Voor 22% gewijzigd door Verwijderd op 03-06-2004 16:08 ]