The Java version wasn't it. Recompiled and redeployed with 1.7.0_25
and it had no effect.
The SSL handshake problem went away when we disabled TLS 1.1/1.2 in the
JCP on the client side and clicked Restore Security Prompts in the JCP.
There was also a problem with JSESSIONID not being sent to
On 3/5/2014 12:52 PM, Konstantin Kolinko wrote:
Session cookie is HttpOnly in Tomcat 7.
If you missed that in migration guide, it is here:
http://tomcat.apache.org/migration-7.html#Session_cookie_configuration
I added this to some code that is executed by most requests that we use to
track
On 3/5/2014 2:28 PM, Konstantin Kolinko wrote:
The HttpOnly flag is used by cookies sent by server to the client.
There is no point checking it on request.getCookies(), as browsers do
not send it back (neither do they send 'path', 'secure' etc.).
Isn't that showing what the server is sending
On 3/5/2014 2:28 PM, Konstantin Kolinko wrote:
The HttpOnly flag is used by cookies sent by server to the client.
There is no point checking it on request.getCookies(), as browsers do
not send it back (neither do they send 'path', 'secure' etc.).
1. Isn't that what gets sent from the
Isn't the applet supposed to send browser cookies regardless of if
Javascript can see them?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
We tried to upgrade a production server to Tomcat 7 yesterday and it
broke our printing applet that we use to control a printer in its native
printer language.
This seemed odd to us because it worked perfectly in testing. When we
go direct to our production servers (bypassing the Cisco load
On 3/4/2014 9:40 AM, Bill Davidson wrote:
We tried to upgrade a production server to Tomcat 7 yesterday and it
broke our printing applet that we use to control a printer in its native
printer language.
This seemed odd to us because it worked perfectly in testing. When we
go direct to our
On 3/4/2014 11:01 AM, Christopher Schultz wrote:
On 3/4/14, 1:26 PM, Bill Davidson wrote:
I realized that I forgot a lot of info:
Tomcat 7.0.47 on RHEL 5.10 Apache httpd 2.2.25
It worked fine with Tomcat 6.0.37
The applet is bit-for-bit identical. It's built with Java 1.1
compatibility mode
On 3/4/2014 11:22 AM, Christopher Schultz wrote:
Aah, sorry, I had missed that. So, the only change was Tomcat? No
upgrade to mod_jk or anything like that? OpenSSL upgrade? Upgraded
Java on the client? Everything else *absolutely* the same?
Exact same httpd, including mod_jk. Same files.
On 3/4/2014 1:24 PM, Christopher Schultz wrote:
Well... then you'd need a balancer for each balancer ;)
Can you reproduce this issue yourself on your own computer (running
the applet locally)? If so, what version of Java is running?
That's mostly what I've been doing for the last 24 hours.
On 3/4/2014 3:13 PM, Mark Eggers wrote:
Hmm, is the applet signed, and is the certificate from a trusted authority?
Oracle recently made some changes to Java which tightened down applet security.
They also made some changes in the security policy that block communication on
well-known ports
On 1/23/2014 5:21 PM, Christopher Schultz wrote:
If you'd care to post your code to either the list or onto the wiki, I'm
sure it would be useful to someone. Feel free to trim-out huge sections
of the code and say make this fit your environment, etc. if you don't
want to show everyone how bad
On 12/11/2013 11:42 PM, André Warnier wrote:
The original issue of the OP was to be notified ASAP when an OOM occurs.
And he indicated that an OOM resulted in a message in the logs.
So, something is already catching the OOM exception, to write this line in
the logs.
On the other hand, there is
On 12/11/2013 7:14 AM, Christopher Schultz wrote:
3. cath IOException in a filter and set an application
attribute. Check this attribute from your monitor.
I've been considering doing this, because I can rig it so that
the error handler does not actually require any memory to run.
The problem
On 12/9/2013 5:20 PM, Bill Davidson wrote:
On 12/9/2013 3:12 PM, Christopher Schultz wrote:
1. Use -XX:OnOutOfMemoryError=cmd args;cmd args
Rig this to email you, register a passive-check data point with your
monitoring server, etc. Just remember that OOMEs happen for a number
of reasons. You
Last week, one of my servers got an OutOfMemoryError at approximately
1:21pm.
My monitoring software which does a heart beat check once per minute
did not notice until 3:01pm. Heart beat kept working for over an hour
and a half.
During that time my high capacity high availablity 24/7
On 12/9/2013 3:12 PM, Christopher Schultz wrote:
Was it a transient error, or a chronic condition? A single thread can,
for instance, spew objects into its stack or eden space exhausting
memory but, when that thread hits the OOME, all those objects are
freed which basically recovers from the
RedHat 5.6 64-bit
java -version output:
java version 1.6.0_20
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
Tomcat: 6.0.26
The -d64 option seems to be removed from the ps command line arguments:
I added a set -x
On 8/10/2011 2:57 PM, Caldarale, Charles R wrote:
1) In what way does this concern Tomcat?
I wasn't sure if it had something to do with the way it was launched.
2) Documentation for -d64 with a standard launcher seems to indicate it's only
applicable for Solaris (although some other tools
Tomcat 6.0.29
I've written a response filter for my web app and it seems to work fine
for servlets but not for JSP's. I
public void doFilter( ServletRequest request, ServletResponse
response, FilterChain chain ) throws IOException, ServletException {
chain.doFilter(request, new
version 1.6.0_20, Java(TM) SE Runtime Environment (build
1.6.0_20-b02), Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed
mode)
Tomcat: 6.0.26
I'm having trouble with a custom tag and I've tried to reduce the
problem to its most basic form:
/WEB-INF/tags/example.tag:
%@tag %
On 2/2/2011 2:17 PM, Konstantin Kolinko wrote:
I think you are bumping into JavaBeans capitalization rules. Rename
your attribute to be xname or xxName.
That worked. Weird.
-
To unsubscribe, e-mail:
On 2/2/2011 2:17 PM, Konstantin Kolinko wrote:
I think you are bumping into JavaBeans capitalization rules. Rename
your attribute to be xname or xxName.
That worked! Thanks!
I think that's a pretty weird thing.
-
To
On 8/30/2010 9:18 PM, Caldarale, Charles R wrote:
There's a lot of baggage implemented to support ThreadLocal. It's one of those
deceptively easy-to-use Java concepts that utilizes a lot of plumbing
underneath the covers (e.g., a specialized per-thread expandable hash map, weak
references).
On 8/31/2010 12:16 PM, Christopher Schultz wrote:
Or, just remove the ThreadLocal manually. Since you know it's name, it
should be easy to remove. There are two obvious ways to remove these
ThreadLocals in a webapp:
1. Modify all the code that uses the iCal4j library so that, after
performing
Sigh. Using Tomcat 6.0.26 and trying to use iCal4j to generate calendar
files so that date/time events in my app can be exported to the user's
calendar.
iCal4j uses static ThreadLocal's to protect SimpleDateFormat and some
other things. When I shut down Tomcat I get these disturbing messages:
On 8/30/2010 2:08 PM, Caldarale, Charles R wrote:
I'm not really clear on how ThreadLocal works.
http://download.oracle.com/javase/6/docs/api/java/lang/ThreadLocal.html
And, as usual, GIYF.
I actually had already read that, and a few other things I found in Google.
It still felt a
On 6/9/2010 2:15 AM, Altanis Alexandros wrote:
I have been reading about the new Tomcat DBCP in a couple of blogs
lately, as I am interested in Connection Pooling for an application I am
working on. Here they are:
http://vigilbose.blogspot.com/2009/03/apache-commons-dbcp-and-tomcat-jdbc.html
Elli Albek wrote:
2. If your JDBC driver supports caching of prepared statements and
metadata, do it in the driver and disable this in DBCP. IMO DBCP does
a poor job at best in caching. We use mysql and its JDBC driver is
doing an excellent job.
It didn't occur to me that that was available.
3.
Christopher Schultz wrote:
When you've played with it for a bit, tell us how things turned out.
It's looking like optimal is caching about 40 PreparedStatement objects.
However, I should qualify that noting that it's with our application and
specifically with our little pummeling benchmark,
of cursors
that can be open on a Connection.
Looks good to me. Not sure if it will have to wait for 1.3 or if they will
work it into the current documentation after some review.
Bill Davidson wrote:
Christopher Schultz wrote:
I see you've cross-posted to commons-user. That's good, but you probably
Christopher Schultz wrote:
I see you've cross-posted to commons-user. That's good, but you probably
want to file an actually bug report / enhancement request for the
documentation.
Filed. Key: DBCP-301
-
To unsubscribe,
Christopher Schultz wrote:
I'm curious about the usefulness of caching prepared statements in
general, though. What is the default maxOpenPreparedStatements setting
and what did you set it to in order to get it to work out well for you?
The default is unlimited, which is the problem. I've
Christopher Schultz wrote:
Uh, oh. Are you doing something like this:
Possibly. I didn't write that code.
If you're doing that, then you're probably making a big mistake. Are you
storing connections in sessions or anything like that? Yuk.
For certain transactional operations, I think it is.
Just thinking about this some more
So apparently, when I was using poolPreparedStatements=true, and
I did conn.prepareStatement(SomeSQLString), I was getting back a
Statement object created by DBCP to be pooled. When I called close()
on that statement, it did not really close(), which was
Bill Davidson wrote:
Could maxOpenPreparedStatements possibly fix this?
Apparently it does.
The DBCP config docs need a better warning on poolPreparedStatements:
*NOTE* - Make sure your connection has some resources left for the
other statements.
just doesn't quite cut it. Something more
Christopher Schultz wrote:
Is it possible that your server just doesn't want to allocate 245 * 4
cursors, and that you are just hitting that barrier?
cursor != connection
Oracle is set up to allow up to 300 cursors per session (connection).
I could up that limit, but it probably won't fix the
Martin Gainty wrote:
are you running as a Transaction?
In some cases, but a lot of these lingering cursors are on very simple
queries, with no insert/update/delete involved. As I said before,
I'm finding lingering cursors on things as simple as SELECT * FROM
some_table WHERE id = ?.
That does
Christopher Schultz wrote:
Probably not. DBCP calls setAutoCommit(true) by default in order to
reset the connection as it goes back into the pool. Any pending
transaction is committed (!) when that happens, so there shouldn't be
any in-progress transactions lingering around.
If you set
Redhat 5.2 Server
Java: Sun JDK 1.6.0_16 (64-bit)
Tomcat 6.0.20 (and whichever version of DBCP that includes)
Oracle 10g (10.2.0.3)
JDBC: ojdbc14.jar
I've been trying to convert an old J2EE application to use DBCP connection
pools from an old custom connection pool class (not a DataSource
Christopher Schultz wrote:
On 10/14/2009 2:17 PM, Bill Davidson wrote:
Redhat 5.2 Server
Wow.
Maybe I should have said RHEL 5.2. 5.3 would be the current
version, so it's actually not that old. RedHat's starting over with
the numbers does get confusing.
This config looks fine, though
Mohit Anchlia wrote:
Something like this:
(DESCRIPTION=(FAILOVER=ON)(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=x)(PORT=1526))(ADDRESS=(PROTOCOL=TCP)(HOST=)(PORT=1526)))(CONNECT_DATA=(SERVICE_NAME=somesid)))
I still haven't been able to locate the documentation,
Ognjen Blagojevic wrote:
IANA-failover-expert, but one question comes to my mind. What happens
when the first server is recovered? Some cached connections will still
point to second server, while newly created connections will go to the
first one?
Actually, it doesn't switch which is the
Tim Funk wrote:
I thought the Oracle JDBC driver allowed for all the nodes to be placed
into the connect string and the driver was smart enough to detect
failover.
[So its a configuration exercise on the connection string.]
I'm having trouble finding documentation for this capability. Can you
Tomcat 6.0.20 using DBCP DataSource
Java 1.6.0_16
Oracle 10g with RAC.
I've got two Oracle RAC nodes, mirroring each other. My current fail-over
method if the primary node fails is to shut down the web servers,
reconfigure
them to use the secondary node and restart the web servers. Not
Tomcat 6.0.18
Oracle 10g
Java 1.6.0_14
I'm a little curious about the defaultAutoCommit parameter.
If I understand the docs and things I've googled correctly, if I don't
set it, I get the JDBC driver default. More googling, suggests that
the default for the Oracle JDBC driver is to have
Mark Thomas wrote:
Alternatively, you could use a database view to present the two sets of
users as a single table.
What about duplicated user names between the two sides?
There's also the need to make sure that the admin side servlets are
not accessible to the public side and vice versa and
Tomcat 6.0.18
Java 1.6.0_14
RedHat 5.2 Server
Oracle 10g
I've got an old web app that was originally spec'd in 1999. Last year, I
got
it migrated from Tomcat 3.2.4 for 6.0.16 and more recently from Java 1.4.2
to 1.6. I'm gradually trying to modernize it. I just converted from using
an old
Rainer Jung wrote:
To simplify your research a little bit: you mentioned you switched
cookies off in order to use the jsessionid URL parameter to log the
session IDs.
If you keep cookies on, then you can also log the value of the
JSESSIONID cookie by using the %C syntax of Apache's CustomLog.
We're using LVS for load balancing to three separate Tomcat 6 servers.
We do not have session replication. We do use sticky load balancing,
or it wouldn't work.
The problem is, we're having some customers, specifically people in
parts of Australia and Malaysia, on wireless ISP's who are coming
Mark Thomas wrote:
Any reason you can't load balance based on the JVM route in the session ID?
Other than not being aware that it could be done or how to do it,
none that I know of.
Normally, we use cookies for the session id. Can LVS look at the
session id in a cookie?
Mark Thomas wrote:
Don't know. Never used it. Look for something in the docs around layer 7
load-balancing and/or cookies. If you are using https then your SSL will
have to be terminated at the load-balancer otherwise you won't be able
to see the session cookie or url.
Apparently LVS doesn't
André Warnier wrote:
Bill Davidson wrote:
...
Our application switches between them [HTTP or HTTPS] based upon
whether there is sensitive data in the page or not.
So I guess that if you did not do that, you would not be having this
issue.
Feasible ?
Non-trivial. Also, there is resistance
Rainer Jung wrote:
IfModule mpm_worker_module
StartServers 2
MaxClients 256
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 32
Usually MinSpaceThreads and MaxSpareThreads having a multiple of
ThreadsPerChild makes it easier
Christopher Schultz wrote:
Yes, most TCP/IP stacks use 127.0.0.1 as a special-case that avoids most
of the real stack and instead uses a kernel buffer as the data transfer
mechanism.
I just tried to benchmark my own system localhost versus a DNS name that
resolves to an IP address handled on
I'm trying to understand mpm_worker MaxCLients and it's relationship
with mod_jk connection_pool_size.
Here's what I've got at the moment:
OS: Red Hat 5.2 Server
httpd: 2.2.11
tomcat-connector: 1.2.28
tomcat: 6.0.18
Java: 1.6.0_13
httpd-mpm.conf:
ListenBacklog 2048
IfModule
Rainer Jung wrote:
Hey great, someone using recent version :)
I've been trying to stay current with the stable releases since upgrading
the app from httpd 1.3 and Tomcat 3.2.4 last year. I usually wait a
couple weeks to a month and watch the mailing lists after a release to
make sure nothing
Peter Crowther wrote:
From: André Warnier [mailto:a...@ice-sa.com]
Peter Crowther wrote:
I'm also particularly amused by the topmost set of bars in
figure 2, given how proud the perl-ites are of their RE
library and performance ;-).
You didn't expect for a minute that this would remain
Rainer Jung wrote:
In case you only want to exclude few methods from compilation,
-XX:CompileCommand=exclude,com/myCompany/servlets/sales/blah/some,method
will do it.
Since we put this change into production, we haven't seen the problem.
Thank you so much.
Okey Kene wrote:
Am using windows vista and i wish to know what version of apache tomcat
to download.
Are you planning to write webapps or are you only wishing to deploy
webapps you've acquired from other sources?
If you wish to learn to write JEE webapps, then I recommend the
latest version
Eric B. wrote:
I was listening to a webinar on spring source by Filip Hanik Mark Thomas
regarding tuning Tomcat for production in which they indicate that the Http
connector is recommended vs an AJP connector
(http://www.springsource.com/node/555).
I downloaded this webinar and
Bill Davidson wrote:
André Warnier wrote:
By the way, the reason why I can't try it right now is that I just
don't have the application to try it with. So whatever I mentioned
before (but which apprently so far seems ok) was purely by attempting
to understand the documentation. Beware.
I
Rainer Jung wrote:
You can track compilation with -XX:+PrintCompilation.
[...various other options...]
Wow. I never realized you could do stuff like that. Neat.
Thanks!
-
To unsubscribe, e-mail:
Caldarale, Charles R wrote:
Most of the 64-bit Sun JVMs come only in -server mode, no -client version. Run
java -version (without the quotes) to see what the default mode is.
Checking that...
$ ./java -version
java version 1.6.0_11
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java
Caldarale, Charles R wrote:
Only if that shows up repeatedly.
It does.
I'm thinking that the JVM shouldn't be getting SIGSEGV's.
You're right about that. However, it could also be an OS or
hardware problem. You might want to run some serious memory
tests on the box, just to eliminate
Caldarale, Charles R wrote:
Major changes went in between 6u7 and 6u10.
Maybe I should try reverting to 6u7?
I'm wondering if -Xint might help.
Only if you want performance to go into the toilet - that's
interpreter mode, also know as really, really, abominably slow.
I was thinking it
Bill Davidson wrote:
Caldarale, Charles R wrote:
Major changes went in between 6u7 and 6u10.
Maybe I should try reverting to 6u7?
Dammit. Looking back through my old hs_err*.log files,
it also happened with 6u7
Christopher Schultz wrote:
What about forwarding X through the tunnel instead?
I've tried that and found it to be unusably slow. Just using
Cygwin/X though. I'm not sure about those fancy light weight
X compression systems.
I really would like to be able to run these kind of tools across a
Tomcat 6.0.18
JVM: Sun 1.6.0_11 64-bit for Linux
What does this switch really do anyway? The name implies it's
for server programs but I can't find a good explanation.
-
To unsubscribe, e-mail:
I've submitted this to Sun a few times. No response. I was hoping
someone here might have an idea of what to look for.
Tomcat 6.0.18
RedHat 5.2Server
Sun JVM
#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x2b68e6a1db57, pid=10229,
Juha Laiho wrote:
However, have you actually measured how much load it would put to various
pieces of your system to not cache this data, but just fetch it from the
DB more or less each time it is needed?
We currently have the ability to turn the caching on or off. We
generally only
turn
Ken Bowen wrote:
Whoops, hold that. This is ok for outbound. For inbound, it seems
Jboss is needed: http://activemq.apache.org/jboss-integration.html
I'm not sure I understand how that says JBoss is needed to do inbound
communications.
There is a page on configuring Tomcat:
Is it possible to set up a callback like situation so that a trigger in an
Oracle 10g database can call a method in a currently running webapp
that's running in Tomcat 6?
My situation is that I want to cache some infrequently changed database
data in memory but when that data does change in the
Mark Thomas wrote:
1. JMS?
I thought Tomcat didn't support JMS. Am I wrong about this?
2. Call an reload servlet from the database?
Sounds slightly painful but at least it's event driven.
3. Drop the immediate update requirement and poll a data changed flag
in the db
every x seconds?
Edward Dowgiallo wrote:
Support for what you want to do is actually a feature in Oracle 11g. For
Oracle 10g, you want to look at the publish/subscribe support which is part
of advanced queueing. The documentation is available online at
http://otn.oracle.com.
Is this the book I should be
Bill Davidson wrote:
Oracle Streams Advanced Queuing User's Guide and Reference
Looking through that, it looks like it uses JMS to send a message back to
Java. Being on Tomcat, that's a problem. Some searching shows I may
be able to use OpenJMS or ActiveMQ to get JMS in Tomcat
Darryl Pentz wrote:
I have an issue where webapp A needs to let webapp B know about an event, and
then return a response to webapp B's processing of that event to the browser.
So basically I need to communicate between webapps in the same container.
I have not found a no-brainer solution to
Darryl Pentz wrote:
You would think so but it isn't that easy. Which is good to some degree,
because that would seem like a scary security vulnerability. Nevertheless,
besides that, Tomcats classloader hierarchy also prevents this mechanism.
So if I'm understanding you correctly,
My company's main webapp is used around the world (Europe, North America,
Australia, etc.).
We're using Tomcat as our app server and Oracle (10g) for our database.
When we want to do an upgrade, that usually involves DDL changes to the
database as well as corresponding changes to the webapp
Paul McGurn wrote:
Segregate, geographically, your customer base's target infrastructure. The way they do this is by
tying their customers to a specific cluster of their cloud, and then everything that
customer does in the application is tied back to that cluster. The layer of redundancy
John5342 wrote:
I get around my the same kinds of problems by keeping all the layers of the
web app seperate so that i can swap them out one at a time and create a near
seemless upgrade. The layers in my web apps are:
1 The web interface.
2. The application logic. (this may itself be several
Johnny Kewl wrote:
Going to add this to my other no no's like those people that insist on
building entire site only in JSP pages...
I'm not sure I get your meaning here. Do you mean really just JSP's
with no Java classes (beans or otherwise) that aren't in the JSP's
themselves?
Yeah. That
Gregor Schneider wrote:
No, in fact the 64-bit-jvm is able to adress (thus use) more memory
than on 32-bit-jvm.
just make sure that a 64-bit-jvm (java-virtual-machine) is installed.
Actually, in machine terms, pointers in a 64-bit system are twice as
wide and thus take up twice as much
On 21 Aug 2008, at 09:25, Mark Thomas wrote:
Add some logging to your firewall configuration to see what is being
dropped.
Dominic Mitchell wrote:
That should help, but it's likely to be a different port in use each
time. Because JMX uses RMI by default, and RMI uses two ports: a fixed
port to
Tim Funk wrote:
An easy kludge is to run jconsole locally on the server and send the
display to yourself.
ssh -Y yourserver (or ssh -X server YMMV)
$JAVA_HOME/bin/jconsole pid
No iptables tricks needed.
I'm running the client on a Windows machine. I did try Cygwin/X
and an ssh tunnel with
I've been through the docs. I've been through Google. I can't seem
to figure this out.
Server: Tomcat 6.0.18, JDK: 1.6.0_07, Redhat Server 5.2
Client: jconsole from JDK 1.6.0_07 on Windows XP
I've got all of these in $CATALINA_OPTS and they do show up in
the java command line when I run ps:
Robert Dietrick wrote:
Why would you want the same person logged in twice
with different accounts?
As a developer of a web app that has both admin and regular user roles,
I want to do this all the time. The admin roles can change things in ways
that affect the regular user's view. I want
Christopher Schultz [EMAIL PROTECTED] wrote:
You could use separate tabs in the same browser if you were to disable
cookies on your browser (and you have correctly encoded your outgoing
URLs).
David Rees wrote:
Yep, this is probably the best way to do it. Just keep in mind that if
you copy
Patrick Markiewicz wrote:
What is the tomcat mailing list spam score, and why am I unable to send
my email to post a question?
You just posted a question.
I don't know what you mean by spam score.
-
To start a new topic,
Assuming httpd and tomcat are running on the same machine,
would it be best to run the mod_jk connection on the loopback
rather than the primary ethernet? Any disadvantages to the
loopback?
It seems like it might be more secure since other machines
would not be able to make a direct connection
Stuart Caldwell wrote:
I know this may sound naïve but is it possible to have tomcat and apache
running off the same port - 8080.
I have iis running on port 80 and do not have another server to install apache
and tomcat.
TCP only allows one listener per port-IP combination. It really
André Warnier wrote:
By the way, the reason why I can't try it right now is that I just
don't have the application to try it with. So whatever I mentioned
before (but which apprently so far seems ok) was purely by attempting
to understand the documentation. Beware.
I tried it today. I
Rainer Jung wrote:
André Warnier wrote:
And, again in other words, if this parameter was set to Off, and
Tomcat generated a new session and a JSESSIONID session cookie for
this session, that the cookie would thus not be marked secure ?
Didn't try this. What does your tests say?
Oooh! I
Christopher Schultz wrote:
Yes, but the OP didn't say whether no changes were made to the original
code (or configuration) when moving between Tomcat versions.
Until the change to the login servlet for the cookie, there were no changes
to the app's code. It's even still being compiled against
Bill Barker wrote:
This is correct. TC 3.2.4 never set the secure flag on that cookie,
and TC 3.3.2 would only set it if you enabled an option in server.xml.
This feature of TC is only on TC 4.0 and higher.
Thank you for confirming that.
Christopher Schultz wrote:
Did you change Tomcat code, or your own code?
Our own code. We have an explicit login servlet that handles
checking the login/password against values stored in our Oracle
database.
Okay, so it sounds like you are using your own. Is there any particular
reason you
Christopher Schultz wrote:
Yep. It's part of the servlet specification. Maybe as you move forward,
you could look into using that and reduce the amount of code you have to
maintain. Note that TC container-managed authentication does not allow
drive-by logins (that is, logins that didn't result
Johnny Kewl wrote:
Bill... Just lose the FORM authentication, replace it with DIGEST, or
even BASIC I think all your problems will go away.
I'm not exactly sure what you're saying. Are you saying that I shouldn't be
authenticating through a form?
Bill Davidson wrote:
I'm confused so I'm not sure what I say below makes sense.
If I'm reading these posts correctly, the cookie is issued by the
front end
(which is Apache web server). Since it is created on an https
session, it
is being marked as secure. When browser switches to a non
BTW, I forgot to thank everyone for helping me to understand
what this problem better. Understanding that the cookie was
being created by Tomcat with the secure flag and that the flag
was causing the problem was the key.
Thanks everyone.
--Bill Davidson
1 - 100 of 114 matches
Mail list logo
