This might cause a problem of using == instead of equals() for strcmp
if (version == (request.getContext().getWebappVersion())) {
mapRequired = false;
}
When running mod_jk with sticky session, but not using tomcat clustering
... Will adding a new version append the version number to the end of
the session cookie AFTER the engineId (used by mod_jk for determining
where to route the request)
Since the session id tomcat generates is always all uppercase. Should
the 'V' for the append be a lower case v? Even though session id
collision is *rare*, but using a char that isn't in the session id name
space would eliminate that problem.
Otherwise +1. For those who are uninterested in the feature, it appears
the extra overhead is minimal. (Some micro benchmarks would be nice for
any skeptics ... or those just curious :) )
-Tim
On 11/5/2010 9:08 PM, Mark Thomas wrote:
All,
The clean-up is in place and I have a patch [1] that adds support for
parallel deployment. There is still some work to do before the feature
can be used (Manager app needs to be made version aware when listing
apps, need to test with clustering, need to write some docs) but I'd
like to apply this patch sooner rather than later so the code is in
place for the next release.
Behaviour should remain unchanged unless someone deploys an app with the
version marker (##<version>) at the end of the WAR / dir / context.xml
name so even if the todo list above isn't complete it shouldn't get in
the way of the next release.
Before I apply the patch I wanted to give folks an opportunity to review
and comment on whether or not it was too big a change for the 7.0.x
branch at this stage. My own view is that it is not.
Cheers,
Mark
[1]
http://people.apache.org/~markt/patches/2010-11-05-parallel-deployment.patch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
