Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Message-ID: <3BDC1EFB.CF85D71B@apache.org>
Date: Sun, 28 Oct 2001 16:06:35 +0100
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: Avalon Developers List <avalon-dev@jakarta.apache.org>
Subject: Re: [phoenix] ClassLoader stuff
References: <200110281013.f9SADg232102@mail016.syd.optusnet.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Donald wrote:

[requoted out of place]
> So I started refactoring but really didn't come up with any ideas. I gotta
> say that I HATE the way they did protocol handling in the JVM though ;)

No kidding, dude!

BTW, I don't only HATE it, I think it's a significant barrier to more
advanced uses of the URL concept on the server side and I was thinking
at submitting a JSR to the JCP to change this. 

Are you guys with me?

> Hi,
> 
> I ended up playing for about six hours today trying to get the ClassLoader
> stuff working again today. There was a few issues. Namely that each time a
> resource was accessed it would reload, scan and build a JarFile and so on
> which was killing performance. There was also no way to specify permissions
> and a whole bunch of other stuff. Also we really can't take over the
> URL.setURLStreamHandlerFactory() because our hosted apps may want to use it.

The java.net.URL design was done by James Gosling himself and it's a
whitebox framework and, in fact, very close to the IoC ideas that later
emerged more explicit. (in fact, the difference in design between
java.io and java.net is striking)

The only problem is that nobody was thinking at the server side when
they designed java 1.0 (both java.io and java.net are that old) so both
protocol handling, classloading and security management (for java 1.0)
were thought for single applications.

Java 1.1 fixed a bunch of issues with classloading and security
management but still didn't remove the stupid requirement of setting the
factory only once.

Today, this plagues almost all servers, expecially servlets since even
if servlet containers don't set thier factory, a servlet can't do
otherwise only one instance of that class can work.

At the same time, it must taken into consideration that it is a
potentially huge security problem: even protocol handlers must be
sandboxed otherwise there is a big chance of having my requests
processed by a protocol handler set by someone else.

It's a mess, expecially when mixing URL protocol handlers, custom
classloaders and custom security managers, but there is no way to do it
now so I think we must come up with something to propose to the JCP to
change the java platform.

But even if we do that, it will take years to become mainstream so we
must come up with another solution.
 
> Anyways there is only one thing that I haven't done yet that will probably
> work. It is ugly but the only option I can see ;( (Well other than writing
> our own ClassLoader which is probably heaps of work).

It is, but it's something that we must consider doing (besides, we can
start using the Tomcat one which is a pretty good one).
 
> Essentioally we have the code for the SarURLHandlerStream and friends in base
> classloader and in the system search path for that sort of stuff. We then
> have each thread store which current application it is dealing with and work
> that way. A bit ugly and britlle but it should work.

Sorry but I don't get it, but probably I've lost the context the
discussion, can you please enlighten me a little?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>