Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 22822 invoked by uid 500); 19 Nov 2002 15:41:46 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 22807 invoked from network); 19 Nov 2002 15:41:45 -0000 Message-ID: <3DDA5B6B.9060502@apache.org> Date: Tue, 19 Nov 2002 16:40:27 +0100 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org Organization: Apache Software Foundation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Compiling with Servlet spec 2.3 classloading References: <3DDA58CD.4020508@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Stefano Mazzocchi wrote: > jakob.dalsgaard@neupart.dk wrote: > >> To the developers >> >> I've created a Pizza Compiler for Cocoon that uses the ClassLoader >> retrieved from ClassUtils.getClassLoader () instead of a classpath >> consisting of jar files and classes directories when compiling java >> files. I've posted a message in the Pizzacompiler discussion forum >> asking if the pizza developers want my code. >> >> I'm posting this message to the cocoon-dev mailing list to follow up >> on others earlier threads regarding compilers and classloading, for >> example: http://w6.metronet.com/~wjm/tomcat/2001/Feb/msg00488.html >> >> I'm deploying cocoon in a Jboss/Jetty environment; and I've turned off >> Java 2 ClassLoading in favour of Servlet Spec 2.3 ClassLoading. I >> might be wrong, but the general difference between them two is: >> >> - in Java 2 classloading, the parent classloader is always asked >> first, then a classloader tries to locate the class itself >> - in Servlet Spec 2.3 the webapp classloader tries to locate the class >> in WEB-INF/lib, WEB-INF/classes or, when deployed in an enterprise >> application, in the interfaces to the ejb-layer (which are not found >> in any files within the webapp). >> >> The beauty (IMHO) of Servlet Spec 2.3 class loading is that you get >> the Xalan/Xerces/whatever that you deploy with your application, and >> _not_ the Xalan/Xerces/whatever is delivered by the JDK or deploy >> environment - much less hazzle. With this classloading scheme I can >> take an arbitrary JDK and expect to get the proper classes loaded. I >> know there's the workaround with endorsed lib and such - but then I >> have to keep my JDK as up to date as my app. >> >> The problem with Servlet Spec 2.3 is that the compiler cannot get the >> interfaces in a neat .jar file and hence cannot load the classes. I've >> not been able to find any freely available java compiler that uses a >> ClassLoader when compiling. Therefore I've made a alternate version of >> the Pizzac java compiler class for cocoon that uses an alternate >> ClassReader class for Pizza. This combination seems to work. >> >> If there's interest in my solution I'll post the files to the list. > > > YEEEEEEESSSSSSSS!!!!!!! YEAH! :-D > You are my man, really. I love this. Stefano, you once said that probably you would have had to make your own compiler to get round this problem, so does this mean that you're not going to do it anymore? ;-) > Let's throw away normal class-path based classloading as soon as possible. > > THIS problem has been the major portability issue for cocoon on > different platforms (like early WebSphere or WebLogic, for example) for > dynamically compiled stuff (like sitemap in 2.0.x and XSP in all versions). > > Now, as much as I like this, I don't want Cocoon to maintain a forked > version of Pizza. Have you given back your patches to the pizza folks or > this is just your own personal release for it? > > In any case, we *really* need to incorporate this so we must find a > proper way. +1000 -- Nicola Ken Barozzi nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org