Deme Carv wrote:
I am getting the error from subject when running the below code in
Websphere in my RAD. It is very interesting that this code doesn't cause
any error in Server. The server runs up Tomcat 6 but I must set the same
code to run in Websphere.
Well, if it is working in Tomcat but
André Warnier wrote:
Deme Carv wrote:
I am getting the error from subject when running the below code in
Websphere in my RAD. It is very interesting that this code doesn't cause
any error in Server. The server runs up Tomcat 6 but I must set the same
code to run in Websphere.
Well, if it is
On Thu, Jul 31, 2014 at 8:13 PM, Deme Carv demec...@gmail.com wrote:
I am getting the error from subject when running the below code in
Websphere in my RAD. It is very interesting that this code doesn't cause
any error in Server. The server runs up Tomcat 6 but I must set the same
code to run
I recently uninstalled Tomcat 6 and installed Tomcat 7.0.42 on a Windows Server
2008 R2. Tomcat is installed as a service on this machine, set to
automatically start at system boot. There is also an icon in the tray of the
service account that owns the software to start and stop Tomcat.
I am developing a COMET application that is primarily based on the example
given on the documentation of the chat server. My problem is that when two
users connect, the connection held open by the comet servlet is closed. I
know this because I am getting END events in my log.
The confusing part
TC 7.0.54 / RHEL 6
I have two physical servers, each running an instance of TC. The servers
are behind a hardware loadbalancer. IPTables is routing request on 80 to
8080. Tomcat runs under a non-root user. All good.
I needed to protect an area of our webapp under SSL. Went ahead and
installed
ok looks like i have the configuration of
org.apache.catalina.valves.CometConnectionManagerValve
wrong. sorry about that. Still have the random disconnect error though
On Fri, Aug 1, 2014 at 10:46 AM, Elias Kopsiaftis yemi...@gmail.com wrote:
I am developing a COMET application that is
On Fri, Aug 1, 2014 at 11:13 AM, John Smith tomcat.ran...@gmail.com wrote:
TC 7.0.54 / RHEL 6
I have two physical servers, each running an instance of TC. The servers
are behind a hardware loadbalancer. IPTables is routing request on 80 to
8080.
This seems unnecessary. If you have a
Fistlly, thank you both of all for answering. I am very glad for very rapid
comments. I attached a file in my original question which tells the jar I
have in both situation. I guess it might not be delivered to the forum. I
know that there is RAD involved but there are as well apache libraries
Daniel Mikusa wrote:
On Fri, Aug 1, 2014 at 11:13 AM, John Smith tomcat.ran...@gmail.com wrote:
TC 7.0.54 / RHEL 6
I have two physical servers, each running an instance of TC. The servers
are behind a hardware loadbalancer. IPTables is routing request on 80 to
8080.
This seems unnecessary.
TC 7.0.54 / RHEL 6
I have two physical servers, each running an instance of TC. The servers
are behind a hardware loadbalancer. IPTables is routing request on 80 to
8080.
This seems unnecessary. If you have a hardware load balancer in front of
Tomcat, it is the only thing that
By the way, pardon my ignorance, but what's a RAD ?
I did look it up in Google, but it comes up with either Rite Aid Corporation or a unit
of nuclear radiation..
Deme Carv wrote:
Fistlly, thank you both of all for answering. I am very glad for very rapid
comments. I attached a file in my
On 01/08/2014 16:30, Daniel Mikusa wrote:
You probably want the SSL certificate installed on your hardware load
balancer. End client's browsers are going to connect to the hardware load
balancer, not Tomcat. Thus you'd want the certificate there so your end
users can benefit from it.
That
Sorry, it is my fault. Rational Application Development. Basicaly it is an
IBM version of Eclipse. Let's say, like there is a Spring version of
eclipse wich comes with Fabric server easily settled, IBM provides RAD wich
has easily setting of Websphere. I guess that I am facing the error because
Not contradicting anything Daniel is saying, but maybe something to add,
and maybe that's the missing part of the original puzzle :
If Tomcat is expecting HTTPS requests on port 8443, then any re-direct or
response that it is sending back is going to include that port number after
the
On Fri, Aug 1, 2014 at 11:54 AM, Mark Thomas ma...@apache.org wrote:
On 01/08/2014 16:30, Daniel Mikusa wrote:
You probably want the SSL certificate installed on your hardware load
balancer. End client's browsers are going to connect to the hardware
load
balancer, not Tomcat. Thus you'd
ok now it is properly configured(I was missing the slash at the end of the
tag), but Im still getting null for event subtypes. Any thoughts?
On Fri, Aug 1, 2014 at 11:18 AM, Elias Kopsiaftis yemi...@gmail.com wrote:
ok looks like i have the configuration of
John Smith wrote:
Not contradicting anything Daniel is saying, but maybe something to add,
and maybe that's the missing part of the original puzzle :
If Tomcat is expecting HTTPS requests on port 8443, then any re-direct or
response that it is sending back is going to include that port number
No, I am not really going that far. I am suggesting that that may be
the kind of thing that is happening, and that you may want to investigate
with a browser plugin, that the requests/responses are really what you are
expecting.
Your initial explanation was a bit confusing and lacking in
John Smith wrote:
No, I am not really going that far. I am suggesting that that may be
the kind of thing that is happening, and that you may want to investigate
with a browser plugin, that the requests/responses are really what you are
expecting.
Your initial explanation was a bit confusing
On Fri, Aug 1, 2014 at 11:58 AM, Deme Carv demec...@gmail.com wrote:
Sorry, it is my fault. Rational Application Development. Basicaly it is an
IBM version of Eclipse. Let's say, like there is a Spring version of
eclipse wich comes with Fabric server easily settled, IBM provides RAD wich
has
On 8/1/2014 12:35 PM, John Smith wrote:
No, I am not really going that far. I am suggesting that that may be
the kind of thing that is happening, and that you may want to investigate
with a browser plugin, that the requests/responses are really what you are
expecting.
Your initial
On Fri, Aug 1, 2014 at 11:49 AM, John Smith tomcat.ran...@gmail.com wrote:
TC 7.0.54 / RHEL 6
I have two physical servers, each running an instance of TC. The
servers
are behind a hardware loadbalancer. IPTables is routing request on 80
to
8080.
This seems unnecessary.
As your testing keep this process in mind. If you encounter a problem just
try to break down the flow from your browser to the server and back. If
you look at the request at each hop through this process, you can often
find where things went wrong. For example, did the request hit the LB?
Is your LB configured to listen on 8443, or on 443? It won't pick up the
port it's supposed to listen on from the TC instances; you have to specify
it.
Nailed it. Simplest solution, I didn't even consider it.
Thanks,
John
There is no response, since you are not even able to connect to that
IP:port.
If you are using the IP of the LB, then the LB is not accepting
connections on port 8443.
You won't get much further, unless you solve that first.
But I thought that you wanted your users to access via port 443
On 8/1/2014 1:33 PM, John Smith wrote:
Is your LB configured to listen on 8443, or on 443? It won't pick up the
port it's supposed to listen on from the TC instances; you have to specify
it.
Nailed it. Simplest solution, I didn't even consider it.
Thanks,
John
Thanks for letting us
On 01/08/2014 17:06, John Smith wrote:
On Fri, Aug 1, 2014 at 11:54 AM, Mark Thomas ma...@apache.org wrote:
On 01/08/2014 16:30, Daniel Mikusa wrote:
You probably want the SSL certificate installed on your hardware load
balancer. End client's browsers are going to connect to the hardware
In my webapp there's a directory '/admin' that's protected under SSL. Users
are forced to use SSL via a security constraint in web.xml. It works great.
As mentioned in the docs and other places, it would be good to prevent SSL
everywhere else on the site, but I searched around and couldn't find
Thanks for letting us know what the issue was; many people never come back
and tell us what fixed it.
My pleasure. This list is awesome.
TLS is layer 5 so if the LB is operating at layer 4 it can't host the
cert. Some LBs can operate at layer 5 so it will depend on your LB
and/or its configuration.
Mark
I see. That's good to know. The LB is at 7.
From: John Smith [mailto:tomcat.ran...@gmail.com]
Subject: Restricting SSL access within webapp
What's the correct way to selectively restrict https to only one area of a
webapp?
Why would you want to do that? Other than a few extra server CPU cycles,
what's the harm in allowing SSL
On Fri, Aug 1, 2014 at 4:34 PM, Caldarale, Charles R
chuck.caldar...@unisys.com wrote:
From: John Smith [mailto:tomcat.ran...@gmail.com]
Subject: Restricting SSL access within webapp
What's the correct way to selectively restrict https to only one area of
a webapp?
Why would you want
Why would you want to do that? Other than a few extra server CPU cycles,
what's the harm in allowing SSL anywhere at the client's discretion?
I'm with Chuck on that one.
From the docs:
Also, while the SSL protocol was designed to be as efficient as securely
possible, encryption/decryption
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
John,
On 8/1/14, 5:43 PM, John Smith wrote:
On Fri, Aug 1, 2014 at 4:34 PM, Caldarale, Charles R
chuck.caldar...@unisys.com wrote:
From: John Smith [mailto:tomcat.ran...@gmail.com] Subject:
Restricting SSL access within webapp
What's the
On Fri, Aug 1, 2014 at 1:55 PM, John Smith tomcat.ran...@gmail.com wrote:
In my webapp there's a directory '/admin' that's protected under SSL. Users
are forced to use SSL via a security constraint in web.xml. It works great.
I would also agree with Chuck and James.
Can you not move this
On 8/1/2014 6:06 PM, James H. H. Lampert wrote:
Why would you want to do that? Other than a few extra server CPU
cycles,
what's the harm in allowing SSL anywhere at the client's discretion?
I'm with Chuck on that one.
From the docs:
Also, while the SSL protocol was designed to be as
On 8/1/14 4:54 PM, David Kerber wrote:
I don't think the problem is so much bandwidth as it is server CPU.
Encryption and decryption are very cpu-intensive tasks.
Not to mention client CPU. (Let's face it, if somebody's on dial-up,
they're probably on an old, slow box, too. Like my G4 bionic
38 matches
Mail list logo
