John Swapceinski wrote:
> I've been trying to get the JSDK 2.1 ServletRunner to pass in an
> initialization parameter to a servlet and have been having trouble. Has
> anyone gotten this to work? Even the sample SnoopServlet doesn't seem
> to be working correctly for me.
>
> It appears that ServletRunner no longer obeys any command line
> configuration parameters that are passed to it on startup, like it did
> in JSDK 2.0 (for example, the "-s" command). Some of the ServletRunner
> configurations are set in the file "default.cfg", and I also see a
> sample file called "servlets.properties" that seems to indicate that
> initialization parameters can be set there. However, it doesn't seem to
> be working.
>
> I think part of my problem is that I don't understand the relationship
> (if any) between the default.cfg file and the servlets.properties file
> (which happen to be in different directories). How does ServletRunner
> know where to find its servlets.properties file? Can anyone give me
> some hints on how to make initialization parameters work? Has anyone
> gotten initialization parameters to work with JSDK 2.1?
>
> Thanks in advance for any help you can give.
>
> John
>
It's easier to make sense of the relationships when you understand that there
are two levels of configuration going on -- a servlet context (with a set of
servlets in it), and the individual servlets themselves. Let's consider the
default configuration of the JSDK 2.1 kit, which is pretty much the same in
the JSWDK kit that includes JSP. I will use {JSDK_HOME} to mean the directory
you installed it into (/usr/local/jsdk_2.1 on my system):
In the "default.cfg" file, two different contexts are being defined:
* The "default" context, which processes all URLs that don't match
the prefix of any other context. The document root cointext for
this context is set with the "server.docbase" property, to
{JSDK_HOME}/webpages.
* The "example" context, which is defined by two properties:
* Any URL that starts with "/examples" is processed by this
context (server.webapp.examples.mapping)
* The document root for this context is {JSDK_HOME/examples
(server.webapp.examples.docbase).
Within each context, the document root directory contains a subdirectory named
WEB-INF that contains the configuration files for that context. For the
default context, this directory is "{JSDK_HOME}/webpages/WEB-INF", while for
the "examples" context this directory is "{JSDK_HOME}/examples/WEB-INF".
In the WEB-INF directory, the "servlets.properties" file defines the Java
class and the initialization properties for all named servlets. For example,
in the servlets.properties files for the default context (that is, in the file
{JSDK_HOME}/webpages/WEB-INF/servlets.properties), we see the following lines
for the Snoop servlet:
snoop.code=SnoopServlet
snoop.initparams=initarg1=foo,initarg2=bar
The snoop servlet will see two initialization properties (initarg1=foo and
initarg2=bar) when its init() method is called. This is how you must set
initialization parameters for your own servlets that run in this context as
well.
In the "mappings.properties" file (within the WEB-INF directory for your
context), you define how the servlet is called. In the default context, there
are two different ways to address the snoop servlet, configured as follows:
/snoop=snoop
.snp=snoop
This means that asking for a URL "http://www.mycompany.com:8080/snoop" or
anything that ends with a ".snp" extension will call the snoop servlet (such
as "http://www.mycompany.com:8080/my/path/to/a/file.snp"). If you leave the
"invoker=true" setting in the "webapp.properties" file for your context, you
also enable a third way to access the servlet, by saying:
/servlet/snoop or /servlet/SnoopServlet
So, if you wanted to add your own servlets, the two files to modify woulld be
these:
* In "servlets.properties", add "xxxxx.code" and "xxxxx.initargs"
lines to define the Java class and initialization parameters for a
servlet named "xxxxx".
* In the "mappings.properties" file, add a URL path and/or an extension
match mapping to define the URL by which your servlet can be executed.
The last thing you have to remember is to include any directory or JAR file
containing your servlets in the CLASSPATH, and you've got things pretty well
understood. You can either preconfigure your CLASSPATH before you run
"startserver", or you can rely on something that is not obvious unless you
enjoy reading shell scripts: if you define a directory called "classes" in
your {JSDK_HOME} directory, this directory will get included in the CLASSPATH
for the server automatically. This makes a pretty good place to put your
servlets while you are experimenting.
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
