Hi Sagara, >From our last meeting, what I understood was that with Option 4, achieving (c) requires that the WAR is deployed twice (as mycapp.war and mycapp#v2.war IIRC). If not, if version 2 is set as default, /mycapp/2 would fail. And the problem with the "double deployment" was that now, the default version and v2 don't actually share the same sessions.
Have you been able to workaround these problems so that we Option 4 is still viable? On Wed, Aug 21, 2013 at 6:00 PM, Sagara Gunathunga <[email protected]> wrote: > > 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 > > -- ------------------------------ *Sameera Perera* Senior Manager, Cloud Technology Group gtalk: [email protected] *WSO2, Inc.* <http://wso2.com/> lean.enterprise.middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
