Hi, Other than introducing a new approach +1 for using same approach used by Tomcat. Not only for easy of use, this would help us to resolve any issue comes with this versionning process.
Thanks, Shameera. On Fri, Jul 12, 2013 at 6:06 AM, Kishanthan Thangarajah <[email protected] > wrote: > Hi Sagara, > > > On Thu, Jul 11, 2013 at 2:43 AM, Sagara Gunathunga <[email protected]>wrote: > >> >> I'm working on ${Subject} to come up with an architectural design to >> cater aPaaS requirements. At the moment I came up with following ideas >> it's better if we can start a discussion here to find best option among >> them or new best approach. >> >> (a) Option 1 - Use context-postfix ( like we use context-prefix to >> handle webapps belong to tenants) >> ======================== >> >> 1. Say user upload a webapp called "mvcapp.war" with version number "2.0" >> >> 2. Assume above web app will be copied to "webapps" directory of AS as >> "mvcapp__v20.war" ( For the moment let's forget how we create >> mvcapp__v20.war file, we have full control on this area) >> >> 3. During the deployment it detect file name contains "__v" pattern and >> call to handle versioning >> >> 4. Finally deployer deploy above mvcapp__v20.war app with "/mvcapp/v20" >> context path. >> >> 5. Now above app can be accessed using following URL >> >> http://192.168.1.4:9763/mvcapp/v20 >> > > > For option-1 above, instead of bringing our own way of app versioning, > can't we use the same approach that tomcat follows [1] ? > > The following table is copied from the tomcat doc page for reference. > > Context Path Context VersionContext Name Base File NameExample File Names > (.xml, .war & directory) /foo*None* /foofoo foo.xml, foo.war, foo/foo/bar > *None*/foo/bar foo#barfoo#bar.xml, foo#bar.war, foo#bar *Empty String** > None* *Empty String*ROOT ROOT.xml, ROOT.war, ROOT/foo 42/foo##42 > foo##42foo##42.xml, > foo##42.war, foo##42 /foo/bar42 /foo/bar##42foo#bar##42 foo#bar##42.xml, > foo#bar##42.war, foo#bar##42 *Empty String*42 ##42ROOT##42 ROOT##42.xml, > ROOT##42.war, ROOT##42 > So here is how the versioning works in tomcat. > > The context name, context path and base file name are closely related. > "##" is used to add the version and "#" is used to add another context to > the path. > > As a given example above, foo##42.war will have /foo as the context path > and 42 as the version. In here, if there are one or more version of the > same app, the latest version takes precedence and the requests gets > dispatched to that. > > "#" can be added to have hierarchical context value for the app. > > So why don't we follow the same approach as above? > > Also I have some questions related to $subject. > 1. Do we need to have all the version of a particular app deployed at all > time? > 2. Is there a requirement to distinguish the version of a app in the URL > like http://192.168.1.4:9763/mvcapp/v20 ? > > Thanks, > Kishanthan. > [1] http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming > >> >> Special Notes >> -------------------- >> >> 1. Unlike tenant use cases in above option .WAR file get unpacked during >> the deployment but due to suggested modification .WAR file name and >> unpacked directory name are not identical. >> >> e.g - .WAR file - "mvcapp__v20.war" >> Unpacked directory - "mvcapp#v20" ( We don't have any >> control to change this behavior) >> >> Due to this fact during the undeployment unpacked directory will remains >> without deleting, but this is not an issue as we can detect the pattern and >> can delete unpacked directory through the undeployment. >> >> >> 2. After deployment app's Context URL will remains constant we can't >> dynamically change it. Here it's not possible to change default version of >> the app just using Tomcat or AS through Admin UI. >> >> e.g - >> http://192.168.1.4:9763/mvcapp/v10 >> http://192.168.1.4:9763/mvcapp/v10 >> http://192.168.1.4:9763/mvcapp/v30 >> >> In order to change default version time to time we need to have >> URL-Rewriting component ( within ELB ? ) in front of AS. URL-Rewriting >> component should handle followings. >> >> * It can receive messages (cluster messages ?) from AS when the default >> version of app get changed. >> >> * Based on current default version it should able to redirect incoming >> messages to correct app version on AS. >> >> * If it's a required feature, it should hide actual context URL on AS >> from users and have to always requite URL like mod_rewrite do . >> >> >> >> (b) Option 2 - Add Proxy or adapter to existing ProtocolHandlers >> ======================== >> >> This idea is to wrap or create proxies for existing Tomcat >> ProtocolHandlers so that we can intercept messages before send to actual >> ProtocolHandlers but this seems not straightforwards thing without losing >> major performance level. When receiving a message Tomcat directly deal >> with Java Socket and and when finding a URL of a message it act on byte >> level processing hence it hard to intercept in this area while keeping same >> level of performance. Tomcat use a class called "Mapper" to dispatch >> incoming messages to correct Context but we don't have any point to >> intercept until this mapping happened. AFAIK Valves get hit after context >> matching happened so we can't use them here. >> >> One alternative is to write and maintenance our own set of >> ProtocolHandlers but this is not straightforward as it sounds and really >> complex task to keep same performance level. >> >> >> >> (c) Option 3 - Customize Tomcat's Mapper Class >> =================================== >> >> Complexity wise this is not hard and we can cater all our aPaaS >> requirements in once place but the cost is we have to fork Tomcat locally >> and maintain, upgrading according to Apache released versions is the >> biggest challenge in long run and generally not a good idea. >> >> >> >> >> Among above 3 options personally I prefer options-1 as it less complex >> and less effect to current Tomcat and AS architectures and I already having >> working prototype. Also any way the prosed URL- >> Rewrite component is useful to ELB. >> >> >> Comments ? >> >> >> >> 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 >> >> > > > -- > *Kishanthan Thangarajah* > Senior Software Engineer, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com* > Twitter - *http://twitter.com/kishanthan* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Software Engineer - WSO2 Inc.* *email: shameera AT wso2.com <[email protected]> , shameera AT apache.org<[email protected]> * *phone: +9471 922 1454* * * *Linked in : *http://lk.linkedin.com/pub/shameera-rathnayaka/1a/661/561 *Twitter : *https://twitter.com/Shameera_R
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
