WEB-INF/lib problems

[Dan Connelly]

I am new here, and new J2EE deployment issues.  Forgive me if these observations are naive.   I gather from recent complaints on this list that deployment of struts WARs into J2EE environments (with the WARs packaged into EAR files) is not working as expected.  The struts.jar isn't getting cpath'ed from the demo apps WEB-INF/lib at deployment time, or gets put in some sub-directory of WEB-INF/lib, where it is not found.  But, the struts demos do work OK on stand-alone Tomcat (if you use Xerces and avoid JAXP).     One workaround people try is to put struts.jar into the j2ee server's CLASSPATH, but this is a bad idea because j2ee is an "embedded environment", ie, a total platform into which apps are installed dynamically.  Anyway, juking the CLASSPATH just causes other problems (in "example" for example).   (Rough summary of various threads.)   I am seeing this too. I my case the problems are on the freebee j2eesdk1.2.1 server that I downloaded from Sun.  This may be related to the WL and iPlanet problems that others have reported.  (Except that you paid good money for that software and you are getting excellent support from your vendor, right?  No annoyance issues, right?)   The Sun Bug Report I have posted below seems relevant to these problems.  I kept thinking that Sun must know about (and would quickly fix ??) such an obvious problem in their own SDK implementation.  So I kept searching their site for such a fix.  Apparently not.  Perhaps deadlines are tight at Sun.   Anyway, .....   This particular Bug Report is quite old and is listed as closed.  But, skeptic that I am, I am not convinced that it was fixed anywhere but on Tomcat.   And it could be that various commercial implementations of j2ee (inlcuding the Sun "reference") employed workarounds for this bug, which ended up as regressions.   Also, what does "javaxservlet:api 3.0beta" mean in this context, given that the latest Servlet API I know of is Release 2.3.     Dan Connelly  (who is not Dan Connolly, W3C, but likes his ideas anyway)           Bug Id 4282385 Votes 0 Synopsis ServletLoader cannot load jars from WEB-INF/lib directory. Category javaxservlet:api Reported Against 1.1beta Release Fixed 3.0beta State Closed, fixed Related Bugs   Submit Date Oct 18, 1999 Description jcheck tests are failing with both tomcat and j2ee. You did not see it fail when running under tomcat because moo.jar is in the classpath when you started tomcat web-server. So, the tomcat server found all the classes. But on J2EE, (where there is no classpath related issues) you saw all of them fail because the ServletLoader is unable to load up classes. Here is the problem with the ServletLoader as it exists today: It can load classes from the WEB-INF/classes and WEB-INF/lib directories but it *cannot* load *jars* from the WEB-INF/lib directory. I am going to file a bug against the tomcat implementation. Meanwhile, I have a suggestion to whoever is responsible for jcheck. Please *do not* start the tomcat server with any more classes than whats required. Can you or anyone else in your team remove moo.jar from the classpath? Workaround None. Evaluation in an embedded environment (ie j2ee) and for war docbases tomcat was not able to access WEB-INF/lib/*jar classes due to the fact that the war protocol handler registration moved from server package to the optional shell package and thusly was not made available to the hosting environment. the fix involved modifying the protocol handler to manage both war and jar uri's alike and update the ServletLoader to generate "jar" uri references (vs war uri references) so that for environments which have a specified war protocol handler (eg tomcat/jdk1.1.x) will get work as well as environments which which run on jdk1.2.x where JarUrlConnection is natively available. cool fix. xxxxx@xxxxx 1999-10-28