Well, first, to be clear: NO, you CANNOT manually update Tomcat. Adobe bundles Tomcat under CF in a very customized way, and this is why we (using CF) have had to WAIT until this update for it to fix the problem that Tomcat 9.0.21 was said to fix (the ghostcat issue, mentioned in my blog post).
Second, I appreciate that you are finding this all very frustrating (and this is where most people would be cursing Adobe and CF, and panting for when they could get off of it). But I will tell you that I help with such frustrating problems daily, and there is always a solution. It is RARELY a "bug", and often not at all "Adobe's fault". I appreciate you are not saying that here. I'm just ranting a bit--and planting a seed for readers (and perhaps you, if it continues).
So, third, if I was sitting with you (providing remote consulting, trying to figure this out), I would be wanting double-check all you said. (It's so easy for httdp.conf files, and the files they include, and so on, to get very nested and hard to easily interpret. Consider that there are settings for all of Tomcat, then can be some set for a virtual host.)
And you may have more than one vhost, so tell us this: do you have more than one site? are ANY of your sites working?
If you have only one, then here's what I'd do next, to PROVE that the mod_jk.so that you say is "updated" is indeed the one that Tomcat's conf files are pointing to: rename it, and restart Apache. If you do, then do the requests which PREVIOUSLY worked (files that DO exist DO work, you said) still work? If they do, then clearly they are NOT using THAT connector (which you renamed), as Tomcat would not be able to find and load it. And that will tell us that you have some OTHER one that Tomcat is using.
Finding which it is using, again, will be challenging. One thing you can do is grep for that mod_jk.so file, to find any (in all folders on the server) that may exist, and then if there are not too many, try renaming them one at a time, and restarting Apache, and running the test (both tests). As you find that such a rename "does nothing", don't forget to rename the file BACK (including the first one renamed above).
There HAS to be an explanation. I am suspecting it's going to be that some combination of factors has you, Apache, and CF looking at some wrong combination of files, which explains where that Tomcat 8 reference in the error is coming from.
Let us know how that goes. Or if you decide not to, in which case I guess you can wait to see if someone has a better answer. It's not likely that Adobe will respond here. They generally do not (but occasionally do). You could ask for help from Adobe on the update blog post (that I point to in my blog post). I would NOT go into great detail there, but instead I would point them to this thread, so that they can read all you and I have offered, in case they may think of something else.
But I really would STRONGLY recommend you not do that until you have tried what I propose above. I really do think that sort of "process of elimination" is going to help you find where the problem/confusion is.
Once you find it, then you can focus on how it happened, and whether you may want to change things so that it does not happen again. (Indeed, it may be that you have been "upgrading" your CF web connector for a couple of years, thinking it was "working", when it is not.)
In fact, I just thought of one more thing you can consider: in that mod_jk.log you referred to originally, there should be a line whenever Apache restarts, reporting the connector version. In Windows, it's something like "Starting Tomcat/ISAPI/isapi_redirector/1.2.46". I don't have a Linux install readily available to check, but from looking around it may look like " mod_jk/1.2.46 initialized". The key question is what version number is that reporting for you? (I have found that it's NOT changed with this latest update, at least on Windows. But it may be that some process Adobe uses is not changing it always.)
My point is to see if yours is a very different reported version number, earlier than that. If it is, then it supports my contention above, and justifies all the more doing that process of elimination to find WHERE that connector is that Apache is using.
Let us know how it goes.
/Charlie (troubleshooter, carehart.org)
1 Correct answer
14
Replies
AdChoices