-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/10/2014 12:35 PM, André Warnier wrote: > Mark Eggers wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 6/10/2014 8:29 AM, André Warnier wrote: >>> André Warnier wrote: >>>> Martin Stolk wrote: >>>>> >>>>> Hello, >>>>> >>>>> We are migrating our applications from tomcat to wildfly. >>>>> We are using mod_= jk (1.2.40) to connect apache to the >>>>> wildfly ajp port. >>>>> >>>>> When using tomcat there are no problems, but with wilfdly >>>>> there is a strang= e behavior in our application. >>>> It is a bit of a puzzle then, why you are asking for help >>>> here. Would "http://wildfly.org/gethelp/"; not be a better >>>> place to start ? >>>> >>>>> Our application is written in java (wicket) and when >>>>> entering a search form= every field fills with a semi-colon >>>>> after entering the find button. When i= set the JkLogLevel >>>>> to trace or debug the problems remains but less frequen= >>>>> tly and not in every form. I also tried different >>>>> ForwardURI** JkOptions, but that make no difference. >>>> I can't think of a reason off-hand why this should ever make >>>> any difference. It would seem that the first thing to look >>>> at, is what this "Find" button in the form really does. Is >>>> it just a "submit" button, or does it call something (some >>>> javascript perhaps) ? Does the <form> send a POST, or a GET >>>> request ? >>>> >>>>> Can anyone help me where to find a solution? >>>>> >>> Ok, I'll bite again. As I understand the issue, you have the >>> following schema : >>> >>> B + BA <-HTTP-> A + M <-AJP-> E + EA >>> >>> where : >>> >>> - B is the browser - BA is the "application" in the browser. >>> That can be pure HTML, or HTML + javascript, or a Java Applet, >>> or whatever - A is the Apache httpd front-end - M is the >>> mod_jk module running inside Apache httpd - E is the Servlet >>> Engine (Tomcat or Wildfly) - EA is the java application running >>> inside of E >>> >>> and we assume that the only element which varies is E, which >>> is either Tomcat or Wildfly. >>> >>> You say that when E is Tomcat, everything works fine. But when >>> E is Wildfly, strange things happen. >>> >>> Given that B + BA are the same and would send the same HTTP >>> requests in both cases to A, - there is no reason why A would >>> do anything different when E is Wildfly, than when E is Tomcat. >>> A does not even know which Servlet Engine E is being used. - >>> there is no reason why M would do anything different when E is >>> Wildfly, than when E is Tomcat. M does not even know which >>> Servlet Engine E is being used. It just knows that it is >>> talking to an AJP connector of a webserver, and that it needs >>> to "translate" the HTTP request, to an AJP request, before >>> forwarding it. >>> >>> The only impact that I can think of, of changing the mod_jk >>> loglevel, is to make mod_jk perhaps a little bit slower, >>> because it has to log more. (But we should be talking of at >>> most milliseconds here). >>> >>> So, on the face of it, logically, I would think that if there >>> is a problem when E is Wildfly, the problem must be with >>> Wildfly, or with how Wildfly is running the EA application. >>> >>> Or else, our premise is wrong, and BA is not exactly the same >>> in both cases, and does not send exactly the same thing to A. >>> But since BA "comes from" E + EA originally, that would also >>> mean that the problem is with Wildfly + the EA application. >>> >>> So I would still go to the Wildfly support list, present the >>> same case as you did above, and ask them if they have a clue as >>> to what may be happening. >> >> >> To extend André's excellent examination . . . . >> >> It would be nice if you could remove A + M from the equation. In >> other words: >> >> B + BA <-HTTP-> E + EA >> >> Then vary E (Wildfly or Tomcat). >> >> If both work, then the issue might be with Firefly's AJP >> configuration (or its AJP implementation). >> >> If Firefly does not work, then the issue might be with Firefly's >> configuration (or Firefly and Wicket). >> >> If neither work, then that's a puzzle. >> >> . . . . just my (coffee-less) 2 cents > > Now wait, Firefly ? Is that linked to the coffee-less state ?
No, probably too much Netflix. Wildfly it is. . . . 2 cents now with more coffee /mde/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTl2BDAAoJEEFGbsYNeTwtQQEIAKVkJDQ4BDSsijLIxzQLX98B 5bGLcWQr794euBMiCh/6sVqD5PjNPwHhKYcbaGRl+GMauLFxvPikODVqQD+y9C+8 k5ZrAbC+nXTQxsNDY8NvzphHLApHjrJIRzHUBRDNDP+0ptgMBKCA46kkWAvq8eXZ WRsHQ0LvffV9U+yXkA3+gbJgHB0w9YuCz+7nvaCzW9nH2CyRpaxZgY1B2NqBwnM5 Xca9XeosQWBgfIkS3HQz6csyZT/7aAPoTED5fq/+vMtmN2nw13rNSxIZklCL8Qwq xcMjtNSsNuyqmPofa75aczDZc/iJ8yYuYSRNGPn4Yoa5GNmzOmEiBDV5nen/0WI= =4QYn -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
