INFO: Starting Coyote AJP/1.3 on ajp-8009Ħ:54:52 PM .Catalina startĦ:55:00 PM .ApplicationContext log INFO: Initializing Coyote AJP/1.3 on ajp-8009Ħ:54:52 PM .AjpAprProtocol start INFO: Starting Coyote HTTP/1.1 on http-8080Ħ:54:52 PM .AjpAprProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080Ħ:54:52 PM 11.Http11AprProtocol start INFO: Deploying configuration descriptor ROOT.xml from / var/lib/tomcat/conf/Catalina/localhostĦ:54:52 PM 11.Http11AprProtocol init INFO: Deploying configuration descriptor hudson.xml from / var/lib/tomcat/conf/Catalina/localhostĦ:54:52 PM .HostConfig deployDescriptor INFO: Deploying configuration descriptor manager.xml from / var/lib/tomcat/conf/Catalina/localhost INFO: Starting Servlet Engine: Apache Tomcat/7.0.0-RC4Ħ:54:51 PM .HostConfig deployDescriptor Ħ:54:51 PM .Catalina loadĦ:54:51 PM .StandardService startInternalĦ:54:51 PM .StandardEngine startInternal INFO: APR capabilities: IPv6, sendfile, accept filters, random. INFO: Loaded APR based Apache Tomcat Native library 1.1.20. I still don't know why this is done at all and also where this happens.6:54:51 PM .AprLifecycleListener init I'm still thinking that an even better solution (better than changing the max http header size) would be to prevent the post paramter (that base64 encoded xml response) being attached as a GET parameter to the URL that is written to the header. Sorry, I really appreciate your help and would love to prove that changing the max http header size prevents the array index out of bound but I guess my limited knowledge to circumvent the problems describes above (and limited project time) defeats me. Maybe this is realted to this ticket in Jboss 7.1.1: cannot be cast to .XMLSignatureFactory: : #: . cannot be cast to .XMLSignatureFactory
TOMCAT BUGZILLA HOW TO
There is a workaround described in that thread and also a wiki article on how to overcome this: There seems to be class loading problems in Jboss 7.1.1 and the bundled version of picketlink 2.0.2 which are described in this forum thread: Unfortunately I can't get the Jboss 7.1.1 version to work (with picketlink - which I need for the SAML authentication). I know this is not all jbossweb related but maybe you have an idea as to where you would start solving this? And after all this the one thread will always respond with "thread is already associated with a transaction.".
The ArrayIndexOutOfBoundsException seems to break the transaction handling as the transaction is not rolled back. This one parameter is the complete base64 encoded XML-Respone which is too big and therefore breaks the max header size and this results to the ArrayIndexOutOfBoundsException.Īnother effect is that (as a dependency of the jboss security artefact) jboss seam is included and this alone starts seam transaction handling for incoming http requests. (I neither know where this happens nor why this happens at all).
TOMCAT BUGZILLA CODE
In my special case the jboss security code throws an InvalidRequestException and packs this into a RuntimeException (which is ok, because there is an error in the response).Īs there is no further handling of this RuntimeException the servlet container will handle it and tries to generate the standard 500 error page.įor a reason I don't know the one hidden value of the posted form is attached as a GET parameter to the URL and the URL is written into the http header to the attribute "location". Then the the jboss security code will handle this request. In the process of authentication the identity provider sends a html-form to the browser with one hidden value (which contains the xml-based authentication response) and javascript that posts the form automatically within an onload event to my Jboss app. I am using a SAML based authentication mechanism (with Jboss Security based on picketlink). Ok, if adding checks to avaoid this is useless, then maybe you have a hint on how this should be solved? I am currently facing this problem while a response is creating a way too big header which exceeds the maxHttpHeaderSize (I guess even by far).Ĭonsequently it throws an ArrayIndexOutOfBoundsException and later on seam transaction already in use exceptions - possibly as a result of the ArrayIndexOutOfBoundsException and an error in not rolling back the seam transaction when this happens.
Still I am not sure if this specific bug is supposed to be fixed in Jboss Web 7.0.10 (which is the version in Jboss AS 7.1.1 which I am using). I also found a mapping of what version of Jboss Web is contained in JBoss AS and what version of Tomcat Jboss Web is/was based on: Will this automatically be picked up for Jboss Web?Īs far as I understand parts of Jboss Web is still coming from Tomcat (even though it is a complete fork now). I believe I ran into a bug (using JBoss Version 7.1.1) that was possibly (according to this comment ) fixed in Tomcat 7.0.x:
0 kommentar(er)
