inname in the URL. I'd be
>interested in hearing what configuration you have for this.
Could you please provide some more detail for what is getting redirected
to where?
Regards,
Daniel
Ashley Hayes schrieb:
> Hi Daniel,
> I recently setup some similar architecture and do
Hi Daniel,
I recently setup some similar architecture and documentation for
tomcat mod-jk integration with proper sticky sessions is very poor. I am not
that familiar with the jk logs but do know I had to do the following to get
sticky sessions to work:
Think your problem may be with only
Hi John,
I actually think your approach is correct, I was merely pointing out
that we had a similar problem and suggested a workaround. This workaround is
obviously not efficient if you have multiple contexts that would like to
share the same large pool of connections.
I'd be interested to
I know we had/have problems with GlobalNamingResources. We have it working
with the connection pool ".." and our JAAS realm configured under
the webapp context node.
Also make sure that your JAAS classes are available to tomcat's classloader,
i.e. under common/lib or common classes.
Like wise the D
Hi all,
We use tomcat's formbased authentication (post to /j_security_check), the
bases of which is a HTTP 302 redirect on success.
We have a problem because tomcat/mod jk is issuing a full URL to the client
that points at an internal ( private) IP/server - as opposed to the public
IP/domain na
