On 04/10/18 13:24, Tomáš Bleša wrote: > As I understand tomcat documentation, parallel deployment is intended to be > used to smoothly rollout new versions of webapp. I've looked in source code > and it's written such that there is probably no way to custimize selection of > proper context version. If session is invalid then newest version is always > selected. > I wonder if it would be desirable to build in more flexibility in context > selection process. For example consider following scenario (real one in my > company). We develop complex CRM system and one ROOT.war is used by multiple > customers. Each customer has special ID that has to be part of URL address: > > site.com?customer=A > site.com?customer=B > ... > All customers A, B, C, ... use the same version 5.x of our app. Now we have > version 6 with massive changes in UI (+external API) and we want to gradually > move our customer base (with their consent) from version 5 to version 6. We > cannot afford to migrate all customers to v6 at once. Giving each of our > customers unique URL (a.site.com, b.site.com, ...) and use virtual hosting is > technically possible but it would complicate other things in our > infrastructure. > > What I would like to accomplish is to have multiple versions of the app, e.g.: > ROOT##571.war > ROOT##572.war // hotfix of 5.7.1 > ROOT##573.war // hotfix of 5.7.2 > ROOT##600.war > ROOT##601.war // hotfix of 6.0.0 > > and two-step process of context version selection. > Step 1) > Belong the request to customer with version 5? -> pre-select ##571, > ##572, ##573 > Belong the request to customer with version 6? -> pre-select ##600, > ##601 > Done by my custom ContextVersionSelector interface implementation > (which of coarse would check "customer" param in URI) > Step 2) > Use StandardContextVersionSelector on results from previous step > (current behavior ... it would be used always as last applied selector) > > If I understand the code right, all context selection magic is done in > Mapper.java (which is now declared final) and it would have to be modified to > support customizable version selection. > > My questions are: > Is there a better way how to accomplish "slow pace" rollout of new version? > (I mean with just Tomcat and nothing more)
Having multiple virtual hosts / tomcat instances is the usual way of handling this but you have ruled that out. It could be done fairly simply if you inserted a reverse proxy in front of Tomcat but that breaks your 'just Tomcat' requirement. > If not, do you consider my proposed Mapper imrovement interesting/useful? (I > can try pull request) This looks to be a fairly specific use case. Given that: - the use case is specific - the changes are likely to be quite invasive - the changes would be to code that executes for every request I suspect that there would be some resistance to these changes being included in a standard Tomcat distribution. What I think is much more likely is changes to visibility and/or refactoring to make the context version selection pluggable so you (or anyone else) can easily insert your own implementation. If you proposed changes like that in a PR then I think they are much more likely to be accepted. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
