httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Schrenk <nschr...@neog.com>
Subject Re: Server Side java support
Date Tue, 02 Jul 1996 00:21:37 GMT
On Mon, 1 Jul 1996, Lucid wrote:

> I am currently working on hacking Java VM support into apache

I'm all for a Java VM in Apache.  We've been developing some server-side
Java code for some time, and have looked at the server-side Java
implementation in Netscape's Enterprise server and it seems really slow. 
Here we've written a standalone server-side Java daemon (it's written in
Java) which mimics enough of Netscape's server-side java API for our
server applets to run unmodified in the Enterprise server's built-in VM
and in our daemon.  We use a simple C CGI program to connect the HTTP 
server to the daemon.  Doing some performance testing we found that an applet
running in our daemon (run with the JDK 1.0.2 java VM runtime) performed
significantly faster than when the same applet was running in the
Enterprise server, and they subjectively appeared to display far faster,
perhaps due to differences in how the output was buffered.  Hopefully
Netscape will improve the performance of Java in the Enterprise server; if
not, I'll end up using our standalone server-side java implementation or
some other server. 

> Ideas:
> 	java support in the core
> 	java support via CGI like interface
> 	java module support
> 	embedded java VM as a handler

Java support in a module seems like the most straightforward approach,
unless you are proposing to be able to implement modules in Java, in which
case things get much hairier and you need to make extreme modifications to
the core.  A module is also good becasue any people won't need or want
this, just like many people don't need or want an embedded perl
interpreter in their HTTP server. 

It could recognize some type of file extension or perhaps you would have 
a "JavaAlias" directive similar to ScriptAlias to define a directory 
containing Java code.

One sticky thing that we ran into is that when you have this persistent
Java VM hanging around it is a pain to do development because you seem to
have to restart the VM before you can get it to load a new version of the
class.  And you also have a problem with not being able to use classes of
the same name back-to-back (which is sometimes useful if you want to
compare output from different versions of a project). 

Let me know if you'd like some assistance with this effort,

Nathan

--
Nathan Schrenk						nschrenk@neog.com
Neoglyphics Media Corp.                              http://www.neog.com/


Mime
View raw message