Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 13743 invoked from network); 14 Feb 2001 15:37:29 -0000 Received: from fw.infoplanning.net (HELO infoplanning.com) (@209.8.58.131) by h31.sny.collab.net with SMTP; 14 Feb 2001 15:37:29 -0000 Received: (qmail 5657 invoked from network); 14 Feb 2001 15:51:49 -0000 Received: from unknown (HELO apache.org) (192.168.0.189) by inet with SMTP; 14 Feb 2001 15:51:49 -0000 Message-ID: <3A8AA56C.E20B7AC8@apache.org> Date: Wed, 14 Feb 2001 10:34:04 -0500 From: Berin Loritsch X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: ClassLoading and Cocoon 2 References: <3A8A1A6B.2BBC2C3F@apache.org> <3A8A6CF4.FD9E032D@apache.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Stefano Mazzocchi wrote: > > [brought Craig into the discussion since he's the classloading guru > around here] > > Berin Loritsch wrote: > > > > Does anyone know how to selectively load classes from a parent ClassLoader? > > > > I recently made Cocoon live inside it's own ClassLoader. This is a good thing > > as it protects us from a myriad of issues with IBM WebSphere and other Servlet > > Containers that have wacky ClassLoaders. However, the one thing it does not > > protect us from is XML Parser conflicts. If we can resolve against the Servlet > > Engine's classes for things like javax.servlet.* and Enterprise applications, > > but not anything else, then we are just about there. > > I don't understand what you mean by parser conflicts in this case: if > Cocoon has its own classloader and delegates to the parent only when it > doesn't find its classes (just like Catalina does) there is no conflict. > What am I missing? Catalina is a Servlet 2.3 environment--where the ClassLoader is completely separate by specification. However, Cocoon 2 will be deployed in many Servlet 2.2 environments like WebSphere, WebLogic, JRun, ATG, Oracle, Tomcat 3.*, etc. The issue is that if any of those Servlet containters/app servers have a conflicting parser and JAXP implementation (like Tomcat 3.*, WebLogic, and WebSphere), Cocoon ends up using the incorrect one. Cocoon 2 requires a JAXP 1.1 compliant parser--which each of the afformentioned app servers only provide JAXP 1.0 at best. In order for this to work in a Servlet 2.2 environment that uses it's own parser, we need to explicitly separate Cocoon from the rest of the environment. > > > One way is to explicitly handle the Parent ClassLoader separately from the > > way the URLClassLoader handles it. In other words, it always checks in the > > current ClassLoader first (this does not seem to be happening), and then > > it checks in the parent ClassLoader. > > Yeah, I thought Catalina used this approach, isn't it Craig? That's probably the way we should go then. > Yuck. I vote for implementing a better classloader (even borrowing > Catalina's code if possible). Ok. I just need implementation details.