All - I have been working on trying to simplify the rewrite rules required for proxying UIs, as is the goal of KIP-9 [1].
I started with the assumption of having specific topologies for each UI. In order to not have to provide rewrite rules to add some artificial app path element - such as 'ambari' - I have added a default path element to the topology. Using this feature, a call to https://localhost:8443/gateway/sandbox-ambari will result in the gateway resolving it to https://localhost:8443/gateway/sandbox-ambari/ambari internally but rendered URLs do not need to have that element. Thus, we can remove all rewrite rules that merely add that path to the URL. It seems that this approach does work to help make the rewrite rules more generic and I think that the progress is worth pursuing the rest of KIP-9 as well. I thought that I would share the results with you beforehand however. I was hoping to reduce the number of rules more substantially than it does. At the same time, this approach no longer requires a rewrite rule for every single file that may be linked in an application and its associated framework. It allows us to move from: <rule dir="OUT" name="AMBARIUI/ambari/outbound/vendorcss"> <rewrite template="{$frontend[path]}/ambari/stylesheets/vendor.css"/> </rule> <rule dir="OUT" name="AMBARIUI/ambari/outbound/appcss"> <rewrite template="{$frontend[path]}/ambari/stylesheets/app.css"/> </rule> <rule dir="OUT" name="AMBARIUI/ambari/outbound/vendorjs"> <rewrite template="{$frontend[path]}/ambari/javascripts/vendor.js"/> </rule> <rule dir="OUT" name="AMBARIUI/ambari/outbound/appjs"> <rewrite template="{$frontend[path]}/ambari/javascripts/app.js"/> </rule> to: <rule dir="OUT" name="AMBARIUI/ambari/outbound/css"> <rewrite template="{$frontend[path]}/stylesheets/{**}"/> </rule> <rule dir="OUT" name="AMBARIUI/ambari/outbound/js"> <rewrite template="{$frontend[path]}/javascripts/{**}"/> </rule> The elimination of the file specific rules leads to a much less brittle service definition and hopefully fewer breakages from version to version. Overall, at this point, it seems that the rewrite.xml for ambariui can be reduced by about 20 lines of XML. Not a huge simplification but the ability to wildcard resources in directories can be huge in terms of new files, images, etc that may be added to existing directories. Here is the reduced ambariui rewrite.xml: <rules> <rule dir="IN" name="AMBARIUI/ambari/inbound/root" pattern="*://*:*/**/ambari/"> <rewrite template="{$serviceUrl[AMBARIUI]}/"/> </rule> <rule dir="IN" name="AMBARIUI/ambari/inbound/path" pattern="*://*:*/**/ambari/{**}"> <rewrite template="{$serviceUrl[AMBARIUI]}/{**}"/> </rule> <rule dir="IN" name="AMBARIUI/ambari/inbound/query" pattern="*://*:*/**/ambari/{**}?{**}"> <rewrite template="{$serviceUrl[AMBARIUI]}/{**}?{**}"/> </rule> <rule dir="OUT" name="AMBARIUI/ambari/outbound/sitepath"> <rewrite template="{$frontend[path]}/"/> </rule> <rule dir="OUT" name="AMBARIUI/ambari/outbound/extrapath"> <rewrite template="{$frontend[path]}/api/v1"/> </rule> <rule dir="OUT" name="AMBARIUI/ambari/outbound/logohref"> <rewrite template="#/main/dashboard"/> </rule> <rule dir="OUT" name="AMBARIUI/ambari/outbound/img" pattern="/img/{**}"> <rewrite template="{$frontend[path]}/img/{**}"/> </rule> <rule dir="OUT" name="AMBARIUI/ambari/outbound/css"> <rewrite template="{$frontend[path]}/stylesheets/{**}"/> </rule> <rule dir="OUT" name="AMBARIUI/ambari/outbound/js"> <rewrite template="{$frontend[path]}/javascripts/{**}"/> </rule> <filter name="AMBARIUI/ambari/outbound/proxyroot"> <content type="*/x-javascript"> <apply path="\{proxy_root\}" rule="AMBARIUI/ambari/outbound/sitepath"/> </content> <content type="application/javascript"> <apply path="\{proxy_root\}" rule="AMBARIUI/ambari/outbound/sitepath"/> </content> </filter> <!-- filter to rewrite api prefix defined in .js from root --> <!-- e.g. /api/v1 --> <filter name="AMBARIUI/ambari/outbound/apiendpoint"> <content type="*/x-javascript"> <apply path="/api/v1" rule="AMBARIUI/ambari/outbound/extrapath"/> </content> <content type="application/javascript"> <apply path="/api/v1" rule="AMBARIUI/ambari/outbound/extrapath"/> </content> </filter> <filter name="AMBARIUI/ambari/outbound/apiendpoint/html"> <content type="text/html"> <apply path="/api/v1" rule="AMBARIUI/ambari/outbound/extrapath"/> </content> </filter> <filter name="AMBARIUI/ambari/outbound/apiendpoint/noroot"> <content type="*/x-javascript"> <apply path="api/v1" rule="AMBARIUI/ambari/outbound/extrapath"/> </content> <content type="application/javascript"> <apply path="api/v1" rule="AMBARIUI/ambari/outbound/extrapath"/> </content> </filter> <filter name="AMBARIUI/ambari/outbound/links"> <content type="*/x-javascript"> <apply path="/api/v1" rule="AMBARIUI/ambari/outbound/extrapath"/> <apply path="\{proxy_root\}" rule="AMBARIUI/ambari/outbound/sitepath"/> <apply path="/#/main/dashboard" rule="AMBARIUI/ambari/outbound/logohref"/> </content> <content type="application/javascript"> <apply path="/api/v1" rule="AMBARIUI/ambari/outbound/extrapath"/> <apply path="\{proxy_root\}" rule="AMBARIUI/ambari/outbound/sitepath"/> <apply path="/#/main/dashboard" rule="AMBARIUI/ambari/outbound/logohref"/> </content> <content type="*/html"> </content> </filter> <filter name="AMBARIUI/ambari/outbound/mainpage"> <content type="*/html"> <apply path="stylesheets/{**}.css" rule="AMBARIUI/ambari/outbound/css" /> <apply path="javascripts/{**}.js" rule="AMBARIUI/ambari/outbound/js" /> </content> </filter> </rules> Feel free to compare to the existing rewrite.xml in {GATEWAY_HOME}/data/services/ambariui/2.2.0/rewrite.xml Perhaps other UI service definitions will be simplified by a more impressive amount. I am a bit concerned about whether we can think through exactly how to migrate existing service definitions and deployments in a backward compatible way for the 0.14.0 release timeframe. * We could add a new version of the service definitions and require old deployments to be changed to specify the old version. * We could add new service definitions for each UI which would assume this deployment pattern and continue to support the existing way as well. ** we could also have an 0.14.0 release that continues to support both as described here but in a separate 1.0.0 release we stop support for the old patterns for UI proxying. Don't particularly like this but it may be cleanest approach. * We could continue to use the service element instead of introducing a new UI element and discover from service definition whether it is a UI and handle it as a UI element as described in KIP-9. ** this would likely require each topology to be redeployed on upgrade and the generation of new topologies based on the service def metadata. Anyway, the above coming together in the next couple of weeks concerns me and I am wondering if it should be pushed out to 0.15.0/1.1.0 release. Please feel free to share any thoughts, concerns or ideas that you may have on this effort. thanks, --larry 1. https://cwiki.apache.org/confluence/display/KNOX/KIP-9+Simplified+UI+Rewrite+Rules+and+Proxying
