Re: Tomcat 4.1.18, JDK 1.4.1, & Soap--Vuko's setup is similar tomine

[J M Craig/Alpha-G]

Hi Vuko,

Thanks for taking the time to provide so much info. Unfortunately, the 4.1.18 install of Tomcat is rather different (perhaps I should down-grade to something known!).

If you're using the JK2 connector, it'd be very similar, I'm sure.
Are you using the JK2 connector?

Very honestly I don't know what the JK2 connector is or,
more fundamentally, what is a "connector" in this context.

A "connector" is the piece of software that you can optionally use with Tomcat so that a webserver (such as Apache) can serve the static HTML portions of a JSP document. It is used for performance reasons or so you can use SSL or various other obscure reasons. It has (finally) occurred to me that perhaps I don't need to bother with linking Tomcat to Apache. Tomcat would almost certainly serve my purposes without being hooked into Apache. But it's already working so I'm not going to bother with undoing it, I guess. In any case, you're clearly not using this capability or you have a different connector; and that's apparently not the heart of the problem I'm facing anyway.

<snip>

So, the first question is: did you have to rebuild the soap.war with the
1.4.1 JDK?

No, I took the soap.war file that came with the soap-2_3_1 distribution and copied to the webapps
directory.

Great to know.

Here's what I've got in the server.xml file (and I'm unsure about the
correct form for the values for a .war file):

<Context path="/soap"
docBase="/var/tomcat4/webapps/soap"
debug="1"
reloadable="true">
</Context>

Should the PATH value be "/soap" for a .war file (that is, it looks like
it's specifying a directory?). I assumed it should since the .war file
gets expanded into a directory, doesn't it?

<snip>

I've taken the Context entry out of the server.xml file.

As to the JK2 connector side, I've added this to the workers2.properties
file (matches the pattern for the /examples/ directory that comes with
Tomcat): <snip>

This wouldn't make any sense if you aren't using the JK2 connector; so let's not bother with it.

The instructions relating to Tomcat don't seem to match up with what's
installed on my system (I don't find any .sh files, for
instance--maybe I should look harder?)

You wrote:

The startup.sh and shutdown.sh scripts are in $CATALINA_HOME/bin/ directory as are these
other scripts.

~/jakarta-tomcat-4.1.12-LE-jdk14 > ls bin/*.sh
bin/catalina.sh bin/jasper.sh bin/setclasspath.sh bin/startup.sh
bin/digest.sh bin/jspc.sh bin/shutdown.sh bin/tool-wrapper.sh

This has been a major source of my confusion. There are no .sh files in the ~/bin directory (there's three JAR's and that's it). Well, it turns out that the Tomcat 4.1.18 version doesn't have any .sh files. What it does have is a single script file for startup and shutdown in /usr/bin called dtomcat4. There's also a series of other scripts which I haven't looked at as closely. The whole set is:
dtomcat4
tomcat4
reloctomcat4
jspc4
jasper4
djasper4

So, the whole structure's different from the directions. (When will I learn that there's never any decent info about the latest revs?) It seems that dtomcat4 corresponds to catalina.sh. It's opening comment line is:

# Start/Stop Script for the CATALINA Server

--at any rate, I can't see how to change the
CLASSPATH settings as described for earlier versions of Tomcat.

There are lines in /usr/bin/dtomcat4 that suggest they're the place for this:
...
# Set standard CLASSPATH
CLASSPATH="$JAVA_HOME"/lib/tools.jar

# Add on extra jar files to CLASSPATH
if [ -n "$JSSE_HOME" ]; then
CLASSPATH="$CLASSPATH":"$JSSE_HOME"/lib/jcert.jar:"$JSSE_HOME"/lib/jnet.jar:"$JSSE_HOME"/lib/jsse.jar
fi

# JPackage JSSE location check
if [ -r "$JAVADIR/jsse/jcert.jar" ]; then
CLASSPATH="$CLASSPATH":"$JAVADIR"/jsse/jcert.jar:"$JAVADIR"/jsse/jnet.jar:"$JAVADIR"/jsse/jsse.jar
fi

CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/bootstrap.jar
...

I may be doing the wrong thing, but I modified
the class path (added a few libraries to it)
by editing the file $CATALINA_HOME/bin/catalina.sh

Well, I've found the spot to do that, but I think all the libraries needed are already in the $CATALINA_HOME/common/lib or ~/endorsed directories. I downloaded the so-called "full" rpm from the Jakarta distribution directory because the LE version didn't want to work--I think I know why that was now, but the full install surely should have everything it needs (see below).

According to the documentation on:
http://ws.apache.org/soap/docs/install/index.html
you need:

- mail.jar from JavaMail - activation.jar from JavaBeans Activation Framework - a JAXP compatible, namespace-aware XML parser such as Apache Xerces
(v1.1.2 or later).
If you have other non-namespace aware XML parsers on your classpath
then the
namespace-aware parser must be at the front of your classpath. Apache
SOAP will not
work otherwise.
I have included mail.jar, activation.jar and xerces.jar in
my CLASSPATH (by manual editing of catalina.sh, it would
probably be cleaner just to copy those in shared/lib/)

I read that about what was required; I also read (in various places) that the requirements for JDK 1.4 were somewhat different so I appreciate knowing what you've done as an indication of what information to pay attention to.But, unless there's something rather subtle wrong with the set-up I have, I don't see how this can be the problem I'm facing because all the required JAR files appear to be in either of these directories:

$CATALINA_HOME/common/lib
$CATALINA_HOME/common/endorsed

The one exception is Xerces.jar--what I've got in the endorsed directory is these two:
xml-commons-apis.jar
jaxp-parser-impl.jar

Now, I suppose this last one might conceivably not be the appropriate one (that is, it might not be XML namespace-aware like Xerces), but since it comes with Tomcat, that seems possible so I'll stick Xerces in and see if that makes a difference.

At this point, the only clue to the whole mess I have is that at least I've finally found the scripts! Apparently the dtomcat4 corresponds to the catalina.sh script from earlier releases. However, it's still unclear:

1) Whether there's any reason Tomcat wouldn't find the classes it needs to run the Soap server (but the XML parser may be faulty).
2) What the error log messages mean....

Thanks for your suggestions and the time you've taken. I'm seriously going to consider down-grading to an earlier version of Tomcat; feeling my way blind just hasn't worked well.

John