Thanks for the feedback. It makes sense to look at adding a rewriter to do this. Will be looking at this in the next few days.
Mike - if you don't mind sharing, how did your extension work? Mark On Wed, Sep 15, 2010 at 10:48 PM, Gagandeep singh <[email protected]> wrote: > It might be tough to change the assumption that shindig host and port are > not static and could change at runtime with the http request. > It might be easier to just add a rewriter that moves the proxied resources > from shindig authority to the host/port you want (which is the host port of > the HttpRequest). > > Take a look at ProxingVisitor for example. You could go over all the urls in > an html which could be proxied, check the ones that are proxied and just > modify their src's to point to the new host/port. > > Does that sound reasonable ? > > On Wed, Sep 15, 2010 at 9:29 PM, Michael Young > <[email protected]>wrote: > >> 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 >> >> >
