You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Mark Nesbitt <ma...@gmail.com> on 2010/09/15 16:26:38 UTC
Shindig host/port questions
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
Re: Shindig host/port questions
Posted by Michael Young <mi...@liferay.com>.
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 <ga...@gmail.com> 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 <mi...@liferay.com>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
>>>
>>>
>>
Re: Shindig host/port questions
Posted by Mark Nesbitt <ma...@gmail.com>.
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 <ga...@gmail.com> 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 <mi...@liferay.com>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
>>
>>
>
Re: Shindig host/port questions
Posted by Gagandeep singh <ga...@gmail.com>.
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 <mi...@liferay.com>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
>
>
Re: Shindig host/port questions
Posted by Michael Young <mi...@liferay.com>.
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