As per thread[1] we have implemented multiple version deployment support for web applications ( including JAX-WS/JAX-RS) and will be available with AS 5.2.0 release. The original plan was to leave default version handling to the ELB using some kind of a URL rewriting mechanism but during the architectural review we decided to bring default version handing into AS level to keep ELB lightweight.
Here under "default version management" concept we need to support following requirements. a.) Change default version through admin UI. b.) Any incoming request which does not mention specific version number in it's request URL should dispatch to current default version. Further response messages or page rendered should hide actual application version instead they should contains default app context . (As an example if "mvcapp/2" is the current default version then requests with "mvcapp" request URL should dispatch to application version named "mvcapp/2". ) c.) Regardless of default version management, if the incoming request URL contains a valid version number (e.g - mvcapp/XY) it should dispatch to specific application version (e.g - mvcapp/XY version) not to the default version. I have done few POCs and pros/cons of each approach are given below. 1. ) *Option -1 * - Extend Tomcat's dispatching logic so that request which does not mention specific version number to current default version, this can be done by modifying Tomcat's Mapper[2] class. The main limitation of this approach is after dispatching to default version response message or rendered web pages contains actual context path (e.g - Response URL is "mvcapp/XY" not "mvcapp") With this approach a.) and c.) possible but b.) is not possible. 2.) * Option -2 * - Instead of deploying each version with unique context path deploy all versions in a single context path and use Tomcat's version numbering support [3]( based on ## ) to handle different application versions. Still we need to modify Mapper[2] class in order to dispatch request which does not mention specific version number to current default version (e.g "mvcapp" into "mvcapp/XY" Context). Main drawback of this approach is each version of a application won't get unique context path and all of them share single context path hence it is not possible to uniquely refer to each application version. In this approach a.) and b.) are possible but c.) is not possible. 3.) * Option -3* - Implement URL rewrite module and invoke it before message reach to Tomcat Connectors, this rewrite module aware about default version management and can rewrite URLs accordingly. Further when rendering web pages this module should rewrite all the links according to default version management logic. Basically this is something similar to mod-proxy module for Apache2. As this involves lot of effort and can affect to performance I haven't look into this and keep it as the final option but with this we can support all of above a.), b.) and c.). This option also involved modification on Tomcat Connector level but I haven't look into this further. 4.) *Option - 4 *- When changing the default application from UI simply rename the .WAR file so that web app will redeploy in the new context path. This is the simplest option and we don't need to modify or extend any Tomcat classes also this supports for our existing DepSync architecture as well. Only drawback is when changing the version of a specific .WAR file it's required to redeploy the app with new context path but in production systems changing the default version is not a everyday activity hence IMO not a very big issue. With this approach above a.), b.) and c.) are possible. Any comments ? [1] - "AS Webapp versioning for aPaaS" [2] - http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat.embed/tomcat-embed-core/7.0.34/org/apache/tomcat/util/http/mapper/Mapper.java [3] - http://tomcat.apache.org/tomcat-7.0-doc/config/context.html Thanks ! -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services; http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
