On Fri, Jul 12, 2013 at 12:20 PM, Supun Malinga <[email protected]> wrote:
> Hi, > > +1 for option 1 (using the tomcat's default support). That's straight > forward and simple than the other options. > > However we should test it thoroughly to see if we have tomcat's exact > behavior.. > I did few testing on this, in fact we can reuse schema and some internal processing from Tomcat but still we have to do some improvements as I suggested in option-1. The reason is we don't use Tomcat deployers instead Carbon deployers so we need some logic to handle versioning within Web Application deployers otherwise application deploy with "/myapp#20" context path instead of "/myapp/20". With suggested naming schema changes above Option-1 can be modified as follows. 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#20.war" 3. During the deployment it detect file name contains "#" pattern and call to handle versioning 4. Finally deployer deploy above mvcapp#20.war app with "/mvcapp/20" context path. 5. Now above app can be accessed using following URL http://192.168.1.4:9763/mvcapp/20 <http://192.168.1.4:9763/mvcapp/v20> Note - According to the doc when it come dispatching to a version Tomcat use following algorithm. If no session information is present in the request, use the latest version. If session information is present in the request, check the session manager of each version for a matching session and if one is found, use that version. If session information is present in the request but no matching session can be found, use the latest version. But in our case we don't need always dispatch to the latest version instead users need a control to define the default version and change it time to time also other versions of same application should be uniquely accessible too hence I don't think above algorithm can be used in our case so still we need URL -ReWriting component in front of AS. Thanks ! > thanks, > > > On Fri, Jul 12, 2013 at 11:56 AM, Sagara Gunathunga <[email protected]>wrote: > >> >> >> >> 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##42 >>> foo#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. >>> >> >> It seems I discover the same thing but in reverse order :) if we have >> above support that's more than enough to handle our use cases in fact I >> used "__v" instead of "#". >> >> >>> >>> 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? >>> >> >> It's up to the user, if user want to run all of them we should >> facilitate. >> >> >>> 2. Is there a requirement to distinguish the version of a app in the URL >>> like http://192.168.1.4:9763/mvcapp/v20 ? >>> >> >> It's just how i came up with my initial design but we can go according to >> above table. >> >> Thanks ! >> >>> >>> 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 >>> >>> >> >> >> -- >> 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 >> >> > > > -- > Supun Malinga, > > Senior Software Engineer, > WSO2 Inc. > http://wso2.com > http://wso2.org > email - [email protected] <[email protected]> > mobile - 071 56 91 321 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
