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 31191 invoked from network); 30 Jan 2001 20:58:10 -0000 Received: from rdu25-5-046.nc.rr.com (HELO akira.webslingerZ.com) (24.25.5.46) by h31.sny.collab.net with SMTP; 30 Jan 2001 20:58:10 -0000 Received: by akira.webslingerZ.com (Postfix, from userid 501) id E937A130A3; Tue, 30 Jan 2001 15:59:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by akira.webslingerZ.com (Postfix) with ESMTP id C6E4260B2; Tue, 30 Jan 2001 15:59:17 -0500 (EST) Date: Tue, 30 Jan 2001 15:59:17 -0500 (EST) From: Donald Ball X-Sender: To: Cc: Subject: Re: Proposal: URL Protocols In-Reply-To: <3A76EDE6.C7E83013@apache.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Tue, 30 Jan 2001, Berin Loritsch wrote: > Paul Russell wrote: > > > > * Berin Loritsch (bloritsch@apache.org) wrote : > > > I want to run something by the list regarding the way > > > Cocoon uses URLs to get references to files and such. > > > This _does_ affect both versions, and it refers to the > > > naming of the protocols. The way Servlet 2.2+ specifies > > > to get files from the WAR file is the context.getResource() > > > method. All resources are relative to the context root. > > > This is separate and distinct from Classloader Resources. > > > My proposal is to specify the following Resource protocols: > > > "resource:" This gets a ClassLoader resource, loaded by > > > the Cocoon ClassLoader. This is what it already > > > does. > > > "context:" This gets a Context resource, pulled by the > > > Context.getResource() method. > > > > Yep. Works for me. +1. How do you propose implementing this? Using the > > standard URI api I assume? > > That would be the long term plan. The alternative would be to do > what is already done in the NetUtils class. Anyone have experience > creating URL Handlers? i'm +1 as well, but warning - there's a serious problem with the URL handler implementation in the JDK. i can't remember the exact details, but maybe stefano will - it had something to do with problems arising if another package in the same JVM tried to register any URL handlers. > Ability to use the loaded ClassPath (no more parsing of the classpath > attributes), ability to use streams (java input stream, and class > output stream). > > That way we won't need the repository at all (except for debugging > purposes)--as we can directly serialize the XSP java stream into > the compiler and directly load the class by stream into the > classloader. oooh. sexy. - donald