Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <39AF9C59.8C9F4017@apache.org>
Date: Fri, 01 Sep 2000 14:08:57 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [C2] ClassLoader issues
References: <F2859mEm2YCaIpJEIbK00003fe9@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robin Green wrote:
> 
> Stefano Mazzocchi <stefano@apache.org> wrote:
> >Robin Green wrote:
> > >
> > > Giacomo Pati <pati_giacomo@yahoo.com> wrote:
> > > >I've never understud why JSP is able to compile and load classes out of
> > > >WEB-INF/lib but XSP does not?
> > >
> > > Funny, I was racking my brains over this just today. Spooky!
> > >
> > > It's because XSP compiler gets the classpath from System.getProperty
> > > ("java.class.path") IIRC, and Tomcat doesn't change the system property
> >to
> > > reflect its own internal classpath. Maybe that would be the solution -
> >but
> > > I'm not sure whether mucking around with predefined system properties is
> > > allowed, safe or sensible.
> > >
> > > So I would suggest an addition to the Servlet API as a cleaner solution
> >-
> > > and I know Stefano is/was on the Servlet expert group, so I'm not
> >talking to
> > > thin air! :-)
> >
> >Please, give me more precisie indications of what you mean.
> 
> I mentioned this in another email on C-users: Maybe the Servlet API should
> have a method to get a classpath from the servlet engine, which would be
> useful e.g. for XSP compilation and XSP class loader purposes. Perhaps this
> classpath would be a list of directories and jars on the local filesystem,
> or perhaps it would be a list of URIs. Or maybe two methods, one for each
> alternative. The file list would be more useful in the case of javac.

Sorry, but I don't see a technological need for this at the API level.

The fact that you require a classpath to compile something is _not_ a
design flaw of the Servlet API but a design problem with stupid Javac
and stupid Java that both base their system classloader on a string
which is list of places were to find classes (a.k.a. classpath).

A servlet should _not_ be aware of where its own classes are: this could
easily lead to security holes.

A servelt should simply call it's classloader or pass it along to Javac.

Imagine a compiler interface that has method

 Class compile(InputStream source, Map flags, Classloader classes) throw
CompilationException;

that's it! the servlet container will give you a classloader that
"covers" all the classes required for your source to compile. And if a
class is not found, it's up to you to change the "available" classes at
the servlet container level.

Sure, such a compiler doesn't exist and this is a problem, but it's not
impossible to write one (or to convince Sun to free it completely) and
it's not impossible to patch Tomcat to provide such advanced
classloading capabilities.

But I don't see any need for any Servlet API changes.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------