Peter Donald wrote:
>
> On Mon, 29 Oct 2001 02:06, Stefano Mazzocchi wrote:
> > 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?
>
> Yes and no. There is so many broken APIs such as this and more keep coming
> out each day. For instance JNDI is a JVM wide setting, JDK1.4 logging is JVM
> wide, JDK 1.4 Prefs is JVM wide etc. This is not even to mention the Policy
> objects and half the security API. More and more of the JVM is being forced
> into the "single JVM, single app" model which completely bites.
yep
> URLProtocol/Content handling could be done much better though so I say go for
> it ;)
ok
> Howrver the only real solution given the way the JVM is evolving (hey anyone
> want to chuck a kitchen sink n today?) is to do isolation at the JVM level.
> Luckily a JSR is currently in progress to just do that - JSR121, the Isolate
> API.
uh, gotta update myself to the new JSRs...
> Essentially it plans to do lightweight creation of isolated JVMs (or
> Isolates) and basic communication between such Isolates. So think of it as a
> fast java version of fork(). It is still not perfect (isolation of native
> resources is a stickler) - but it will solve many of these in-JVM issues.
>
> It will also potentially be so much faster than native C fork - yaya! How
> kool will that be. STart one JVM at computer start and then have each other
> java app start faster than native apps and no longer require 4-5 times as
> much memory as native apps. Yay!
Which is basically what Mozilla is going to do on windows to beat IE in
starting up (which, BTW, already does this in a hidden way being
"explorer" the desktop application)
> However it is not gonna see the light of day till tiger (1.5) at earliest ;(
right.
> Actually you will notice that Phoenix has been gradually evolving so that it
> can take advantage of that model ;)
kewl :)
> > > 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).
>
> Actually part of Catalinas classloader has already been canibalized, cleaned
> and refactored and is sitting in excaliburs CVS ;) (I nabbed the Extension
> handling code essentially).
Ah, great.
> > > 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?
>
> Okay we have our application deployment file - say foo.sar (much like .war
> files except for Phoenix service framework). In it is contained the jars that
> contain the support libraries and block archives.
Ok
> Ideally we want to access these libraries inside the .sar without extracting
> them onto the filesystem. That way it is easier to manage and there is less
> chance that a user can mess up the deployment.
Good point.
> Originally it was implemented in a similar fashion to the jar: protocol
> handler. An example would be
>
> sar:file:/my/dir/apps/demo.sar|/SAR-INF/lib/myBlocks.jar
>
> This worked great for small .sars but got painful as the size of the .sar got
> bigger. The reason was that each URL access would rescan the zip and reload
> it all. While the time difference was unnoticable for our demo apps however
> it took about 6 minutes at 99% CPU to unpack/load the catalina .sar file ! ;)
I know how that feels: try starting four different Cocoon instances into
tomcat 4 and watch your cpu melt :) (and your disk fill up!)
> So we really need for their to be only one ZipFile object opened at ony time.
> We can't cache at the JVM level because side-effects between Aplications can
> occur. (I have suffered from side-effects of URL caching at JVM level before).
And it's a potential security hole anyway.
> So we need to cache at the Application level. To do this I changed urls to
> look something like
>
> sar:/SAR-INF/lib/myBlocks.jar
>
> However implementing this required per-thread information to be setup and
> maintained for each application so that propoer caching could occur.
Right. I know what you're talking about.
> However everytime I tried to implement this I ended up with a spiderweb of
> ugly
> dependenceis and assumptions - not really maintainable.
>
> It also required us to set per JVM protocol factory because the class
> implementing SarURLStreamHandler was not in system classloader but in the
> containers classloader.
Hmmm, what if we design a new URL-handling system that cascades back on
the JVM one directly into avalon? Cocoon already does this, but as more
and more things require to properly setup protocol handlers, this might
be a thing to consider.
And for sure, will be faster and easier than to wait for the JSR to come
up with something into the official JVM.
> Other real options include
> * moving SarURLStreamHandler to system classloader and going with ugly tight
> coupling.
-1, ugly and potentially harmful.
> * extracting jars into tmp/work directory and reusing them (like how Pauls
> sugested using MetaJarToolkit)
not that bad, but might easily fill up your disk.
> * writing our own ClassLoader
I like this one the most.
> * ignoring this factor and always extracting lib
> * something else?
having a thread-group and one main thread per SAR is not that bad of an
idea. After all, this is what you expect when you have multiple servers
running inside the same JVM.
But I think that in order for this to work, we need to couple this with
a custom classloader and a custom security manager and provide an
avalon-way of getting URLHandlers, completely avoiding the native calls
to new URL(), but using avalon-powered factories such as
URL URLFactory.create(...)
but there might be some stupid final methods that prevent us from
messing up with that, I'll do some research...
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
