The problem was a duplicate worker entry. Apparently, in JK2, duplicates were ignored. I've written a perl script that converts the JK2 config to a JK1 config because of the large number of entries- I'll just need to have it validate that there are no duplicate workers.
Jk1 should probably handle this failure mode a little different- like with a 'duplicate worker' message/test. If it were as easy as a global search and replace on a single system, then I'd have no problem doing it. If I were at liberty to go into the details of all the impacts such a simple change causes at a megacorporation, you'd understand why its such a big deal. Its a huge/costly chain of events. Lets just say I'd be writing patches for Apache httpd long before we'd make such a change across all the servers because the overall cost per change is far less. Imagine coordinating 20 or more teams to test hundreds of applications because of strict change control procedures. Substituting the value in all of the files is the easy part... Thanks for the responses though. Is there a separate mailing list for jk1 development where I should post the suggestion to add a simple test/error message when parsing a duplicate worker? Byron -----Original Message----- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 20, 2005 12:20 PM To: Tomcat Users List Subject: Re: jk 1.2.10 + apache 1.3 issue Guernsey, Byron (GE Consumer & Industrial) wrote: > worked just fine under Apache 2 and we haven't seen any issues in the > JK1 code or cookies with respect to the ':' in the JVM Routes. To you > it might seem easier to change the jvmRoute, but unfortunately there > are literally 100's of production app servers that would need changed > and restarted. Well, there are users unlike you that do not allow cookies, so the colon in uri is invalid and needs to be encoded. Also I can give you few links to the editors that can do search and replace in multiple files at once ;). Also, just mail your workers.properties and httpd.conf. It would be much easier then guessing I suppose. If this is confidential data, then, well ... Regards, Mladen. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
