tomcat can't see beans

i have recently been working on a tomcat 4.0.4 install, and to get my beans to work i had to include the name of the bean class in the "import" directive at the top of the page. i thought this was odd at the time, as no examples i've seen did this, but it worked.

now i have tomcat 4.1.10 (enforced by the deployment environment) and it complains about me trying to import the bean classes (it asks for a period, presumably because it expects me to be importing a package). So i remove the import of the bean class, but then i get "can't resolve symbol" errors when i try to use the bean.

my web app has its context set in server.xml, there's a WEB-INF folder with classes and lib folders within it, and my compiled .class files live in the classes folder.

I think you'll agree, this has "classpath problem" written all over it, but i thought tomcat automatically looked in WEB-INF/classes without it being configured anywhere.

Can anyone help me help my tomcat find its beans?

[my java environment is 1.4.0, my OS is RH7.3]

Simplest method: put them in a package.

It's not hard, and it will save you no end of headaches.

Say your package is com.devshed.funky.beans.

Create a folder structure like: WEB-INF/classes/com/devshed/funky/beans, and put all your beans in there.

Then the first (non-comment) line in each of your beans needs to be package com.devshed.funky.beans;.

It really causes headaches when everything is in the default package. I think that's because your jsps are in the org.apache.jasper package (I think), and so it looks for your beans in the same package (or something like that).

many thanks, bricker42/james, worked a treat.

this is not the first time you have come to my aid... much appreciated.

what gets me is why it didn't work with vanilla classes in the 'classes' folder - all the docs say to just throw them in there, so i did... is this a bug in that version of tomcat, or is it the same with more recent versions? someone needs to get to the bottom of this.

<rant>
i'm getting cheesed off with java/jsp etc - it just doesn't live up to the much vaunted "write once, run anywhere" description. we're trying to deploy my app and are running up against all sorts of problems with versioning, security etc. i guess it's partly my novicedom, but i am seriously thinking about crawling back to my PHP world and never venturing into Java land again.
</rant>

Ya, versioning can be a real pain with java.

I suppose it wouldn't be too much different with php, though. Don't develop for 4.2 and deploy with 4.0.6 .

having calmed down, i realise it's just a familiarity thing. like, i can reel off that the PHP superglobals came along at 4.1.0 and that register globals defaulted to off at 4.2.0, and that nothing worked in PHP3 ( ! ), but i'm not so proficient in java land.

that said, i did my docs for my app, which had to describe the development enviroment, and when i'd finished, i realised that i'd given versions for (wait for it): apache, mod_jk, j2sdk, mysql, mm.mysql, tomcat.

surely there has to be a better way...!

I'm surprised you didn't need to specify a version for j2ee.

And if you really wanted to, you could cut apache and mod_jk out of your app (probably), then it would closer to php. The only difference would be the jdbc driver.

One nice thing with java is that you can package your app into a .war file, which makes installing it on a new system WAY easier.

j2sdk -> j2se

i couldn't spot the difference/additional benefit between .war files and the expanded structure - is there any?

the jdbc driver was a sticking point - the server had an app running on mm.mysql version 1.2! the craziest thing is that this app has just been developed! i think we're gonna keep the 1.2 driver for the other app and sling my 2.0.10 (or maybe 2.0.14) into the WEB-INF/lib folder of my app so that we have the best of both worlds....

...and we did decide to cut apache and mod_jk out of the equation!

i guess i've learnt something for the next time: get the entire versioning of the deployment environment signed off before dev work begins...

The advantage of .war files is for distribution, really. They're easier to install than a .jar or .zip archive (since the app server handles the unpacking).

I just think that's a more convenient way of distributing an application to a different server.