HTML Code im Output unvollständig

[MichiM]

Hallo,


eine kleine JSP, die sich selbst per Form action aufruft, gibt HTML aus. :wink:

So lang die JSP ohne Form action aufgerufen wird, gibt sie den HTML-Code komplett aus.
Sobald sie jedoch über das Form aufgerufen wird, wird der HTML-Code abgeschnitten und zwar wird der nicht an einer ganz bestimmten (durch eine Codestelle identifizierbare) Stelle, sondern scheinbar nach einer best. Output-Länge, was sich einfach dadurch feststellen lässt, dass man davor mal einige Zeilen Text anbaut und schon wird der Output an einer anderen Stellen abgeschnitten.

(Hab mir den kompilierten JSP-Code angeschaut: Generiert wird auf jeden Fall alles, nur ausgegeben später nicht.)

Ich verwende hierbei den Tomcat 5.5 und Firefox 2 (habe aber auch den Opera probiert, gleiches Problem).


So einen Fehler hatte ich auch noch nicht. Ist da irgendeine Server-Kofiguration verantwortlich? Maximale Outputlänge bei Requests oder so was?
(Allerdings wäre die dann schon sehr geizig vorkonfiguriert.)

Muss da mal URLDecoder probieren...

Gruß Michi

 

[gex]

hey,

also nach der migration auf websphere 6.1 hatten wir auch so ein problem, da es aber eine struts applikation ist, haben wir immer post daten...

das problem klingt nach irgendeinem buffer problem, hast du irgendwelche filter definiert? bei uns war es ein compressionfilter. nachdem wir den rausgenommen hatten war alles i.o. - nur muss ich dann noch schauen, was geändert hat, damit wir die komprimierung wieder reinkriegen.

gruss
gex

 

[MichiM]

Keine reproduzierbare Fehlerursache feststellbar. Wirkt irgendwie labil, was ich aber jetzt schon öfter bei Java-Projekten erlebt habt.


Abgeschickt werden die Daten jedenfalls über dieses Formular:

<form action="bearbeiten.jsp" method="get" accept-charset="UTF-8" style="padding:0px;margin:0px;">

Eingelesen so:

zeit                = java.net.URLDecoder.decode ( request.getParameter ( "zeit" ), "UTF-8" );

Angezeigt so:

                                                <tr>

                                                    <td class="darstellungszelle" bgcolor="<%= hintergrundfarbe %>">

                                                        Zeit

                                                    </td>

                                                    <td class="darstellungszelle" bgcolor="<%= hintergrundfarbe %>">

                                                        <input type="text" name="zeit" value="<%= zeit %>" size="40" maxlength="128">

                                                    </td>

                                                </tr>

Sollte man da noch irgendwie rummaskieren...?



Filter hab ich keine installiert. Es läuft der Tomcat 5.5 in der NetBeans-Umgebung.




(In PHP macht man so was in einer halben Stunde und dann läufts, da hockt man tagelang dran und es geht noch nicht. :bahnhof: )


Der kann doch nicht einfach den Code abschneiden da, Frechheit. :lol:

 

[gex]

also soweit ich dein problem nachvollziehen kann, sollte das nicht direkt ein jsp problem sein, sonst würde dir ja irgendwo ein error geworfen (prüf zur sicherheit aber trotzdem mal die logs)

ich würde auch anstellle von method="get" method="post" verwenden, dann bräuchtest du auch nicht über den URLDecoder zu gehen, und im falle von formularen ist eh post zu empfehlen

nebenbei könntest du anstelle von scriptlets hier auch ganz gut auf die JSTL zurückgreifen, was dann das ganze
auch schöner macht.

(In PHP macht man so was in einer halben Stunde und dann läufts, da hockt man tagelang dran und es geht noch nicht.)

arbeite sonst auch noch mit php, aber ist doch immer eine frage der erfahrung mit einer sprache, wie schnell man damit arbeiten kann. an solchen kleinen problemen geht ja meistens die zeit verloren...

 

[MichiM]

Das Abschneiden des Codes findet dann statt, wenn ein Datenbankschreibzugriff stattfindet...

Wenn ich die Zeile mit executeUpdate rauskommentiere, wird zwar natürlich nicht gespeichert, aber der HTML-Output auch nicht gekürzt.

