Luc Saint-Elie wrote:
> Hello,
>
> Here are some basic/stupid questions about JWSDK 1.0-ea settings:
>
> I would like to use a jared servlet with JWSDK 1.0-ea, this servlet having
> a properties to be set
>
There are really two issues here.
Q: How does the JSWDK servlet engine find my servlet classes?
A: Put the JAR file containing your servlet in the class path environment
variable, either before you execute the "startserver" script, or by modifying
that script itself.
This is also true for any classes referenced by your JSP pages -- for the
JSWDK engine, they *must* be on the system class path to be found. And yes,
that means there is no automatic reloading if you change the classes ... you
must restart the server to have this recognized.
Q: Where do I declare my servlet initialization parameters?
A: This depends on whether you want your servlet to appear in the "default"
servlet context, or in a specific servlet context (for this purpose, think of
a servlet context as similar to, but not identical to, a zone in Apache
JServ).
In the examples below, I assume that $JSWDK-HOME is the directory you
installed JSWDK-1.0-EA into, and that we're talking only about the two
contexts that are included in the default configurations.
If you want your servlet to be part of the default context, you would modify
the following files:
$JSWDK-HOME/webpages/WEB-INF/servlets.properties
(to set the servlet name and class, and the init properties)
$JSWDK-HOME/webpages/WEB-INF/mappings.properties
(to map the servlet to a particular URI prefix or extension)
If, on the other hand, you wanted your servlet to appear as part of the
"examples" context, (and therefore have a URI like "/examples/xxxxx"), you
would modify these files instead:
$JSWDK-HOME/examples/WEB-INF/servlets.properties
$JSWDK-HOME/examples/WEB-INF/mappings.properties
How did I know this? Because the "default.cfg" file tells me that the
document base for the default context is "webpages" (relative to $JSWDK-HOME
because an absolute path was not used), and the document base for the examples
context is "examples" (again relative to $JSWDK-HOME because the path is
relative to the current working directory). In both cases, the configuration
information is always stored in a WEB-INF subdirectory under the document base
directory for the context
you are working with.
A "document base" is in fact a directory in both of these cases, because you
are declaring something equivalent to the "DocumentRoot" configuration
parameter in Apache. However, you have several choices in how you actually
set this value. Consider the following examples:
* server.webapp.examples.docbase=examples
"examples" must be a directory relative to the current
working directory when you execute the startserver script.
* server.webapp.examples.docbase=/my/path/to/examples
This is an absolute path to a directory, on the same server,
that contains the document tree for this context. There
must be a WEB-INF subdirectory here containing the configs
for the servlets in this context.
* server.webapp.examples.docbase=http://www.mycompany.com
Use an existing web server as the "document root" for this
servlet context, which lets you access files (HTML pages, JSP
pages, whatever) on a different server in a distributed environment.
No changes at all to your servlets are required, as long as you are
using ServletContext.gerResource() instead of
ServletContext.getRealPath() to access these resources.
* server.webapp.examples.docbase=xyz://.....
You can define your own URLStreamHandler for scheme "xyz:"
and access resources from a database, from a JAR file, or whevever,
in a manner totally independent of the underlying protocol.
Again, the servlet source code doesn't change at all -- this
is a configuration setting for the context in which the servlet runs.
>
> 1) How must I set up the new "Webapp" ?
> =======================================
> from the doc (in default.cfg):
> //-----
> # All sections of the server's namespace are defined in terms of
> # a 'webapp'. There are two attributes that define a webapp, 1)
> # a mapping of where the webapp is placed into the namespace of
> # the server and 2) the base of the webapp. The base can be composed
> # of a simple string as shown below which indicates a file
> # relative to the current working directory (the directory in which
> # the server was started) or can be a full URL.
>
> server.webapp.examples.mapping=/examples
> server.webapp.examples.docbase=examples
> //--------
>
> Perhaps I'm stupid but I don't understand this. More precisely I don't
> understand was is "examples" in the line
> "server.webapp.examples.docbase=examples". The doc says "The base can be
> composed of a simple string as shown below which indicates a file relative
> to the current working directory (the directory in which the server was
> started)" but there is NO file named "examples" in the install there is
> only a directory.
>
> I've added the following lines to my default.cfg:
>
> server.webapp.luc.mapping=/TEST
> server.webapp.luc.docbase=TEST
>
> And placed some jsp and HTML files in a <JWSDK1.0-ea_HOME>/TEST directory
> (so at the root level like the original examples directory)
>
> I can access my files with
> http://127.0.0.1/TEST/myfile.jsp
> but not with
> http://127.0.0.1/luc/myfile.jsp
>
Your "server.webapp.xxxx" configuration parameters are establishing a new
servlet context with an alias of "luc". Now, you must create the appropriate
configuration files for that context, with the following contents:
TEST/WEB-INF/servlets.properties
=================================
jsp.code=com.sun.jsp.runtime.JspServlet
jsp.initparams=keepgenerated=true <-- Or whatever init params you
want
TEST/WEB-INF/mappings.properties
==================================
.jsp=jsp
This causes the ".jsp" extension for any URI within your context (in other
words, any URI of the pattern "/TEST/.xxx.jsp") to be resolved to the JSP
servlet. Extension mapping is per-context instead of global, because you
might want to use a different JSP implementation than some other web-app (i.e.
some other context) that is installed in the same server.
So why did "http://127.0.0.1/TEST/myfile.jsp" work? Well, it's a little
subtle, but makes sense once you understand the way that the servlet engine
figures out what servlet to run. It works like this (the URI being requested
is "/TEST/myfile.jsp"):
* Match the beginning of the requested URI against the prefixes
of all defined contexts, to see which one to choose. In thiis
case, there are only two prefixes defined:
/example --> The "example" context
/luc --> The new context that you created
so neither of them matched.
* If no context matches, use the default context instead,
which includes a mapping for the JSP servlet (look at
the config files in "webpages/WEB-INF" to see this).
This also explains why "http://127.0.0.1/luc/myfile.jsp" fails until you add
the config files described above. The "/luc" prefix matched the prefix for
your context, so the servlet engine checks the mappings you've defined there
-- but you didn't have any defined, so it didn't know what to do.
I hope this helps you understand what's going on. The key principle is that
you configure each web application independently from all other web
applications that are running in the same server, by modifying config files in
the WEB-INF subdirectory under the document base for that application.
Because nearly all references within your servlets and JSP pages are relative,
you don't even care if the sysadmin changes the "mapping" setting for your app
-- everything still works. This is incredibly powerful, once you get the hang
of it.
In the servlet APi version 2.2 spec, you will see this configuration stuff
formalized in an XML-based configuration file for a web application. But it's
really all the same principles that apply, so learning them now will help you
transist to 2.2-based servlet engines with very little effort.
>
> 2) Which files are mandatory in a Webapp and where must I place them ?
> ======================================================================
> I would like to use a jared servlet (cocoon in fact) in a Webapp that is in
> a TEST directory.
> Where must I place the cocoon.jar file ?
(It does not matter, as long as it's on the system class path)
>
> At the root level of my TEST directory ?
> In the Web-INF directory ?
> Is this Web-INF directory a mandatory member of a Webapp?
> I seem to have understood that the servlets properties are set up in the
> "servlets.properties" file in the Web-INF directory, is it true, can this
> be placed elsewhere ?
> If it is true, how can I access my jared servlet from another Webapp ? does
> that mean that I need a version of the same jared servlet for each of my
> Webapps ?
>
Most of these questions have been addressed above, but I'd like to deal with
the last one for a moment.
Because all of the servlets have to be on the system classpath for JSWDK, you
can declare a servlet mapping like this:
jsp.code=com.sun.jsp.runtime.JspServlet
in more than one "servlets.properties" file, and they will all reference the
same class. However, each web-app (i.e. each servlet context) will have its
own ***instance*** of that class, with its own initialization parameters.
The way to think about this is that a web-app is a self-contained unit. I can
share things that are loaded from the system class path, but the init
parameters and mappings are private to my web-app, independent of any other
web-app that might be using the same servlet classes. This approach minimizes
the opportunities for servlets (or JSP pages) that are part of one web-app to
mess up the behavior of a different web-app installed on the same server.
>
> Thanks in advance
There's lots of other subtleties to this. Give me a holler if you've got
other specific questions, either on the list or privately.
>
> +------------------------------------------------+
> | Luc Saint-Elie |
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
