Hello,
> If you don't set secretRequired="false" properly then at start time Tomcat
> will complain if there is no specified "secret" attribute.
> If it doesn't complain then most probably you are testing again with the
> wrong server.xml or old version of Tomcat.
the issue seems to be that
Hello Martin,
> > This should be: secretRequired="false".
> > This attribute has been renamed recently.
I just looked at my notes, and I tried that already yesterday night.
Still facing the same problem with 403. Might it be possible that I need
to use a secret in order to access ajp from
Hello Martin,
> This should be: secretRequired="false".
> This attribute has been renamed recently.
thanks. I'll test later and let you know how it went.
Cheers,
Thomas
-
To unsubscribe, e-mail:
Hello,
the problem was that I edited the wrong server.xml. The one that was not
used. So now that I figured that out, settings these two settings help.
Hello,
I've just upgraded to tomcat7 (7.0.100) afterwards I'm unable to
reconfigure it to the pre 7.0.100 behaviour where AJP connector listens
on the public ip address in order to use it with mod_jk. Can someone
help me out to make it works again? My server.xml is:
Hello,
I have mod_jk version 1:1.2.18-3etch1 (which comes with Debian Etch) as
loadbalancer in front of four tomcats version 5.5.20-2etch2 that do not
duplicate sessions because of their size (100Mbyte per session; 120 -
500 users). My workers.property looks the following:
worker.list=router,
Rainer,
No, the design of mod_jk is stateless w.r.t. sessions. There are only the
obvious solutions, i.e. assuming that after some time of disabling (time
depending on typical session use cases like 10 minutes or an hour) you stop
the worker and thereby redirect users that still try to use
