cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Proposal: URL Protocols
Date Wed, 31 Jan 2001 09:11:26 GMT


Donald Ball a écrit :
> 
> 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.
> 

The JDK protocol extension mechanism is poorly designed. There are two
possibilities to add a new protocol (see java.net.URL javadoc) :
- add the package name of the URLStreamHandler (with special naming
conventions) to the system property "java.protocol.handler.pkgs",
- call the static "java.net.URL.setURLStreamHandlerFactory" method,
which can only be called once within the JVM lifetime.

As you can see, neither solution is compatible with WAR drop-in
deployment. That's why IIRC Stephano envisioned one time to have a
Cocoon-specific URLStreamHandlerFactory class that all components should
use. This class would handle all Cocoon-related protocols and delegate
others to the JDK.

BTW, there's a good article on the JDC on this subject, even if it
ignores the above problems :
http://developer.java.sun.com/developer/onlineTraining/protocolhandlers/

> > 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
> 
-- 
Sylvain Wallez
Anyware Technologies

Mime
View raw message