Not sure if I'm reading you right, or whether it is a typo. Shouldn't your Controller code be in Controller.class, not controller.class? You have declared that the servlet is com.foo.webapp.Controller, yet you state that the class is com/foo/webapp/controller.class.
I did a check this morning. I had a typo in the post.
The XML and the class name matches perfectly and
am still getting an error.
Which servlet container are you using? Jetty or Tomcat? The other thing to try is to unpack your servlet classes into the class directory and see if that has any effect.
We usually have our servlets in the class subdirectory as they are normally in a packed WAR file and have support libraries in the lib subdirectory.
Haven't heard of this problem though so will be interested in the outcome. If you have a standalone version of the servlet container, you could try on that to see if it is JBoss induced or a natural operation of the servlet container - based on your results in the previous test.
I maybe reading you wrong but you dont have a load-on-startup for your controller and your post indicates that you get a classnotfound on "deploy"?
Can you check if all the classes that referenced by the Controller class are also loaded
i finally found out what the problem was.
In trying to simplify what's being posted i inadvertently took away the problem.
The jar file inside the WEB-INF/lib is named
hs-custom.jar instead of just custom.jar as i have
seems that the problem is somewhere in the
characters (hs-). I ended up renaming the jar
to hs_custom.jar and it works fine.
anyway, is this a bug? a caveat? or feature of Jboss?
No. i take that back. ignore my last post. It's still not working
I can't help you, but I can confirm the problem. I have some servlet code in a jar called evp.jar, located under WEB-INF/lib. That code makes calls on code contained by another jar, jtapi.jar, also located in the WEB-INF/lib directory. Everything works fine when I run the servlet, until it attempts to instantiate an object of a class defined in jtapi.jar. Then it blows up, and I get exceptions in the JBoss standard-out window.
The only way I found to fix the problem was to actually unpack the jtapi.jar and include the files when I build the evp.jar. It stinks, but it works.
I did, by the way, see if I could reproduce the problem by creating a do-nothing class and putting it in it's own jar under WEB-INF. When my servlet tries to instantiate an object of that class... same problem. So, it's not the jar file itself, or the name. Something else is going on.
I am using the integrated jboss-3.2.0_tomcat-4.1.24, and JRE 1.4.1_2-b06 on W2K. I should note, that the WAR is deployed as part of an EAR. I have found no other problems with the deployment.
OK. I've just tried with one of my simple projects. I've got a WAP servlet page rendered through the OpenWave OUI and it is calling an EJB, whose interface code (client stubs) are in another jar in WEB-INF/lib. The servlets are placed in a jar, servlets.jar and stored in WEB-INF/lib. The client stubs are in products-client.jar.
No problem. Also tried calling the servlets archive mervlets.jar just in case there was any name precedence for loading. No issue there either.
My env: Win2K, JDKI 1.4.1_01, JBoss/Tomcat (standard 3.2.0 bin dist)
So let's recap. The situations are:
1) No class found on deploy when servlets are in a JAR
2) OK when servlet classes are unpacked into WEB-INF/classes
1) No class found on execution when servlets are in a JAR
2) OK when servlet classes are unpacked into WEB-INF/classes
If there are external dependencies for the servlets, are there also dependencies that these support classes have?
Just trying to locate any patterns in this. If anyone else has some suggestions ...
I ended up cleaning up all directories and started from
scratch. THe class loader problem seems to go away now.
I had a few instances where i kill JBoss during startup
and it left some 1/2 deployed Jetty directory in the
work dir. Not sure if that was causing some of the problem or not.
One thing i did notice though:
I have Controller servlet inside WEB-INF/lib/custom.jar which extended a based servlet in side another jar that is located in the classpath.
The class loader from BEA seems to work fine but not
in JBoss/Jetty. I think this could be BEA's extension.
Thanks to all who replied.
I would only add that like someone else said, put your servlet code in the WEB-INF/classes dir. The .war file is already compressed, no reason to put it in the .jar file. Ideally the /lib dir is used for 3rd party support classes. Anything you can compile should always go in the /WEB-INF/classes dir.
Also, why are you compiling your jsp pages to the /classes dir? Can't you just leave the jsp pages in the web root (and sub-dirs) outside of the /web-inf dir? I can understand about pre-compiling them, and I think you can have jetty pre-compile all jsp pages when a web-app is deployed. I have never heard of putting the compiled classes in the web-inf/classes folder. Doesn't this possibly break the ability to (at least in development) modify a .jsp page and watch it get automatically recompiled so you see your results right away?
Also, as per another post, if you have one .jar file class use another class from another .jar file, and they are both in web-inf/lib, this will work fine. But as another reply said to that post, if the second .jar file class depends on yet another class that is not in the classpath of the web-app, you will see problems. Much like if you try to run a java main() class and the class the main() method is in depends on (imports) another class that is not added to the classpath when running the main() class, you will usually get ClassDefNotFound or something like that. Even though your code looks fine, and it compiles, at runtime (or in the case of web, deploy time), if its not in the runtime path, it wont work.
>>I would only add that like someone else said, put
>>your servlet code in the WEB-INF/classes dir.
>>The .war file is already compressed, no reason to
>>put it in the .jar file. Ideally the /lib dir is used for
>>3rd party support classes. Anything you can
>>compile should always go in the /WEB-INF/classes
We have one 3rd party jar that we don't have source code so there it goes into /lib. THe other option is
to unjar the 3rd party and rejar it inder WEB-INF/classes which is just as bad as far as maintenance
>> Also, why are you compiling your jsp pages to >>the /classes dir?
we don't want to allow compiling during production deployment. dev deployment uses a different build
path which does allow recompiling.
in Prod, we don't even want to have jetty compiling during startup either.
I am getting the same.
I am running JBoss-3.0.6 and Jetty (Not sure of the version but part of the bundled download) JDK 1.3.1_04.
Have a war file with all my servlets in a jar and a 3rd party jar in WEB-INF\lib.
This same structure worked in 3.0.0 but now I am unable to see any classes in the third party jar. Servlet starts ok though.
I agree un jaring the 3rd party is not ideal but I have resorted to adding the jar to default\lib.
I have had some issues with the lib directory. While my memory fails to keep the details(I think it had to do with struts), I did have a work around. Our production environment has an ear/war packaging scheme with all the pertinent jars at the ear directory(struts, commons-*.jar, etc) and our application having a "Class-path: struts.jar" entry in the war/MET-INF/MANIFEST.MF. Unless your developing using ears, I don't think this structure will work with direct deployment to the deploy directory.
While I'd prefer to have struts.jar in the war, allowing multiple wars with different versions of struts. This work around has been sufficient, for now...
I'd still like to get the correct functionality(ear/war/WI/lib). I'll play with a few simple scenario today and see what works and what doesn't and post some results.
I checked on both 3.2+tomcat and 3.0.4+jetty and it seems my environment works just fine.
I have an ear+war with a custom JSPServlet that exists in the WEB-INF/lib directory. This JSPServlet was deployed in both the lib directory and the classes directory,exclusively. I was sorry, but pleased, to see that it works fine. Both the classes/lib have access to each other and are accessing the rest of the ear via a "Classpath: " reference.
I'm a believer!
I saw my big flaw.. I had my custom JSPServlet in a higher classloader(ear) and was being asked to reference something lower in the heirarchy(war)...
Perhaps that is happening with your environment as well. Can you think of anything that exists in the jboss/lib, jboss/server/default/lib, deploy/ directories that your WAR is accessing that may cause issues?