Ich weiß nur leider auch nach genauerem Hingucken und x-fachem Umwandeln des Query-Strings nicht, was daran jetzt geeignet sein könnte, den HTML-Output zu kürzen...? :

    public void bearbeiteten_datensatz_speichern ( String id, String vorname, String name, String geschlecht, String datum, String zeit, String ort, String laenderkennung )
    {

            String sSql = "";
            
            try
            {
        /*
                    sSql = "UPDATE dav SET vorname='" + vorname + "', " +
                                           "name='" + name + "', " +
                                           "geschlecht='" + geschlecht + "', " +
                                           "datum='" + datum + "', " +
                                           "uhrzeit='" + zeit + "', " +
                                           "ort='" + ort + "', " +
                                           "laenderkennung='" + laenderkennung + "' " +
                                           "WHERE ID='" + id + "'";*/

                             sSql = "UPDATE dav SET vorname='2' WHERE ID=15";

                    

                    this.fehlercode             = this.anweisung.executeUpdate ( sSql );


            }
            catch ( Exception ex )
            {
                
                
                // "Fehler beim Schreiben des Datensatzes:\n\nSQL-Anweisung: " + sSql + "\n\nFehlermeldung: " + ex.getMessage();

            }  
                    
    }

Es sind also noch nicht mal variable Strings in der Test-Query und dennoch wird der HTML-Output wie beschrieben abgeschnitten, sobald diese Methode in der JSP aufgerufen wird. Lesen aus der Datenbank dagegen funktioniert einwandfrei.

Hat irgendjemand eine Idee, wie es sein kann, dass so eine Query den Output abschneidet? ???:L

(Datenbanktreiber hab ich sicherheitshalber auch nochmal frisch runtergeladen, passt auf die installierte MySQL-Version.)




So was überfordert mich dann schon...

 

[gex]

lass dir sonst mal den querystring ausgeben, und fange die exception nicht so trostlos ab, sondern gib die exception mal aus, zumindest solange du an diesem problem sitzt.

 

[MichiM]

Alles natürlich probiert, es wird beim Schreibzugriff keine Exception geschmissen, grad nochmal probiert. "Dennoch" besteht ein Zusammenhang zwischen Schreibzugriff und abgetrenntem HTML-Code. Mystisch...

Gibts irgendeine Eigenschaft bei den Metadaten, die hier eine Rolle spielen könnte? (Wird vielleicht zu viel Speicher für
den Datenbankzugriff reserviert, dass der Tomcat nachher Platzprobleme bekommt...?)

Was bedeutet allerdings das, zu finden im Log-File?

SCHWERWIEGEND: Servlet.service() for servlet jsp threw exception
java.lang.NullPointerException
at com.mysql.jdbc.ResultSet.buildIndexMapping(ResultSet.java:607)
at com.mysql.jdbc.ResultSet.findColumn(ResultSet.java:963)
at com.mysql.jdbc.ResultSet.getString(ResultSet.java:5584)
at org.apache.jsp.bearbeiten_jsp._jspService(bearbeiten_jsp.java:512)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:368)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)

 

[java_entwickler]

Hallo,
Welche Codierung hat Deine MySQL ? Die muss man bei Installation auswählen. Das Problem liegt , glaub ich, an der Codierung. Probiere : request.setCharacterEncoding() ...

 

[MichiM]

Die Tabelle ist mit latin1_german1_ci kodiert.

Habe testhalber mal

request.setCharacterEncoding ( "ISO-8859-1" );

eingefügt, keine weitere Reaktion.

Nachdem ich es wieder rausgenommen hab, erscheint auf einmal zur Abwechslung folgende Exception im Log-File: :roll:

2008 19:08:55 org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already.  Could not load java.net.BindException.  The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1238)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1198)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
	at com.mysql.jdbc.CommunicationsException.<init>(CommunicationsException.java:161)
	at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:2759)
	at com.mysql.jdbc.MysqlIO.quit(MysqlIO.java:1410)
	at com.mysql.jdbc.Connection.realClose(Connection.java:4947)
	at com.mysql.jdbc.Connection.cleanup(Connection.java:2063)
	at com.mysql.jdbc.Connection.finalize(Connection.java:3403)
	at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
	at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
	at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)

Anwendung schon vor dem Schließen der Datenbank beendet, was will er mir damit sagen...?

Ist der Tomcat nicht so gut geeignet für Datenbankanwendungen oder was soll das jetzt alles auf einmal...? :lol:

Bisher gabs eigentlich keinen nennenswerten Probleme, aber als die Datenbank ins Spiel kam, wurde es mysteriös. :wink:

(Den MySQL-Treiber hab ich von hier: http://www.mysql.com/products/connector/j/ )

 

[ms]

Ich hatte auch mal so ein Problem aufgrund von mangelndem Festplattenplatz.
Es konnte kein Logfile geschrieben werden.

ms