Hi Mark, Of course. Our code is open source. You can download it here:
http://sourceforge.net/projects/lportal/files/Liferay%20Plugins/6.0.5/opensocial-portlet-6.0.5.1.war/download The src is in the WEB-INF folder. Look for ShindigFilter and LiferayJsonContainerConfig. Hope that helps. - Mike -- Liferay Europe Symposium October 12-13, 2010 Frankfurt, Germany www.Liferay.com/EuropeSymposium2010 -- Follow us on Twitter: liferay On Sep 19, 2010, at 5:16 AM, Mark Nesbitt wrote: > 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 >>> >>> >>
