-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joel,
On 2/23/2011 10:47 AM, Joel wrote:
> On Wed, Feb 23, 2011 at 10:44 AM, Joel <felixtheratr...@gmail.com> wrote:
>> sackett-research-lab2b:opt joel$ sudo find /opt/Tomcat -type f | xargs grep
>> function2.basiceng.umr.edu
>> grep: /opt/Tomcat/conf/server: No such file or directory
>> grep: copy.xml: No such file or directory
It looks like you might not have enough "sudos" in there: I believe
xargs isn't being run as administrator, hence all the errors.
Try this:
sudo find /opt/Tomcat -type f -exec \
grep "function2.basiceng.umr.edu" "{}" \;
>> /opt/Tomcat/webapps/ROOT/index.jsp: <meta http-equiv="Refresh"
>> content="0;url=http://function2.basiceng.umr.edu/view";>
That looks promising.
>> /opt/Tomcat/webapps/view/acct_new.jsp:// "<a href=\"
>> http://function2.basiceng.umr.edu:8080/view/Accounting/confirm.jsp?id="; +
>> id + "\">"
This appears commented-out, but could be a problem.
There appear to be references to these things in various places:
>> /opt/Tomcat/webapps/view/test.html: <a href="
>> http://function2.basiceng.umr.edu:8080/view/cgi-bin/test.cgi";>Test</a>
Note that the port number here (8080) isn't the same as the very first
one (the META refresh, to port 80). It looks like the app "matured" over
some time and maybe graduated from 8080 to 80 and nobody went back and
cleaned things up.
The proper way to create a link in JSP back to the same site, allowing
for relocations of both hostname /and/ deployment directory (say, /foo
instead of /bar) is this:
<a href="<%= response.encodeURL(request.getContextPath()
+ "/cgi-bin/test.cgi") %>">link text</a>
There are better ways to do this these says (using JSTL, for instance),
but this will work with all versions of JSP... and if you're on Tomcat
4.1 you'll need all the backward-compatibility you can get. :)
>> Feb 23, 2011 10:41:51 AM org.apache.struts.util.PropertyMessageResources
Oh, if you're using Struts, you can use the Struts taglibs to create
URLs for you. Assuming you don't really want to mess with too many
things just yet, I'll leave that discussion for later if you want.
Now, the fun part:
>> Feb 23, 2011 10:41:52 AM org.apache.coyote.http11.Http11Protocol start
>> INFO: Starting Coyote HTTP/1.1 on port 8080
HTTP connector on port 8080.
>> Feb 23, 2011 10:41:52 AM org.apache.coyote.http11.Http11Protocol start
>> INFO: Starting Coyote HTTP/1.1 on port 80
HTTP connector on port 80.
>> Feb 23, 2011 10:41:52 AM org.apache.jk.common.ChannelSocket init
>> INFO: JK2: ajp13 listening on /0.0.0.0:9007
AJP13 (aka mod_jk) connector on port 9007.
>> Feb 23, 2011 10:41:52 AM org.apache.jk.server.JkMain start
>> INFO: Jk running ID=0 time=1/8 config=/opt/Tomcat/conf/jk2.properties
Fantastic: it's running mod_jk2. Oddly enough, mod_jk2 is out of date
when compared to mod_jk. mod_jk2 was an abortive attempt to improve on
mod_jk... then mod_jk caught up and got better and mod_jk2 wasn't necessary.
Were these the latest "Starting Coyote" messages in the log file? When
constantly starting and stopping, it's easy to lose track of what
messages came from which startup. I recommend deleting the
logs/catalina.out file before you start with a new configuration just to
avoid confusion.
>> tcp46 0 0 *.9007 *.* LISTEN
>> tcp46 0 0 *.http *.* LISTEN
>> tcp46 0 0 *.http-alt *.* LISTEN
Those appear to be Tomcat.
>> without:
>>
>> sackett-research-lab2b:bin joel$ netstat -a | grep LISTEN
I don't see any :http and :http-alt, so this probably means that Tomcat
is listening properly. No port binding errors in the log file is also a
good indication.
> About the server.xml I must not have looked very closely, I think this is
> what you want.
Looks like the right stuff, thought many are commented-out. Let's look
at the enabled connectors (should be no surprised, given the log output
from above):
> <!-- Define a Coyote/JK2 AJP 1.3 Connector on port 9007 -->
> <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
> port="9007" minProcessors="5" maxProcessors="75"
> enableLookups="true" redirectPort="8443"
> acceptCount="10" debug="0" connectionTimeout="0"
> useURIValidationHack="false"
>
> protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>
AJP13 connector on port 9007.
That's all: there must be more somewhere else.
So... back to the original question: what's going on?
Are the messages you are getting coming only from Safari? Can you track
the HTTP messages that are actually being sent? It's tough to tell
what's going on just from Safari error messages (which are somewhat
"friendly" and try to interpret the situation instead of telling you
exactly what happened).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1lMRgACgkQ9CaO5/Lv0PB4JQCgm1+fjsOx9RSBkeeEdiV3Kvis
BUYAmQHWluZIsa5JpwHP75eqS9RheUwY
=lJjY
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
