This just keeps getting weirder and weirder.
I extracted the actual request
> https://maps.googleapis.com/maps/api/geocode/json?key==
from where it had been logged to catalina.out, and built a simple
program to feed it to Scott Klement's HTTPAPI, an open-source HTTP
interface for OS/400-native
Running Tomcat on various AS/400s (V6R1 or later OS), we've found that
shutdown.sh doesn't reliably shut down the server, and we frequently
have to shut it down forcibly (i.e., finding CATALINA on a WRKACTJOB,
and giving it a 4 with OPTION(*IMMED)).
Port 8009 does appear to be open before we
Konstantin Kolinko wrote:
2. Shutdown command is sent to port 8005. (8009 is a port used by AJP
protocol connector).
Thanks. That at least clears up a misconception on my part. Researching
it cleared up another misconception on my part: that the Catalina job
directly owns the ports.
Christopher Schultz wrote:
Maybe use DMPJVM? Sorry for the through-Google link [PDF]:
THANKS! Never heard of such a thing until you brought it to my
attention, and it's enough of an eye-opener that I would have gladly
forgiven even a through-LMGTFY link.
DMPJVM looks like it may be just
Alissa Schneider wrote:
Still, when I visit https://localhost:8443, the browser throws a
certificate warning. When I click on the certificate warning and view
certificate, it displays information on my self-signed certificate
(that I've deleted). I think if I could figure out how to make Tomcat
We have a situation:
A Tomcat server with a number of contexts.
One of those contexts should be available unsecured on port 8080.
The others should only be available secured, on port 443.
Is there a way we can restrict 8080 to the one unsecured context?
--
JHHL
Caldarale, Charles R wrote:
Read the servlet spec, chapter 13 (the 3.0 version is, unfortunately, harder to
comprehend than the earlier versions). Put the following in the
WEB-INF/web.xml of the webapps you wish to restrict to HTTPS:
user-data-constraint
Christopher Schultz wrote:
This is what I get from my own web.xml:
0003c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31
? x m l sp v e r s i o n = 1
0202e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 49 53
Reversing the flow to
od -t x1a web.xml | head -n 5
shows the correct hex values. But then it shows the character values as
if interpreting them in EBCDIC.
This suggests that there's a good reason why head and od aren't in
the manuals for QSHELL (the unix-like interface that was added to
Pid * wrote:
Examine the first few bytes of the input. I seem to remember a
character encoding issue causing this error.
Of what input in particular? At least some of these exceptions appear to
be getting thrown in the process of bringing up Tomcat, so I'm guessing
we're not talking about a
Mark H. Wood wrote:
I have no idea what DCM is or does. Maybe it works with PKCS #12
files, which can carry both parts in a single container.
That part isn't really relevant here (I hope), but to clarify:
DCM = Digital Certificate Manager. It's part of the IBM Midrange
operating system
We have a customer (who shall remain nameless), who had previously
ignored our instructions and used IBM DCM instead of Keytool to produce
a keystore, and had it signed, all the while blissfully ignorant of the
fact that none of it would be the least bit compatible with Tomcat.
I just got an
I have just wiped the Tomcat installation on the V5R4 box in question,
and done a clean install of 7.0.25.
No change in its behavior.
I tried a modified version of our standard Tomcat-launch CL program,
that adds a CATALINA_OPTS environment variable, with a value of
-verbose:class (excerpt
Tim Watts wrote:
I made some suggestions to this effect the other day:
http://tomcat.10.n6.nabble.com/Tomcat-7-0-25-on-an-AS-400-V5R4-Another-try-Help-td4984199.html#a4984215
Maybe you already tried them or didn't get the email.
Thanks for the link. I'm guessing that the email probably got
Tim Watts wrote:
http://tomcat.10.n6.nabble.com/Tomcat-7-0-25-on-an-AS-400-V5R4-Another-try-Help-td4984199.html#a4984215
- Add these lines to the end of conf/logging.properties:
org.apache.catalina.startup.Bootstrap.level = ALL
Tim Watts wrote:
import java.io.File;
import java.net.URL;
import java.net.URLClassLoader;
public class FindClass {
public static void main(String[] args) {
try {
URLClassLoader loader = new URLClassLoader(
new
To recap, I've got a situation where Tomcat is crashing on takeoff, on a
V5R4 AS/400, with what appears to be the same setup that works fine on a
V6 box, and showing correct environment variables in the STDOUT spool
file, and leaving this in Catalina.out.
java.lang.ClassNotFoundException:
Christopher Schultz wrote:
export -s JAVA_OPTS=-Dos400.awt.native=true
-Djava.awt.headless=true -Xms256m -Xmx512m
In my catalina.sh script.
FYI it is recommended to customize catalina.sh by creating a setenv.sh
script and using that. That way, you don't have to play games with
updating
Theoretically, I've ironed out the bugs concerning which JVMs Tomcat
will run under, but it still isn't coming up.
The STDOUT from attempting to start Tomcat is as follows:
/wintouch/tomcat/bin/catalina.sh: 001-0019 Error found searching for command
tty. No such path or directory.
Using
Tim:
This is normally in TC_HOME/lib/catalina.jar.
A. Does it exist there?
B. Does the user the process is running as have permission to read
that file and directory?
C. If yes to A B, is the file corrupt?
/wintouch/tomcat/lib/catalina.jar exists. I had to FTP it
David kerber wrote:
If I'm not mistaken (which is definitely possible), if you name it
ROOT.war, it will also become the default context.
Quite true. Even a neophyte like me is aware of that. ;-p
(And there's a lot more about Tomcat that I *don't* know, than there is
that I *do* -- it was
We just had a report of extremely high CPU usage from the Tomcat job on
one of our customer installations. A WRKACTJOB screen shot from before
we forcibly shut Tomcat down and restarted it shows:
Subsystem/Job Type CPU % FunctionStatus
CATALINA BCH .0 CMD-QSH
In my experience, shutdown.sh has never worked reliably on AS/400, and
I don't know why, or even understand enough about how it works (or
enough about shell scripts) to troubleshoot it.
Can somebody shed some light on it?
--
JHHL
In my experience, Tomcat's shutdown.sh has never worked reliably on
AS/400, and I don't know why, or even understand enough about how it
works (or enough about shell scripts) to troubleshoot it.
Here's the script. I can tell that it eventually transfers control to
catalina.sh (which is also
. . . and when I looked back at the box I was testing, Tomcat *had*
finally shut down. And when I ran both the start and stop scripts this
time, the stop script worked perfectly (and promptly).
Weird. Why would the shutdown take so long as to give the impression it
had failed entirely, then
We're attempting to bring up apache-tomcat-7.0.25.zip on a customer's
AS/400, the same as we've done on several other AS/400s (including our
own), and it's not working.
In catalina.out, I'm seeing this:
Jun 18, 2012 11:36:23 AM org.apache.catalina.core.AprLifecycleListener init
Found the problem:
The lines
# Java 6 settings if needed
export -s JAVA_HOME=/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre
export -s CATALINA_HOME=/wintouch/tomcat
Mark Thomas wrote:
On 18/06/2012 22:02, James Lampert wrote:
Found the problem:
The lines
# Java 6 settings if
needed
export -s
JAVA_HOME=/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre
# Java 6 settings if needed
export -s JAVA_HOME=/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre
export -s CATALINA_HOME=/wintouch/tomcat
export -s JAVA_OPTS=-Dos400.awt.native=true -Djava.awt.headless=true
-Djava.version=1.6 -Xms256m -Xmx512m
I just tried moving them out of bin/catalina.sh and
We are having a very frustrating error on one customer box, with a
Tomcat version and a WAR file that are working perfectly elsewhere.
That same WAR file runs perfectly on this same box, if expanded from the
command line.
Can anybody here shed any light on this?
--
James H. H. Lampert
Konstantin Kolinko wrote:
. . .
In essence it checks that File.getCanonicalPath() of (webapp root
directory + archive entry) is as expected.
at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:122)
My colleague at the next desk found this:
Victoria Johnson - Kio wrote:
The text on Apache is really confusing me about setting up SSL on
Tomcat,
what do I do with this command
%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA
Well, first you need to be sure you're NOT running this on an AS/400.
For some reason, Keytool
Anybody know what to make of this?
Here's the scenario: Tomcat 7.0.25 freshly installed on an AS/400
running V6R1. The box has no port restrictions set up in it. The only
ports in use, in the 8000-8099 range are 8000, 8001, 8005, and 8035.
I launch Tomcat, and 8080 and 8009 both open up.
I notice that the self-signed certificates I've been generating have the
default 90-day validity period.
Does this have any bearing on the validity period once I get the
keystore signed by a CA?
--
JHHL
P.S.: I haven't heard from anybody, here or on the Java400-L list, since
I posted the
We're now trying to bring up Tomcat 7 on a V5R4 AS/400, after
successfully doing so on V6 and V7 boxes. They have Java 6 installed,
and I'm told that they installed some PTFs over the weekend, but it's
still crashing on takeoff.
In catalina.sh, we have:
# Java 6 settings if needed
Christopher Schultz wrote:
Did you also put your server's key into the keystore?
It seems that when the customer rep jumped the gun and submitted a CSR
to Thawte before we even had Tomcat running on a self-signed
certificate, he did so using IBM DCM, whose keystores are incompatible
with
Caldarale, Charles R wrote:
One thing you didn't tell us was exactly how you start Tomcat. Have
you tried starting Tomcat from a command prompt so you can see the
display of the derived variables, such as CLASSPATH?
We start it from a variation of the OS/400 CL program given in this blog
Ognjen Blagojevic wrote:
You must find keystore with earlier generated key pair (the one you also
used to generate CSR for CA), and import all three certificates into
that keystore.
Dear Ognjen:
Thanks. That does sound vaguely like something we went through ourselves
some years ago, when
Ognjen Blagojevic wrote:
You must find keystore with earlier generated key pair (the one you also
used to generate CSR for CA), and import all three certificates into
that keystore.
Dear Ognjen:
At this point, I still don't have the keystore used to generate the CSR,
but I *do* now have
So far, I've had complete success using self-signed certificates, both
here and on the customer box, once I found out that the CN needs to
match the domain name.
But now, we're trying to get the customer box up on a CA-signed
certificate, and Tomcat doesn't like it. (Given that we haven't
I've now got the CA certificates the customer representative is trying
to use here, and I'm attempting to test them on our box.
I followed these instructions:
https://search.thawte.com/support/ssl-digital-certificates/index?page=contentactp=CROSSLINKid=SO15518
rather than the ones here:
Dear Igor (et al):
Thanks for getting back to me. To answer the questions (and pose a few
more):
Igor Cicimov wrote:
Are you sure you have downloaded the correct intermediate certs?
I didn't download them myself; neither did I place the order. But I'll
pass this on to the fellow who did.
Mark H. Wood wrote:
As already pointed out, there's your problem. To identify a networked
service, the value of CN should be the FQDN of the host providing the
service. (This is why people suddenly became interested in securing
DNS: we are relying on it to validate certificate bindings to
Scenario:
I created a self-signed certificate for the box I was testing:
CN = James Lampert
OU = Development Lab
O = Touchtone Corporation
L = Costa Mesa
ST = California
C = US
I then installed it into the Tomcat server on that box. Connecting to
the site with Firefox, I was told
I created a self-signed certificate for the box I was testing:
CN = James Lampert
Pid * wrote:
The Common Name must match the domain name of the server as seen by the client.
Hmm. So where Keytool asks
What is your first and last name?
you answer not with what it's asking
Tim Watts wrote:
That's a possibility if it's padding the passwords as well. I'm not an
AS/400 expert by any means. Is /foo a preallocated file and if so could
the problem be with the way it was allocated?
The Java-400 list over at Midrange.com is also in on this (albeit not
this specific
Well, using a keystore created on my WinDoze box, and FTP'd to the 400
definitely works: Port 8443 came right up.
But that still leaves open the question of why on earth keytool fails to
create valid keystores on the 400, whether run from QShell or QP2Term.
Inquiring minds want to know.
I'm attempting to bring up SSL support in Tomcat 7, on an AS/400 (V6R1).
Tomcat itself runs nicely, but following the instructions on
http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html
I am consistently getting:
SEVERE: Failed to initialize connector [Connector[HTTP/1.1-8443]]
:
bar
What is your first and last name?
[Unknown]:
James Lampert
What is the name of your organizational unit
50 matches
Mail list logo
