You think your question about Jigsaw is worth entering this list, you have a better formulation for some of the answers ? Mail to jigsaw@w3.org !
Jigsaw is the new W3C reference server. Its main purpose is to demonstrate new protocol features as they are defined (such as HTTP/1.1 or PICS), and to provide the basis for experimentations in the field of server software (such as the provided MUX prototypical implementation).
You can download Jigsaw distribution file in various formats, and using either ftp or http:
Java has a number of advantages that fit well with our purposes. It provides portable threads and garbage collection, allows for a very dynamic server architecture. It's ability to move code around may be use in future development to experiment with the mobile code concept.
No so true ! Check out the performance evaluation of Jigsaw, which indicates that it performs at least as well as the CERN server.
To a normal HTTP web-admin, Jigsaw's configuration process might look really strange...Jigsaw's design emphasis two different processing stage in serving documents:
In short the rationale for separating these two stages is to make the serving stage as efficient as possible, by having the indexing stage prepare as much as possible the work. A document enter the WEB space the first time Jigsaw serves it; this happen behind the scene most of the time, and consist in creating a resource for the document to be served by querying a resource factory. The current resource factory can be configured to create various kind of resources based either on the file name extensions, or (in case of a directory) based on its name.
However, once a resource is created, it no longer reflects the settings of
the resource factory (available resp. as /Admin/Extensions
and
/Admin/Directories
); in some sense the information gets
compiled so that at serving time, processing overhead is reduced as
much as possible.
The current version of the generic resource editor is rather terse. At this point, the resource editor will present all the declared resource attribute values and some ways to edit them. All the attributes are declared in each resource reference manual.
Resource editors is an area in which you can expect big improvement in the next release. Right now, it is recommended that you use two browser windows, one displaying the form based editor, and the other one displaying the appropriate reference manual for the resource being edited (which described all the attributes semantics).
Setting up authentication through the form based interface requires you to run through the following stages:
/Admin/Realms
.
You can of course reuse authentication realms to protect different areas
of the server.
/protected
directory resource, then you have to bring up its
editor, which will usually be available as
/Admin/Editor/protected
.
That's it ! For more information, you may want to read through the configuration tutorial.
CERN server implemented this through the Pass directive, which let you map a server path to an absolute path on your file system. Jigsaw uses the w3c.jigsaw.resources.PassDirectory resource.
COOKBOOK METHOD: Create a new resource with Add resources in the Editor at the location you want the new server path to exist. Assign whatever name you desire to the new resource, and assign w3c.jigsaw.resources.PassDirectory for the class. Edit this new resource to change the pass-target attribute to the absolute path to the directory you want to serve.
You may want to change the name attribute of the 'index' file in that directory to Overview.html. name and filename are two separate attributes in Jigsaw; this is also a poor man's (or a Win95/NT user's) symlink.
Serving directories outside your server root may be a security risk.
They are two ways to setup CGI scripts. The manual way requires that you
describe each script to the server. Let's say your script's path relative
to the server root is WWW/cgi-bin/myscript
. You will first have
to create an appropriate
w3c.jigsaw.forms.CgiResource
instance to wrap your script, by pointing your browser to the
/Admin/Editor/cgi-bin/ directory resource. Click the Add resource
link, and enter the name under which you wish your script to be seen, and
the
w3c.jigsaw.forms.CgiResource
as the resource class.
Then edit the newly created resource, and setup it's command line (the command line the server will use to run your script). Each line of the text field should represent one argument, the first one being the script full path.
You can also register files of a given extension as scripts, by using the
/Admin/Extensions
extension editor. Say you want to have all
.pl
files to be exported as perl scripts. Register the
extension, and map it to the
w3c.jigsaw.forms.CgiResource;
when required, you can even specify the interpreter to be run to execute
the script (for example, under Windows 95, or NT).
Running Jigsaw as a proxy involves the following steps:
w3c.jigsaw.proxy.ProxyDirectory
resource in the root resource store, by pointing your browser to /Admin/Editor
and selecting the Add resource link. Type in the name of the resource
(ie proxy
), and its class
(w3c.jigsaw.proxy.ProxyDirectory
). local-root
attribute to the old root resource (ie
root
under the default configuration) and select OK.
This will make sure that requests targeted to the proxy itself will be served
by the normal server, allowing for access to the configuration.
w3c.jigsaw.root.name
) to proxy.
Then select OK.Jigsaw can be extended in a number of ways. Here are just three possible things you can play with, from the simplest to the complex ones:
Jigsaw implements its own persistence mechanism while RMI already
provides a way to serialize objects, why is it so, will it change ? What
Jigsaw implements in the w3c.tools.store
package is more
then persistence. It provides both a way of serializing objects and
a way of describing what and how the object will be dumped. The available
meta-description of objects (that you can obtain through the
getAttributes
method of resources), is a central part of
Jigsaw architecture, since it offers the ability to create generic
resource editors. This is not likely to disappear.
However, Jigsaw persistence mechanism may be merged in the future
to the RMI interface, just by providing an implementation of the
readObject
and writeObject
method through its existing
mechanism.
HotJava is Sun's
Java based browser. If you want to experience an HTTP/1.1 compliant browser,
you can run this browser on top of Jigsaw's HTTP/1.1 compliant HTTP
client API. To do so, you need to define the
java.protocol.handler.pkgs
property to w3c.www.protocol
before launching HotJava. The best way to do so is to edit the HotJava
property files.
Jigsaw's HTTP client API defines a number of other properties, if you are planing to use this setting, you should read the HttpManager documentation to get the complete list of available properties. These will allow you to add caching, authentication, proxying and more to HotJava !
As of release 1.0alpha5, Jigsaw can now run on port 80, without running as the root user. To implement that you need to install the relevant piece of native code. This C code has been compiled and tested under Solaris, porting it to a different platform/architecture should be pretty easy.
Follow the normal installation procedure, and try to run Jigsaw on
a port greater than 1024. Once this work, stop Jigsaw (through
/Admin/Exit
), Make sure your LD_LIBRARY_PATH variable includes
the directory containing libUnix.so
(this is the
Jigsaw/lib
directory under the standard release).
Select the user and group you want Jigsaw to run as. Make sure that
user has read/write access to the entire config
directory. Then,
you just need to run Jigsaw through that special command line:
java w3c.jigsaw.Main -user user -group group
<other-options>
Where user and group should provide (resp.) the user and the group you want Jigsaw to run as.
Warning: As the underlying UNIX process will change personnality right
after acquiring the socket, the form based restart button (available
from the properties editor) will no longer work, since the process will no
longer be able to allocate a socket on port 80.
Under such a setting, the only way to restart Jigsaw is to kill it
(through /Admin/Exit
) and restart it manually.
As of release 1.0alpha5, Jigsaw can now - under UNIX - be chroot'ed. If you try to do so, you are supposed to have some experiences with chroot'ing programs. We will assume that you already have a correct root to run a standard HTTP server and that you have read and understood the Running Jigsaw on port 80 FAQ entry.
You need to install Java in that root (using whatever prefered way you want). To install Jigsaw, I would recommend using the following directory structure:
Given that (don't forget to symlink the real
/usr/local/jigsaw
to the chroot'ed one), you should be
able to reuse that script:
#!/bin/sh # Jigsaw # $Id: FAQ.html,v 1.19 1997/02/12 09:26:04 abaird Exp $ # Jigsaw launcher # LD_LIBRARY_PATH will be set to work *only* before chroot, by the java script # We add here, support for PATH as they appear to be after the chroot CR_LD_LIBRARY_PATH=/usr/local/jigsaw/lib:/usr/local/java/lib/sparc:/usr/lib:/lib LD_LIBRARY_PATH=$CR_LD_LIBRARY_PATH:$LD_LIBRARY_PATH export LD_LIBRARY_PATH # CLASSPATH needs two hacks: one to include jigsaw.zip before chroot, and # an other one to include everything after chroot CLASSPATH=/0/w3c/abaird/sbroot/usr/local/jigsaw/classes/jigsaw.zip:/0/w3c/abaird /sbroot/usr/local/jigsaw/classes/servlet.zip:/0/w3c/abaird/sbroot/usr/local/jigs aw/classes/plus.zip:/0/w3c/abaird/sbroot/usr/local/jigsaw/extensions export CLASSPATH CR_CLASSPATH=/usr/local/jigsaw/classes/jigsaw.zip:/usr/local/jigsaw/classes/serv let.zip:/usr/local/jigsaw/classes/plus.zip:/usr/local/jigsaw/extensions CLASSPATH=$CR_CLASSPATH:$CLASSPATH export CLASSPATH # Ready to run jigsaw, now: cd /0/w3c/abaird/sbroot/jigsaw exec /usr/local/java/bin/java w3c.jigsaw.daemon.ServerHandlerManager $* -group n obody -user nobody -chroot /0/w3c/abaird/sbroot -root /jigsaw
Anselm Baird-Smith
$Id: FAQ.html,v 1.19 1997/02/12 09:26:04 abaird Exp $