I apologize for the crummy subject line.
I started at a new company last week and was thrown into the lion's den immediately. We had a application on the verge of going into production... One of my guys had the app running and QA'ed so I didn't delve too much into the details of what he was doing.
We had this:
../legacy/ROOT/
..............index.jsp
..............WEB-INF/
.....................lib/
.........................(libs)
.....................classes/
............................x.class
There's a virtual host in conf/server.xml that defined the root as ROOT.
The new application seems to have started as a copy/paste of the legacy app. It has no entry in server.xml. It piggybacks, so to speak, on the legacy app even though it is wholly separate. The new application is rooted at legacy/ROOT/NewApp:
../legacy/ROOT/
..............index.jsp
..............WEB-INF/
.....................lib/
........................(libs)
.....................classes/
............................x.class
..............NewApp/
....................index.jsp
....................WEB-INF/
...........................lib/
..............................(libs)
...........................classes/
..................................x.class
To get to the legacy app, you browse to http://theUrl. To get to NewApp, you browse to http://theUrl/NewApp. That all works fine. Maybe.
We installed the new application on Saturday night. Monday morning, we find that while NewApp works great, our users can't log in to the legacy site. They get an application-generated 'bad username' error.
It occurs to me I don't know why NewApp works at all. I did not change web.xml. So I surmise that Tomcat finds a URL it likes by looking at the HOST definitions, then sees /NewApp in the URL and is happy to traverse into the legacy/ROOT/NewApp sub-directory where it finds an index.jsp and we're off to the races.
Now I get very confused. The legacy code has a WEB-INF folder, and NewApp/WEB-INF also exists. I don't know why Tomcat is doing anything with the NewApp/WEB-INF. Yet it is because NewApp works great. To make matters worse, the libs and and class files in both apps are nearly identical in name and content. The x.class file in NewApp is slightly different than the one in legacy - NewApp has a new login method. NewApp's x.class still has the old login method in it, however, though nothing in NewApp uses it.
I'm trying to determine how legacy's failure is related to our deployment. It must be - but it's hard to see how. We checked file dates. Nothing in legacy has been changed. I'm thinking it's a classpath issue somehow.
So, do I have one application here, or two? I thought it was the latter. But I'm not so sure. I'm so confused I can't even ask a good question :-/
The only other oddity was that Tomcat didn't explode the WAR file though the configuration looked like it should have. We had to do it by hand - and it worked.
This is what happens when your lead developer says, "3 months" and management says, "No, 1 month." It's a credit it works at all.