-
This is what I understand that these rapidly changing buzzwords mean.
Beware, I am wrong, and not general, and not far reaching enough...
Moreover, I speak with UNIX bias. I discovered (on March 27, 2000) a great book:
Duane K. Fields, Mark A. Kolb, Web Development with Java Server Pages ,
Manning Publications, 554 + intros as . It is scheduled to appear in April 2000,
but you can buy it really cheap over the net as PDF file (they call it EBook)
at http://www.manning.com/.
Beware, it is about 600 pages to print (including front and back matter).
While for obvious reasons it ends at Tomcat 3.0, it is quite up to date
with JSP/J2EE/Servlet specs, and I find it an easy to follow, yet quite
packed with practical info. No, I do not work for them...
JSP -- Java Server Page -- a mixture of HTML, XML, and Java
which is great for producing dynamic Web contents. To understand what
is happening on the Web Server side, you can look at JSP as shorthand
notation for a full blown servlet. It is great, since you can hide
programming in JavBeans, define jsp:something XML tags
which do special tasks, and use already predefined tags too (say, e.g.,
to include files). At the same time, you can use normal HTML/JavaScript
to design your page. When the Web server (say Apache, but many other
servers support it too) a *.jsp file request
- Apache sends request to Tomcat using a special module
jserv. This module handles Apache side of socket connection
to Tomcat. They talk a special protocol called AJPV12 (Apache JServ
Protocol version 1.2). It was derived from the originl AJPV12
used in the original Apache JServ Project
http://java.apache.org/jserv/
but it evolved and is different. Beware!!! Currently the JServ
from Apache JServ Project use the same name for the protocol and the
module, but these things are different and incompatible. However, it
all will be consolidated hopefully soon (so I hear...). To use
Tomcat and JSP with Apache you have to use the Tomcat version of
jserv module. Note, in this small world viewed from the
Tomcat/jserv perspective, the Tomcat is a server (waits for
jserv to call him), and jserv is a client,
since it makes the first move.
- Tomcat gets the path to the *.jsp file from Apache's
jserv and checks if the *.jsp file is older than
the time stamp on the corresponding servlet in its memory.
If it is, it skips compilation and executes
the servlet. If *.jsp file was recently modified
(i.e., the servlet in the memory is older) Tomcat converts
the file into Java code. It does it by unfolding the
jsp:xxxx tags into pieces of corresponding
Java code, converts the static HTML into
out.println(something), inserts the Java code from scriplets,
etc. You can actually look at this Java code by peeking at the Tomcat
work subdirectories under $TOMCAT_HOME/work.
- Tomcat compiles the source Java code of the servlet and loads it to
the Virtual Machine, the servlet container. Of course, the
*.jsp page can be buggy, and you will get error page
rather than results in such cases.
- The servlet is executed in the servlet container and the results
(i.e., HTML page description), are returned to jserv
of Apache, and Apache returns them to the browser..
Few pointers to stuff on the Web:
Back To Questions List
-
Servlet container -- The piece of software which runs the
servlets. The servlet container can be either:
- a standalone application which just displays servlets and does
not talk to anything else. This is not really a practical solution
but may be great thing for debugging/testing;
- an integrated part of the Web Server, i.e., servlet container
runs in the same process as Web Server, and has access to all
internals of the web server and to its environment variables.
This is often the case when Web server is written in Java.
- a separate piece of software which talks to a Web Server
(or some other server) using some agreed upon protocol.
In this case, the Web server is a client, and the servlet container
is a server. The Web Server takes requests from browsers, looks at
them, and if they are requests to run servlets (or JSPs) it passes
them to the servlet?JSP container using some communication/data
exchange protocol. The servlet container runs the
servlet (it may need to compile the servlet first, though in most cases
you need to provide a ready to use class), collects
the results, and then passes them back to the web server using
a mutually agreed protocol. The web server returns results to
a browser which wanted a servlet served.
Servlet container, has to know where the servlet classes are located,
where are the other classes needed to run servlets (e.g., JavaBeans or
utility classes), i.e., it needs to have CLASSPATH defined. It will also
do many other things depending on the scope of services supported
by the servlet container (e.g., authentication, encryption...).
Tomcat is more than just a formal servlet container.
Ut is also a special server which talks to the Web server and
provides Web server with servlet/JSP processing capabilities.
Moreover, it is also a simple Web server (working by default on port 8080).
It can be interfaced with several Web servers,
but I only tried it with Apache, so I do not talk for others.
Back To Questions List
-
Web application -- It is a collection of JSPs, servlets, style
sheets, static HTML pages, Java Script or other client scripting
embelishments, applets, etc., which are related in some way.
It also contains information (called deployment descriptor files)
needed to describe what is what in this zoo.
The idea here is to collect some related pieces in one place (i.e., under
a single subdirectory, analogous to a tar archive for UNIX) and then to
mount the whole thing on the Web under some distinct location/URL.
In principle, web application can be distributed as a
single WAR file (Web Application aRchive) and installed
without unpacking in the area known to a Servlet Container (in our case,
Tomcat is our Servlet Container). In fact, the Web Application
usually does not have to know where it is located in the
directory stucture if you know the rules:
- All links in the HTML portion which refer to the material within
its own web application, should be relative.
- All absolute paths (i.e., paths starting from the /
character) within JSP tags (e.g., jsp:include or
within web.xml deployment descriptor, refer to
the top directory of your web application, and not the
top directory of the Web Document Tree.
- If you really need to have it, you can find what is your actual
path in the Web Document Tree by calling
getContextPath, e.g., you can use the trick:
<BASE HREF="<%= request.getContextPath() %>/">
and put it in the <HEAD> of your JSP.
Word of caution. In practice, the WAR files are still pain to
use (as of Tomcat
3.1 beta 1, as far as I know) since they had problems with situations
when some class was using another class from the same
WAR (some problems with class loader I presume). But they work on it.
It is therefore safer at this time to unpack the WARs before using
them. WARs are JARs. They are created, signed, packed, etc.,
the very same way the JAR files are, i.e.,
with the jar utility from JDK. The different extension was
chosen to stress that it is not only a Java code which
is in the WAR file, but also JSPs, HTML pages, config files, etc.
The WAR has a specific default directory structure, however, you do not
have to create a directory if it is empty in a given WAR. Example:
.../index.html
.../TheTextFile.txt
.../OurSoftware/OurProgram.exe
.../OurSoftware/TheTarFile.tgz
.../something.jsp
.../spiffyapplet.class
.../somedir/someother.html
.../anotherdir/some.jsp
.../anotherdir/my.html
.../anotherdir/funny.gif
.../images/some.gif
.../images/some.jpeg
.../WEB-INF/web.xml
.../WEB-INF/lib/...
.../WEB-INF/lib/some.jar
.../WEB_INF/classes/...
.../WEB_INF/classes/com/bigcomp/servlets/ByFromUs.class
.../WEB_INF/classes/com/bigcomp/utils/SnoopUser.class
.../WEB_INF/classes/com/bigcomp/utils/FancyServlet.class
There are essentially two types of files in this directory
structure:
- Files to be directly served on the Web, i.e., HTML,
applets, JSP, style sheets, images, text files, etc. These files are
in top directory, and in ordinary directories which will be
served as regular Web content in the Web document tree.
- Files located under WEB-INF directory. These files
are not to be served directly by the Web server.
The lib subdirectory contains jar files, with Java
binary code, which will be automatically included in the
Servlet Container CLASSPATH.
The files under classes subdirectory represent classes
and packages needed within web applications.
These can be either servlets to be served
or they may be utility classes or JavaBeans (needed by
servlets and/or JSPs). The web.xml is an XML file
which allows to set and/or modify
parameters, arguments, remap names, set mime types,
specify tag libraries, specify servlets to be loaded on
start-up, define scopes, authentication, encryption,
etc., etc., for the components of the current web application.
To learn more about it, study the Bible, i.e., Java Servlet
Specification, v2.2
(
http://java.sun.com/products/servlet/2.2/ ).
This directory structure can be changed, but this would require
that you remap the default structure via directives in configuration
files, and possibly by patching the Java code which is used in Tomcat.
Back To Questions List
-
Servlet Context -- it is essentially what servlet
sees when it runs, and how external world sees the servlet.
In Tomcat, servlet runs within the web application (see above)
and the directories, as well as web.xml configuration
file provides for initialization parameters for servlets,
attributes (i.e., sort of UNIX environment variables known
to the servlet), name mapping, knowledge of static pages within
web application, CLASSPATH, JavaBeans and utility classes which
were given in appropriate directories. I also believe that it
will be possible to set which virtual machine will run servlets,
and other goodies. The external world sees servlet as running
in the container which is accessible via the the container path,
i.e., the URL path. In the case of Tomcat/Apache combination, the URL
path is set via ApJServMount directive in Apache configuration
file. Purists are now spinning in their graves, I think...
Back To Questions List
-
In general, you need to have an Apache which supports DSO modules already
installed.
It needs to be a version at least 1.3.6, I believe.When this was written,
the latest production version was 1.3.12 and this is what I used.
You can get Apache
from http://www.apache.org.
Then you install Tomcat which you take from
http://jakarta.apache.org
As a part of Tomcat, there comes a specially
adapted version of the jserv module, which you need to copy to a
libexec directory of Apache. Then you need to configure Apache and
Tomcat to work together..
I do not want to give here a detailed prescription of installation, but
rather point you to the gory details. I just want to stress few points.
At this moment, Apache and Tomcat are not perfectly integrated. The
interface is still until very active development. But the major point is,
that Apache and Tomcat are two separate pieces of software. They formally
can run on different machines. They talk to each other via TCP/IP socket
and use the special protocol AJPV12 (for more on this check the
( JSP description at the top of this FAQ).
On the Apache side the piece which talks to Tomcat is called jserv
module. Formally, Tomcat is a TCP server. It waits for incomming
connections, usually on port 8007 (but you can change it).
These connections come from Apache Web Server (or other servers for
that matter, since connectors are written for Netscape
and Web IIS servers, and probably others too).
Tomcat gets the request from the Web server, processes
it, and returns the results back to Web server using the TCP connection and
talking via AJPV12 protocol. As you see, there are some things which
Apache has to know about Tomcat, but Tomcat does not need to know much
about Apache when it is installed.
At this point the information about Tomcat which is needed
by the Apache Web server is contained in the file
$TOMCAT_HOME/conf/tomcat.conf. This file is usually referenced
in the main Apache configuration file $APACHE_HOME/conf/httpd.conf
via the Include directive somewhere towards the end as, for
example:
Include /usr/local/apache_t3.1b1/sources/build/tomcat/conf/tomcat.conf
where the $TOMCAT_HOME in this case is:
/usr/local/apache_t3.1b1/sources/build/tomcat.
This file still has some some historical entries which are the leftovers
from the JServ project
(which is currently the most stable and
optimal way of running servlets in production environment, and which
served as a prototype for the Tomcat specific jserv module).
But essentially it tells jserv module of Apache:
- On which port the Tomcat is listening via
ApJServDefaultPort directive.
- That the files with *.jsp extension should be handled by
jserv
AddHandler jserv-servlet .jsp,
- That certain URLs, should be directed to Tomcat for processing.
For example:
ApJServMount /DynaWeb /root
tells Apache that URs whose path start with /DynaWeb should
go to Tomcat for processing. The /root seems to be fixed
at this moment, but it will probably evolve at some point to what it
was in the original Apache JServ module.
- That certain paths in the Web Document Tree should be blocked from
public view, e.g.:
<Location /DynaWeb/WEB-INF/ >
AllowOverride None
deny from all
</Location>
tells Apache to deny access to the URLs which start from /DynaWeb/WEB-INF.
In this case it is probably overkill, since Tomcat most likely
checks and enforces that the WEB-INF directory is not served
directly.
- There may be additional directives which take actions BEFORE the
request is forwarded to Tomcat, e.g., rewriting URLs with Rewrite,
providing Basic Authentication, as for example:
<Location /DynaWeb>
AuthType Basic
AuthName "For internal users only"
AuthUserFile /usr/local/apache/auth/htpasswd
AuthGroupFile /usr/local/apache/auth/htgroup
AuthType Basic
<Limit GET POST>
require group demo
</Limit>
</Location>
and aliasing some locations, restricting access, etc. I am not sure if
the encryption of Tomcat Apache communication is supported at this moment.
Yes, the is a bleeding edge, and there is not much documentation,
and you need to look up the comments in the files and source code, or
simply try, to know what is happening.
The Tomcat has its config files too, the: $TOMCAT_HOME/conf/server.xml,
the $TOMCAT_HOME/conf/web.xml, and the web.xml files in
each directory. The are some other files, in the $TOMCAT_HOME/conf
directory, but I do not think that they are being used at this moment. Either
these are things which will be used one day, or they were used one day, and
stay in conf just in case they will be needed again.
The $TOMCAT_HOME/conf/server.xml is the file which you will change
most likely, especially to add new contexts, i.e., essentially new
web applications. The typical entry looks like this:
<Context path="/mytests"
docBase="/usr/local/apache_t3.1b1/htdocs/jkltests" debug="0"
reloadable="true" />
where the
- path sets the path to this context in URLs, e.g., the
URLs http://www.webette.com/mytests/index.jsp or
http://www.webette.com/mytests/servlet/HelloWorld could be
referring to this context.
- docBase points to the disk directory which holds the web
application. Note that directory name does not have to be the same
as the URL path. This does not have to be an absolute path. The
relative paths will be appended to $TOMCAT_HOME/webapps.
- reloadable tells the Tomcat if it should reload the
JSP page, when its source was changed.
There are other options here, so you need to read the docs which come with
Tomcat. Another popular place to change is the Connector section.
<Connector
className="org.apache.tomcat.service.SimpleTcpConnector">
<Parameter name="handler"
value="org.apache.tomcat.service.http.HttpConnectionHandler"/>
<Parameter name="port" value="8080"/>
</Connector>
<Connector
className="org.apache.tomcat.service.SimpleTcpConnector">
<Parameter name="handler"
value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/>
<Parameter name="port" value="8007"/>
</Connector>
The first connector, HttpConnectionHandler, refers to the fact that
Tomcat is also a small Web Server, which works on the port 8080 by default.
It is great for debugging, but in production environment it may be a liability
since it leaves a backdoor for your Web contents, which you cannot protect
with password and/or HTTPS protocol. You can change the port to something
else (but the hackers with any basic port scanner [e.g., Satan or Saint] will
find it in no time), but essentially, in the production environment you simply
need to delete this portion or comment it out with a XML comment:
<!-- -->. The second connector,
Ajp12ConnectionHandler, is the one which manages the communication
with Apache. It is not needed when you use Tomcat as a standalone Web Server.
However, you have to have it if Tomcat communicates with Apache. The default
port is 8007, and you need to change it when you have this port reserved
by something else (e.g., a second installation of Apache which usis the
JServ. The $TOMCAT_HOME/web.xml sets default and
operational environment for the Tomcat server. You probably do not want to
change it, but in case you want, you need to read the comments in the
twin file, the Document Type Definition fileweb.dtd which explains
the structure and the meaning of the web.xml. Find the rest in the
$TOMCAT_HOME/docs directory, check the official site
http://jakarta.apache.org.
and you may also try to look at my brain dump at:
http://www.ccl.net/cca/software/UNIX/apache/
Back To Questions List
-
When you install Tomcat 3.1beta1, the examples of web applications
will be located under directory $TOMCAT_HOME/webapps.
For the real stuff, it is probably not where you want your
Web Applications to be located. You want them in your Web Documement
Tree. For example, for apache, by default, it will
be $APACHE_HOME/htdocs.
Assuming that your web application is located in the directory
/home/joeshmoe/mystuff/Shop, and you want to access it
as: http://www.mycomp.com/Shop/ you may want to move it
to $APACHE_HOME/htdocs, i.e, create directory
$APACHE_HOME/htdocs/Shop. Note, that you can mount and serve
on the web any directory which is accessible on your computer. The issue
is that from the maintainance perspective, it is nice to have things
in the expected place, i.e., under Web Server Document Root directory.
But if you just moved it there, and did not change the configuration
files, Apache would serve this directory as regular files, and
Tomcat would not even know about it. To have this
directory served by Apache via Tomcat, you need to block direct
access to WEB-INF directory (or even the whole application) through
Apache, and make Apache send requests
to this directory to Tomcat rather than serve the directory directly.
To do that you need to:
mount directory as a context for Tomcat but block the direct
access to WEB-INF subdirectory, so the regular HTTP
Apache requests to this directory end up as "Forbidden".
These lines in
$TOMCAT_HOME/conf/tomcat.conf should
take care of it for the example described above:
ApJServMount /Shop /root
<Location /Shop/WEB-INF/>
AllowOverride None
deny from all
</Location>
Register this context in
$TOMCAT_HOME/conf/server.xml
<Context path="/Shop"
docBase="/path/to/document/root/Shop"
debug="0"
reloadable="true">
</Context>
Of course, replace the paths/names given here with your actual
paths and names. In this case, since the name of your Web application
top directory is the same as the name with which it will be referred
to in the URL (i.e., Shop), you are OK if you deny access to
the WEB-INF in Apache. Hower, if you wanted to serve the
Web Application on the Web under the different name, say, you want
to mount it as Boutique, your approach would be:
ApJServMount /Boutique /root
<Location /Boutique/WEB-INF>
AllowOverride None
deny from all
</Location>
<Directory /path/to/document/root/Shop >
AllowOverride None
deny from all
</Directory>
Now, you need to place the info also in the
$TOMCAT_HOME/conf/server.xml
<Context path="/Boutique"
docBase="/path/to/document/root/Shop"
debug="0"
reloadable="true">
</Context>
Of course, replace the paths/names given here with your actual
Back To Questions List
-
You can actually make yourself a small UNIX script ahich takes a servlet
as a parameter. This way, it will not change you your current environment
but it will make sure that you have all the needed classes. For example:
============== cut ===========
#!/bin/sh
JAVA_HOME=/usr/local/jdk1.2.2 (or /usr/java1.2 under Solaris)
export JAVA_HOME
TOMCAT_HOME=/usr/local/apache_t3.1b1/sources/build/tomcat
export TOMCAT_HOME
PATH=${PATH}:${JAVA_HOME}/bin
export PATH
CLASSPATH=${JAVA_HOME}/lib/tools.jar:${JAVA_HOME}/lib/dt.jar:${TOMCAT_HOME}/classes
export CLASSPATH
javac $1
============== cut ===========
You may want to change of the TOMCAT_HOME.
Back To Questions List
-
Let us assume that the Document Root of your Apache Web Server
is /home/www. Now, you have some Web application in the physical
directory /home/www/jkltests. You need to add the following lines to
$TOMCAT_HOME/conf/tomcat.conf file to mount the web application:
ApJServMount /mytests /root
<Location /mytests/WEB-INF/ >
AllowOverride None
deny from all
</Location>
<Directory /home/www/jkltests >
AllowOverride None
deny from all
</Dierectory>
This will mount the mytests web application and Apache will forward
all requests of a type:
http://www.wearebig.com/mytests/something to Tomcat. Moreover,
while latest version of Tomcat does it automatically, we explicitly
deny access to any URLs like
http://www.wearebig.com/mytests/WEB-INF/something. Moreover,
since we actually mounted the web application with a different name
(mytests than its top directory (jkltests), and since the
application top directory is located within the Web Server Document Tree
(Document Root for Apache is here /home/www), we need to tell
Apache not to URLs like http://www.wearebig.com/jkltests/something
to anybody (deny from all). Once we are done with tomcat.conf
we need to inform Tomcat about the application by adding the information
to the $TOMCAT_HOME/conf/server.xml file:
<Context path="/mytests"
docBase="/home/www/jkltests" debug="0"
reloadable="true" />
Let us assume that you have the following files in
/home/www/jkltests:
/home/www/jkltests:
drwxr-sr-x 3 root www 512 Apr 1 04:56 WEB-INF
-rw-r--r-- 1 root www 39 Mar 31 15:14 junk.html
drwxr-sr-x 2 root www 512 Apr 1 05:08 junky
/home/www/jkltests/WEB-INF:
drwxr-sr-x 3 root www 512 Apr 1 04:36 classes
-rw-r--r-- 1 root www 939 Apr 1 04:56 web.xml
/home/www/jkltests/WEB-INF/classes:
-rw-r--r-- 1 root www 1399 Apr 1 03:07 HelloYou.class
-rw-r--r-- 1 root www 1647 Apr 1 02:59 HelloYou.java
-rw-r--r-- 1 root www 1407 Apr 1 03:01 ServletHello.class
-rw-r--r-- 1 root www 1655 Apr 1 03:01 ServletHello.java
drwxr-sr-x 2 root www 512 Apr 1 04:35 sp
/home/www/jkltests/WEB-INF/classes/sp:
-rw-r--r-- 1 root www 1413 Apr 1 03:04 HelloJKL.class
-rw-r--r-- 1 root www 1660 Apr 1 03:04 HelloJKL.java
/home/www/jkltests/junky:
-rw-r--r-- 1 root www 146 Mar 31 22:55 junk.jsp
In this case, we only have servlets under
/home/www/jkltests/WEB-INF/classes directory.
The classes in /home/www/jkltests/WEB-INF/classes represent
servlets without any package statement, while the HelloJKL
class, in the sp subdirectory has the package sp;
declaration at the top. HelloJKL is also a servlet. If your deployment
descriptor in the /home/www/jkltests/WEB-INF/web.xml is empty, i.e.:
looks like:
?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2.2.dtd">
<web-app>
</web-app>
you can access these pages on web as:
http://my.machine.org/mytests/junky/junk.jsp
http://my.machine.org/mytests/junk.html
http://my.machine.org/mytests/servlet/ServletHello
http://my.machine.org/mytests/servlet/HelloYou
http://my.machine.org/mytests/servlet/sp.HelloJKL
However, when you put there a web.xml file like:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//\EN"
"http://java.sun.com/j2ee/dtds/web-app_2.2.dtd">
<web-app>
<servlet>
<servlet-name>JKL</servlet-name>
<servlet-class>sp.HelloJKL</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>JKL</servlet-name>
<url-pattern>/JKLservlet</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>JKL</servlet-name>
<url-pattern>*.jkl</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>You</servlet-name>
<servlet-class>HelloYou</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>You</servlet-name>
<url-pattern>/YouServlet/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>You</servlet-name>
<url-pattern>/us/him/her</url-pattern>
</servlet-mapping>
</web-app>
you will be able to access the servlet HelloJKL as:
http://heechee.ccl.net/mytests/servlet/JKL
http://heechee.ccl.net/mytests/JKLservlet
http://heechee.ccl.net/mytests/servlet/sp.HelloJKL
http://heechee.ccl.net/mytests/whatever/and/so/page.jkl
while the servlet HelloYou can be accessed as:
http://heechee.ccl.net/mytests/servlet/HelloYou
http://heechee.ccl.net/mytests/servlet/You
http://heechee.ccl.net/mytests/YouServlet
http://heechee.ccl.net/mytests/YouServlet/whatever.html
http://heechee.ccl.net/mytests/us/him/her
Back To Questions List
Thomas Oellrich wrote:
> Hello,
>
> Can anybody tell me whether it's possible to automatically load a servlet
> on startup of Tomcat? If yes, how? If no, is this feature intended for
> future releases? I couldn't find any information on this in the official
> documentation.
>
Use the <load-on-startup> element in your web.xml file, as described in the
Servlet 2.2 API spec. The data value determines the order in which the
startup servlets are loaded.
<servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>com.mycompany.servlets.MyServletClass</servlet-class>
<init-param>
<param-name>param1</param-name>
<param-value>value1</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>
Craig McClanahan
==============================
Note that there is no space around parameter names and values. The older
version of Tomcat were confused when there was a white space around
parameters names and values. But it may be fixed by now.
Back To Questions List
Tell tomcat to use another server.xml by putting in on the startup.sh
command line as:
bin/startup.sh -f /usr/local/mytomcat/conf/server.xml
Back To Questions List
- From: Andreas Siegrist <A.Siegrist@tv1.de> to
tomcat-dev@jakarta.apache.org
Tomcat 3.0
You may get the user name (and password) by decoding the
authorization string yourself. We are using a static method in a
utility class:
public static String getRemoteUser(HttpServletRequest request) {
String auth = request.getHeader("authorization"); // as send by apache
if (auth == null) return null;
try {
auth = new String((new
BASE64Decoder()).decodeBuffer(auth.substring(6)));
}
catch (Exception exc) {
exc.printStackTrace();
return null;
}
if (auth == null)
return null;
int pos = auth.indexOf(":");
if (pos < 0)
return null;
return auth.substring(0, pos);
}
Back To Questions List
-
The Basic Authentication with Apache is done with appropriate entries
specifying the Location Unfortunately, you cannot use
.htaccess file in the web application directory as of now, since
Apache does not see those files (it passes requests to Tomcat). However,
you can put the instructions into httpd.conf or tomcat.conf
to perform Basic Authentication before forwarding requests to Tomcat. For
example, to protect context path /examples (i.e., URL to web
application residing at http://www.mycom.com/examples) you put
something like (modify to taste):
<Location /examples>
AuthType Basic
AuthName "For internal users only"
AuthUserFile /usr/local/apache/auth/avspass
AuthGroupFile /usr/local/apache/auth/avspeople
AuthType Basic
<Limit GET POST>
require group avs
</Limit>
</Location>
You need to have the files avspass and avspeople
or whetever you want to call them already created.
Check the Apache docs how to do it. It is simple when you know it.
Note that this will work both for HTTPS and HTTP. You may want to
disable HTTP (i.e., unsecure) access to this directory, since Basic
Authentication with HTTP is a BIG SECURITY RISK -- password is sent
in the open, unencrypted.
Back To Questions List
-
In your server.xml find lines:
<Parameter name="port" value="XXXX"/>
and change XXXX to what you want.
- Remember that you need to run tomcat as a root if you want to use
ports lower than 1024
- If you change the tomcat port 8007 (i.e., the one with which it talks
to Apache Web server, you need to make the corresponding change
in the tomcat.conf file (the line: ApJServDefaultPort 8007).
Back To Questions List
-
Tomcat is a not only a piece which runs JSPs and Servlets and talks
AJP protocol to Apache web server. Tomcat is also a small,
web server. You can disable the tomcat web-serving activities
by commenting out the following portion of server.xml file
<!-- New HttpServer. -->
<Connector className="org.apache.tomcat.service.http.HttpAdapter">
</Connector>
i.e., changing it to:
<!-- Disabling web server on port 8080 by commenting out the line:
<Connector className="org.apache.tomcat.service.http.HttpAdapter">
</Connector>
-->
Then you need to kill and restart apache/tomkat.
Back To Questions List
-
Back To Questions List
-
You have a servlet myServlet.class in the web application under
.../tomcat/webapps/nero and you want to pass initial parameters
(arguments) to the servlet. The example of use is in the
$TOMCAT_HOME/webapp/test/WEB-INF/classes/ServletParam.java
and also look at $TOMCAT_HOME/webapp/test/WEB-INF/web.xml to see
how initial parameters are passed. In short:
You need to edit the file:
.../tomcat/webapps/nero/WEB-INF/web.xml and add there
this information between tags <web-app>...</web-app>:
<servlet>
<servlet-name>myServlet</servlet-name>
<servlet-class>myServlet</servlet-class>
<init-param>
<param-name>where</param-name>
<param-value>Rome</param-value>
</init-param>
<init-param>
<param-name>when</param-name>
<param-value>66</param-value>
</init-param>
</servlet>
This will set the initial parameters where="Rome" and
when="66".
Word of caution. The Tomcat 3.1 Beta 1 had a bug. When you had spaces
around the paramater and value in the init-param section, it was confusing
the Tomcat. Use the style above and do not leave the space around
parameter and value entries.
Back To Questions List
-
Kindly contributed by: Viv Gregory <vivg@layer3.co.uk>
Solving "http: can't resolve symbol ap_escape_uri"
or
How to make Tomcat 3.2.1 work with Apache 1.3.3
We have a legacy web server running Redhat 4.2 with a 1.3.3 Apache, when
I tried to integrate Tomcat 3.2.1 I found that the mod_jserv.so module
which is used to link Apache to Tomcat was generating an error;
httpd: can't resolve symbol ap_escape_uri
Out of curiosity I looked at the source to mod_jserv.so:
See: .../jakarta-tomcat-3.2.1/src/native/apache/jserv/*.c
I found that there was only one use of the string in the code (see
jserv_ajpv12.c) and figured that it was probably calling an internal
apache function.
I checked the source to Apache 1.3.3 and could not find the string,
however by searching for escape_uri I found many similar calls.
Significantly the Apache 1.3.3 code used escape_uri and the Tomcat code
used ap_escape_uri.
I changed the source in jserv_ajpv12.c to escape_uri so it would match
Apache 1.3.3.
install instructions.
cd jakarta.../src/native/apache/jserv
apxs -c *.c -o mod_jserv.so
This also initially failed producing a "command failed with rc=" type
error message, searching the web I discovered some instructions about
changing the environment variables in the apxs build program.
Here is a "diff apxs apxs.original.1.3.3" which shows the changes I made
[my changes]
< my $CFG_CFLAGS_SHLIB = '-fpic -DSHARED_MODULE'; # substituted via
Makefile.tmpl
< my $CFG_LD_SHLIB = 'gcc'; # substituted via Makefile.tmpl
< my $CFG_LDFLAGS_SHLIB = '-shared'; # substituted via Makefile.tmpl
---
[original 1.3.3 Apache]
> my $CFG_CFLAGS_SHLIB = ''; # substituted via Makefile.tmpl
> my $CFG_LD_SHLIB = ''; # substituted via Makefile.tmpl
> my $CFG_LDFLAGS_SHLIB = ''; # substituted via Makefile.tmpl
I also came across a note saying that one should in fact use the
following command to build the mod_jserv.so file.
apxs -c -0 mod_jserv.so *.c
This worked so I then put the mod_jserv.so in the correct
.../apache/libexec area and it was then possible to start Tomcat.
>From then on I could play around with the webapps examples and generaly
fool around with some simple jsp and servlets.
Viv Gregory.(Layer3 Systems Limited)
Back To Questions List