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. URLProtocol/Content handling could be done much better though so I say go for it ;) 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. 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! However it is not gonna see the light of day till tiger (1.5) at earliest ;( Actually you will notice that Phoenix has been gradually evolving so that it can take advantage of that model ;) > > 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). > > 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. 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. 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 ! ;) 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). 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. 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. Other real options include * moving SarURLStreamHandler to system classloader and going with ugly tight coupling. * extracting jars into tmp/work directory and reusing them (like how Pauls sugested using MetaJarToolkit) * writing our own ClassLoader * ignoring this factor and always extracting lib * something else? -- Cheers, Pete *-----------------------------------------------------* | For those who refuse to understand, no explanation | | will ever suffice. For those who refuse to believe, | | no evidence will ever suffice. | *-----------------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
