We ran into the same issues here and we had to write an extension to inherit the values from the request.
+1 to add this as configurable behavior - Mike -- Liferay West Coast Symposium September 8-9, 2010 Anaheim, CA www.liferay.com/wcs -- Follow us on Twitter: liferay On Sep 15, 2010, at 7:26 AM, Mark Nesbitt wrote: > Hi, > > Had some questions about server host and port in container.js - in > particular the values that are used in Uri generation (ex: > gadgets.uri.proxy.host - set from defaultShindigProxyConcatAuthority > in container.js). Currently this value either comes from web.xml, or > a system property (jetty.host, jetty.port - or system property set > explicitly) or you can just specify the value in this file. Is there > any reason to not use the incoming requests HttpServletRequest's > getServerName, getServerPort, getScheme for this? For tomcat, we > would rather configure this through the connector setting. For > WebSphere App Server, for many reasons setting this explicitly with > one of the above methods is problematic and we would prefer the > incoming request's getServerName/Port in these cases - which should > work well with WebSphere's reverse proxy solutions. This solution > seems reasonable - but worry there might be issues since shindig does > not implemented it this way. > > If this is a reasonable way to go, any thoughts on how to implement > this? Looks like this servlet request value are used a little bit in > the proxy/concat default uri managers - but just for strict parsing - > which I am still unsure if that is useful. Finding a way to pass > servlet request's values into some of these areas where it is used by > changing shindig code is also I way I don't really want to go. > Extending JsonContainerConfig is an option - but unsure if there is a > guice mechanism (or other way) that would allow us per request config > property resolution ( still thinking this through). > > Any quick thoughts/help is appreciated - > > Mark
