-----------------------------
Please read the FAQ!
<http://java.apache.org/faq/>
-----------------------------
I found installing Apache and JServ somewhat labor-intensive and
error-prone, as others on the list have mentioned. Here are some of
the things we're doing to cope with it:
- Install Apache and JServ, together, from a short script.
This only needs to be the commands that you would type
normally, but putting them in a script documents them,
and ensures you won't forget one of the options. This also
saves time when you repeat the installation, and you can and
should repeat the installation (see below).
- Make a list of what needs to be adjusted in the config files
for your installation. Don't just take notes on the back of
a napkin; type them up and proofread them. This also serves
as good documentation. Ours includes explanations of why
things are configured the way they are, so that the rationale
for each choice is also documented. (Ours also starts with
a brief "theory of operation" that gives an introduction
to the different pieces of software, and different config files,
involved in getting everything working.)
The only drawback to our document is that it describes only the
things that need to be changed from the default configuration
for Apache 1.3.6 and Apache JServ 1.0. Future versions may
break our document; we'll wait and see.
- When you've got your configuration working, finally, tear the
whole thing down and reinstall it, using your notes. Correct
the notes wherever necessary. Yes, this takes longer, but it's
better to spend the time now than later on, when your servlets are
running in a production environment. The best way to understand
the install process is to repeat it a bunch of times.
- We've also built custom installers for our "major" servlets,
so that simply running the configure script, and then the
install script, will properly configure most items. This saves
a lot of time when moving a new version of one of our servlets
onto our production server, but again, it requires more of a
time investment up-front. We think it's going to pay off pretty
well, even for relatively small servlets, in the time saved
trying to debug servlet-specific configuration items.
- Write your own site-specific FAQ containing common mistakes
at your site. For instance, here are some items from ours
(note that some of the items are specific to our site).
Things To Check
---------------
- Is the name of the servlet wrong in the alias? i.e.,
.../servlet/PasswordAdmin/PasswordAdminServlet is correct,
.../servlet/PasswordAdminServlet is WRONG.
- Are ALL libraries contained in either your servlet code
repository or biology.jar?
- Is biology.jar current?
- is edu.ucsd.bio.util.FileLocker12 present? Is there
anything else that could be missing due to 1.1-1.2 JDK
differences?
- Check ALL log files (not just the one you think should
contain the info you're looking for).
- Check for jconnect40.jar in wrapper.classpath.
Switching on Truss Debugging (sometimes useful)
-----------------------------------------------------
- Expand .jar files, edit .properties file to point to
classes instead of jar file.
- truss -p -t \!poll PID (where PID is the pid of the VM)
- stat("some/path/file.class") Err#2 ENOENT often means
file.class is missing from the repository.
- Install multiple servers. We run three at the moment. One is
the production server, used by users. One is exclusively for
testing things that are believed to be ready to move to the
production server, and also serves to test our installers, and
any configuration changes that are are contemplated. A third
server is used during development, and is unique in that its
code repository points to a development copy of our CVS tree.
Originally we had two servers running on a different machine.
I tore those down and rebuilt them several times, before we
had any servlets in production. Then we decided to move to a
different machine, and the tools I had built for the first
machine helped out a lot. In total, I've probably installed
Apache and JServ about 15 or 20 times. I didn't wise up and
document things right away, and every new install had annoying
configuration problems that were time-consuming to find and
fix. With my documentation, and tools, the installs are quick,
there are fewer configuration problems, and when something
is screwed up, it can usually be found by going back over
the checklist.
- When you do change part of the configuration, be sure to document
not only what you changed, but why you changed it.
- Remember, revision control is your friend. If you're not using
something like RCS or CVS to track your config files, you
really should be.
To summarize: document the hell out of everything you do.
JServ installation is difficult, particularly the first few times you
try it. However, with practice, and good notes, it's definitely
manageable. The first time I installed it, I think it took a couple
of days. But at this point, I believe I could re-create our
configurations in just a few minutes.
I'd also like to point out that we originally started with JRun, but
its overwhelming abundance of configuration files (check sometime...
there are over 200 .properties files in a standard configuration!
Only about 50 are active, though, and only some of those need
changes... but which ones?) and the utter disorganization of the
files, was completely frustrating. JServ has only a couple of config
files, the comments in them are reasonably clear, and, with a little
practice, it seems a lot more manageable. This is in fact why we
decided to switch to JServ.
The JServ FAQ is definitely worth reading. However, it does have
limitations. In particular, it is not, and never will be, customized
to your site, your configuration, or your servlets. Such
documentation is extremely valuable, but you need to write it
yourself. [To be honest, I've never really liked Faq-o-matic style
FAQs, for JServ or any other projects, although can't say exactly why
not.]
Well, this is longer than I'd planned, but I hope it helps someone.
I'd also be interested in how other people are managing their JServ
installations.
Scott
--------------------------------------------------
Scott Kelley, [EMAIL PROTECTED]
Biology Computing Services, UC San Diego
--------------------------------------------------
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html/>
Problems?: [EMAIL PROTECTED]
