https://issues.apache.org/bugzilla/show_bug.cgi?id=47121
--- Comment #7 from Guenter Knauf <efl...@gmx.net> 2009-05-25 11:32:48 PST --- Hi Vladimir, (In reply to comment #6) > I do not believe it matters which specific .NCFs I used as long as Apache and > Mod_JK were unloaded in all Address Spaces and they were. In fact it does: you use something which sounds for restarting - but if you try a restart, and Apache is not loaded (because you stopped it) then the shutdown command starts Apache instead of shutting down, and the following load command gives you then the 'already loaded' - makes sense? Therefore please use only the NCFs I suggested, even if these need two steps: first a down followed by an up; anyway you cant do a restart since you intent to load a new build of a module. > I unloaded Tomcat as well just to be on the safe side. > Next time I can skip that step. correct, not needed. > Before I go ahead and run the same experiment again can you please confirm > that > you noticed the difference in 2 IF statements. yes, and I explained in detail how it works. Please re-read my last comment where I stated that the block in QFTomcatConnector.conf only is active when mod_jk is _NOT_ loaded. > Condition checked is the opposite. Shouldn't it be the same? No, and I explain again. In httpd.conf you can find: # The following line instructs Apache to load the jk module LoadModule jk_module modules/mod_jk.nlm <IfModule mod_jk.c> JkWorkersFile "sys:/adminsrv/conf/mod_jk/workers.properties" JkLogFile "logs/mod_jk.log" JkLogLevel error </IfModule> that means: mod_jk gets unconditionally loaded, and the following block gets conditionally active when mod_jk is loaded. In QFTomcatConnector.conf you have: <IfModule !mod_jk.c> LoadModule jk_module modules/mod_jk.nlm JkWorkersFile "sys:/adminsrv/conf/mod_jk/workers.properties" JkLogFile "logs/mod_jk.log" JkLogLevel error </IfModule> that means: this block gets only active if mod_jk is _NOT_ already loaded, and is then loaded, and its config stuff is set. Now the problem is this: if QFTomcatConnector.conf is included in httpd.conf _BEFORE_ mod_jk gets loaded from httpd.conf then the whole block in QFTomcatConnector.conf gets active, and loads mod_jk + sets JkWorkersFile. Then a bit later comes the unconditional load of mod_jk from httpd.conf which just gets ignored by the Apache loader with 'module already loaded', then follows the mod_jk config block which conditionally gets active when mod_jk is loaded -- and at this time its loaded, and there then happens the second JkWorkersFile setting which then makes mod_jk refuse loading. Now if you just move the include of QFTomcatConnector.conf down _AFTER_ the mod_jk configure block everything is fine - then mod_jk is loaded already when QFTomcatConnector.conf is processed, and no second config happens. I agree that Novell's config is somewhat crazy, and even more worse is that they then dont care about the order things happen, and where to include QFTomcatConnector.conf from httpd.conf; though the change we did with mod_jk is fully correct - realize that with the old behaviour you would never get aware of a second JkWorkersFile usage, and if it would point to another file than the standard you would be lost. Feel free to open a bug report at Novell and tell them they should use same config block as what they use in QFTomcatConnector.conf - then it wouldnt matter if mod_jk gets loaded + configured either from QFTomcatConnector.conf, or from httpd.conf, and there would never happen a second configure; the first one would just win! Though I doubt it makes much sense to tell Novell for two reasons: 1.) I've heard that they stopped working on SP9, so anyway we probably dont get any updates anymore from Novell. 2.) The whole webservice stuff including mod_jk support is moved to Novell India, and asked Rainer and me last time for SP8 already about the new stuff with mod_jk later 1.2.23, and AFAICT they couldnt make sense of our replies - so they backported some patches so they could avoid later versions. Guenter. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
