On Wed, 20 Nov 2002, Glenn O wrote:
> Date: Wed, 20 Nov 2002 17:05:23 -0800 > From: Glenn O <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > Subject: Re: SOAP: Unable to resolve target object > > Craig R. McClanahan wrote: > > > > > > > Is anybody else using SOAP and tomcat 4? If so, have you run into a need to > > > share classes across contexts, and if so, how did you do it? I'd like to > > > improve on my copy-on-startup approach. > > > > > > > In general, it's really easy to share classes across webapps -- simply put > > them in a JAR in the $CATALINA_HOME/common/lib subdirectory. This is > > documented on the general discussion of how class loading works in Tomcat: > > > > http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html > > > > The only potential complexity is if such a shared class tries to load a > > class that is in the webapp's /WEB-INF/classes or /WEB-INF/lib directory > > ...which is exactly the case I'm describing. > > > > -- this will not be possible unless the shared class takes special > > measures to use the thread context class loader. > > Yes, but we're talking about SOAP, so I'd prefer not to customize it. > > In large scale apps I believe there is a need for .war-deployable > shared classes. Perhaps it could be accomplished with nested webapps? > Just something for you to think about for a future version. Loading classes not under /WEB-INF/classes or /WEB-INF/lib into the web app class loader would violate the servlet specification, and make any application relying on it hopelessly unportable. Architecting a solution to this at the container level isn't going to be trivially solved, even in a future specification version. The problem is the fundamental nature of class loaders in Java -- they have links to their parents (that's why class loader delegation can work) but not their children. The currently architected solution to this problem, which works already in today's app servers, is the thread context class loader. Therefore, I have a hard time seeing much urgency for making a change like this, or a need to invest the effort in designing, building, and testing solutions that implement it. <soapbox> Of course, I also feel that ***way*** too many Tomcat developers and users put ***way*** too much stock in sharing JAR files, giving up the notion that a webapp is a stand-alone deployable unit. Among other things, that means your webapps *must* share the same version of the JAR, and be updated at the same time -- if you follow the design practices recommended by the servlet and J2EE specs (put your library jars in the webapp), you have complete freedom to update webapp A to a patched version of the library, without forcing webapp's B and C to change at the same time). "But wait ... that means I have to manage multiple copies of the same file". Yep, and so what? A few lines added to your Ant or shell scripts that deploy apps takes care of that once and for all. Not a compelling argument for me. "But wait ... that means there will be multiple copies of these classes in memory." True, and that's probably a little more compelling, until I remember that I just upgraded my desktop PC from 256mb to 1gb for under $200 ... nah, it's not an important enough issue for me to give up the advantages of independently deployable self-contained WAR files. </soapbox> > > - Glenn > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
