views:

72

answers:

2

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.

+1  A: 

Wow! Definitely a face-palm moment for you. :-(

Here's my stab at understanding it, and of course I could be quite wrong: at runtime Tomcat doesn't care necessarily what is at the same level on the filesystem as the application root, so long as it finds what it thinks is a valid WAR in the root. And it would make sense Tomcat would check to see if a given folder structure in a URL matches a webapp before looking to see if it's a folder IN a webapp. So that would explain the "new" app.

As for the original app, if it doesn't reference the "NewApp" folder at all, then Tomcat would have no reason to even look in there, and if it did it would ignore the fact it looks like a webapp. It's just another folder of files. I suspect you can probably access any file in there directly by hand-constructing a URL to it. Handy. :-p (Edit: probably not, thinking about it again, Tomcat would likely just take any 'NewApp' reference to mean the new app, not a file in the old app.)

So... you have two webapps. I think Tomcat will keep them separate. But... it would give me the heebie-jeebies to think I had something like that in production...

Rodney Gitzel
I'll vent for a while, read some replies, and come up with a plan to at least locate the problem's vicinity if not the actual problem.
Tony Ennis
+1  A: 

I echo what Rodney has said. Tomcat looks for WAR files and treats them as an individual webapp (I think...). In your case, as Rodney says, from Tomcat's point of view all you have there is a webapp that happens to have a folder with some class files in it.

What I suspect is happening is that NewApp has the same packages/class names as legacy, and therefore one is overwriting the other (as Tomcat is probably picking up the NewApp WEB-INF folder - I don't quite understand how but there you go).

This isn't what you or your company wants to hear, but they should never have been bundled together as two separate apps. If NewApp depends on Legacy, then you could have JAR'd up the required code from Legacy and included it as a dependency for NewApp. But as you have it now, they should be separate, and I would say that Tomcat is getting pretty confused.

But maybe someone else has a way to solve it as it exists right now... but I'd be surprised to be honest.

Ben J
Jar'ed up? hahahahahahah. **cough** ok. NewApp doesn't depend upon Legacy, or vise-versa. They just sort of slammed them together!
Tony Ennis
Ahh sorry, they aren't interdependent? I'm not sure where I got that idea from then :P
Ben J
You probably got the idea because one is embedded in the other!
Tony Ennis