Can we keep class files in WEB-INF folder instead of copying entire war file in apache tomcat

[ranganath noonepally]

HI Experts,

We have a very old j2ee application developed using good old jsp and classes, and we deployed that to tomcat, now it has to be slightly modified, and i modified 2 classes and generated new .class files, can i directly copy the .class files into the webapps/WEB-INF folder, or do i need to take any extra precautions.

The reason i am doing this is when i rebuild the project with eclipse juno (exact version of eclipse Version: Juno Service Release 2 Build id: 20130225-0426), its giving me so many errors in jsp's like the below ones.

"ArrayList cannot be resolved to a type".

Can someone please help in clearing out the errors while building the project or let me know how to copy the class files.

Thanks,
Ran.

[Jeanne Boyarsky]

First, backup the entire directory in case this goes horribly wrong!

As a short term solution, you can copy the two class files. Make sure you compile into the same target version of Java as they were using. Since it is old, that is likely not Java 7 or 8!

In the long run, you should figure out how to build the war. Does the JSP have any imports in it? Such as <%@ page import="java.util.ArrayList" %>

[ranganath noonepally]

HI Jeanne,

thnaks for the suggestions, my directory structure is like /opt/vendor/tomcat/webapps/apppA/WEB-INF/classes and the classes are in the classes folder, i think i will backup the entire appA folder, and copy my 2 .class files into the classes directory.

And coming to the jsp errors while rebuilding, these jsp's are used as include in another jsp, they have the import statements, but when i rebuild i see lot of errors from these child jsp's.

It use to work before, but i rebooted my machine, may be some settings have been not configured now, as the setup before was done by java expert.

thanks,
ran.

[Jeanne Boyarsky]

One more question:
Is the JSP error just in Eclipse or do you get the error when running it? Eclipse often gives validation errors on old JSPs, it doesn't prevent them from running.

[ranganath noonepally]

It was just an eclipse error, but i haven't created a war file since January, back then i haven't seen these errors in eclipse back then, and i rebooted my machine in February, and then now i made some change and need to create a war file, and then to deploy, since it giving all these errors, my plan was to simply copy the only changed class files, and then restart tomcat to take that in effect.

[Tim Holloway]

Probably you should have asked this in the Tomcat forum.

Tomcat, like all good J2EE-compliant web application servers, works with WARs. Like many J2EE-compliant web application servers, Tomcat supports WARs in 2 formats:

1. "Real" WARs. Which is to say, ZIP files that conform to the J2EE spec for structure and content and have a ".war" filename extension.

2. "Exploded" WARs. An exploded WAR is the collection of files and directories that you get when you unZIP a WAR. The only difference being that instead of being in a ZIP file, they're discrete filesystem objects.

Fun fact: If you drop a WAR file into the TOMCAT_HOME/webapps directory, Tomcat will explode the WAR into a directory of the same name and deploy it. And if you later drop in a newer WAR file, Tomcat will ignore the newer WAR and continue to use the older exploded WAR.

If you copy files (your .class files, for example) into an exploded WAR directory tree, Tomcat will detect the changes and re-deploy the entire WAR on the fly. Tomcat does this by periodic scans, so it often takes a few seconds before it happens.

All of the above assumes that you're working with Tomcat in its out-of-the-box configuration. It's possible to modify Tomcat's behavior depending on what options you change.

You may consider that a dynamic re-deploy is risky, in which case, stop Tomcat, modify the exploded WAR, then restart it. You might also want to ZIP the exploded WAR and save the ZIP (.war) somewhere external to Tomcat in case you want a "permanent" archive. One of the risks that Tomcat versions 5 and up has when dynamic re-deploying is that not all of the old classes can be recovered, so Tomcat can potentially get blown to due to exhausted PermGen memory. Java 8 allegedly eliminates that problem, though.

Also, disclaimer: If you're using the Eclipse WTP plugin that comes bundled as part of the Eclipse J2EE spin, that plugin does some rather awful things to Tomcat configuration. I don't think that any of the numerous sins that it commits affects your problem, but for best results, try running Tomcat stand-alone.

[Prasad Krishnegowda]

Just a question.. Your project does not have a build system? You rely on Eclipse to generate a war file?

[Tim Holloway]

Prasad Krishnegowda wrote:Just a question.. Your project does not have a build system? You rely on Eclipse to generate a war file?

Many people do. I lost faith in IDEs as the sole means of generating production modules when I almost had to re-install an obsolete copy of Windows in order to install an obsolete copy of Visual Studio + patches in order to complie a 1-line change at an unholy hour of the morning.

I'm happy to let Eclipse help me, but these days I maintain a strict policy that the "official" build should be doable even on a machine with no GUI at all, using Ant, Maven, or whatever ("make" can be a bit unstable, though). Which, it turns out is now fashionable thanks to systems like Jenkins.

Still, like I said. A lot of people rely on their IDE to do the whole thing. And aside from the much greater potential for breakage between releases that IDEs have, IDEs are also often extremely customized by their users to the point where often I cannot build a project that the guy on the next desk owns even though I have all the "source code". In constrast, I could ship you just about any Maven-based project I have and you could build it even under some different OS on some other continent. And have, more than once. Not to you. To folks in Belarus, for example.

[Prasad Krishnegowda]

Thanks Tim, I didn't know still many rely on IDEs, as you said if something goes wrong, the project build goes for a toss.

[Tim Holloway]

IDEs are the Dream of the Pointy-Haired Boss.

Management gets the idea that if the IDE is intelligent enough, then they can hire ignorant monkeys for cheap to do the coding and the IDE will substitute for their lack of knowledge and experience.

This is distressingly common. And, I've no doubt a large part of why we've had so major meltdowns this past week.

[Bear Bibeault]

I'm with Tim. IDEs are for editing, not relying upon as project tools. I do my builds in either ant or grunt depending upon the project.