You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@slider.apache.org by Jon Maron <jm...@hortonworks.com> on 2014/06/24 21:36:31 UTC
Help with Guice/Jersey
Hi,
I am attempting to split out the Slider agent-based HTTP resources into a separate web application in order to explicit secure those interactions (SSL etc). In doing so I am leveraging the Jersey/Guice/Jetty based web app infrastructure in Yarn.
It appears that even though I have split off a separate yarn web app instance, configured with the associated agent resources, those new resources can not be reached/found (the other non-agent resources still managed by the SliderAMWebApp still work). In other words, even though each WebApp instance is configured with its own GuiceContainer, for some reason the agent web app can not return those resources when requested (my understanding is that a GuiceContainer will scan the classes bound to the servlet module to identify configured resources and providers. In a debugger I’ve also seen that that scan appears to take place).
A successful, non-agent request looks like this:
14/06/24 17:26:28 DEBUG mortbay.log: REQUEST /ws/v1/slider/mgmt/app on org.mortbay.jetty.HttpConnection@d2c5c4d
14/06/24 17:26:28 DEBUG mortbay.log: sessionManager=org.mortbay.jetty.servlet.HashSessionManager@6602b61b
14/06/24 17:26:28 DEBUG mortbay.log: session=null
14/06/24 17:26:28 DEBUG mortbay.log: servlet=default
14/06/24 17:26:28 DEBUG mortbay.log: chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
14/06/24 17:26:28 DEBUG mortbay.log: servlet holder=default
14/06/24 17:26:28 DEBUG mortbay.log: call filter NoCacheFilter
14/06/24 17:26:28 DEBUG mortbay.log: call filter safety
14/06/24 17:26:28 DEBUG mortbay.log: call filter AM_PROXY_FILTER
14/06/24 17:26:28 DEBUG web.SliderAmIpFilter: Remote address for request is: 192.168.64.1
14/06/24 17:26:30 WARN web.SliderAmIpFilter: Could not find proxy-user cookie, so user will not be set
14/06/24 17:26:31 DEBUG mortbay.log: call filter guice
14/06/24 17:26:31 DEBUG mortbay.log: RESPONSE /ws/v1/slider/mgmt/app 200
Whereas an unsuccessful agent request looks like this:
14/06/24 17:11:46 DEBUG mortbay.log: REQUEST /ws-agent/v1/slider/agents/register on org.mortbay.jetty.HttpConnection@1ad901b1
14/06/24 17:11:46 DEBUG mortbay.log: sessionManager=org.mortbay.jetty.servlet.HashSessionManager@372cab4
14/06/24 17:11:46 DEBUG mortbay.log: session=null
14/06/24 17:11:46 DEBUG mortbay.log: servlet=default
14/06/24 17:11:46 DEBUG mortbay.log: chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
14/06/24 17:11:46 DEBUG mortbay.log: servlet holder=default
14/06/24 17:11:46 DEBUG mortbay.log: call filter NoCacheFilter
14/06/24 17:11:46 DEBUG mortbay.log: call filter safety
14/06/24 17:11:46 DEBUG mortbay.log: call filter AM_PROXY_FILTER
14/06/24 17:11:46 DEBUG web.SliderAmIpFilter: Remote address for request is: 192.168.64.1
14/06/24 17:11:47 DEBUG mortbay.log: EOF
14/06/24 17:11:49 WARN web.SliderAmIpFilter: Could not find proxy-user cookie, so user will not be set
14/06/24 17:11:50 DEBUG mortbay.log: call filter guice
14/06/24 17:11:50 DEBUG mortbay.log: call servlet default
14/06/24 17:11:50 DEBUG mortbay.log: RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register.gz
14/06/24 17:11:50 DEBUG mortbay.log: RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
14/06/24 17:11:50 DEBUG mortbay.log: RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
14/06/24 17:11:50 DEBUG mortbay.log: resource=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
14/06/24 17:11:50 DEBUG mortbay.log: RESPONSE /ws-agent/v1/slider/agents/register 404
The second request shows that the guice interaction did not yield a response and the next filter (default) is attempted.
Anyone have any experience with this sort of configuration (multiple instantiated web apps/guice containers)?
— Jon
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Help with Guice/Jersey
Posted by Josh Elser <jo...@gmail.com>.
Sorry, but I'm not going to be of much help here. I remember having a
hard time wrapping my head around what Guice was doing when I tried to
get a basic AM Webapp running.
If Guice is just getting in the way, you could always ditch it and just
use the Jersey/Jetty components, IMO.
On 6/24/14, 3:36 PM, Jon Maron wrote:
> Hi,
>
> I am attempting to split out the Slider agent-based HTTP resources into a separate web application in order to explicit secure those interactions (SSL etc). In doing so I am leveraging the Jersey/Guice/Jetty based web app infrastructure in Yarn.
>
> It appears that even though I have split off a separate yarn web app instance, configured with the associated agent resources, those new resources can not be reached/found (the other non-agent resources still managed by the SliderAMWebApp still work). In other words, even though each WebApp instance is configured with its own GuiceContainer, for some reason the agent web app can not return those resources when requested (my understanding is that a GuiceContainer will scan the classes bound to the servlet module to identify configured resources and providers. In a debugger I’ve also seen that that scan appears to take place).
>
> A successful, non-agent request looks like this:
>
> 14/06/24 17:26:28 DEBUG mortbay.log: REQUEST /ws/v1/slider/mgmt/app on org.mortbay.jetty.HttpConnection@d2c5c4d
> 14/06/24 17:26:28 DEBUG mortbay.log: sessionManager=org.mortbay.jetty.servlet.HashSessionManager@6602b61b
> 14/06/24 17:26:28 DEBUG mortbay.log: session=null
> 14/06/24 17:26:28 DEBUG mortbay.log: servlet=default
> 14/06/24 17:26:28 DEBUG mortbay.log: chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
> 14/06/24 17:26:28 DEBUG mortbay.log: servlet holder=default
> 14/06/24 17:26:28 DEBUG mortbay.log: call filter NoCacheFilter
> 14/06/24 17:26:28 DEBUG mortbay.log: call filter safety
> 14/06/24 17:26:28 DEBUG mortbay.log: call filter AM_PROXY_FILTER
> 14/06/24 17:26:28 DEBUG web.SliderAmIpFilter: Remote address for request is: 192.168.64.1
> 14/06/24 17:26:30 WARN web.SliderAmIpFilter: Could not find proxy-user cookie, so user will not be set
> 14/06/24 17:26:31 DEBUG mortbay.log: call filter guice
> 14/06/24 17:26:31 DEBUG mortbay.log: RESPONSE /ws/v1/slider/mgmt/app 200
>
> Whereas an unsuccessful agent request looks like this:
>
> 14/06/24 17:11:46 DEBUG mortbay.log: REQUEST /ws-agent/v1/slider/agents/register on org.mortbay.jetty.HttpConnection@1ad901b1
> 14/06/24 17:11:46 DEBUG mortbay.log: sessionManager=org.mortbay.jetty.servlet.HashSessionManager@372cab4
> 14/06/24 17:11:46 DEBUG mortbay.log: session=null
> 14/06/24 17:11:46 DEBUG mortbay.log: servlet=default
> 14/06/24 17:11:46 DEBUG mortbay.log: chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
> 14/06/24 17:11:46 DEBUG mortbay.log: servlet holder=default
> 14/06/24 17:11:46 DEBUG mortbay.log: call filter NoCacheFilter
> 14/06/24 17:11:46 DEBUG mortbay.log: call filter safety
> 14/06/24 17:11:46 DEBUG mortbay.log: call filter AM_PROXY_FILTER
> 14/06/24 17:11:46 DEBUG web.SliderAmIpFilter: Remote address for request is: 192.168.64.1
> 14/06/24 17:11:47 DEBUG mortbay.log: EOF
> 14/06/24 17:11:49 WARN web.SliderAmIpFilter: Could not find proxy-user cookie, so user will not be set
> 14/06/24 17:11:50 DEBUG mortbay.log: call filter guice
> 14/06/24 17:11:50 DEBUG mortbay.log: call servlet default
> 14/06/24 17:11:50 DEBUG mortbay.log: RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register.gz
> 14/06/24 17:11:50 DEBUG mortbay.log: RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
> 14/06/24 17:11:50 DEBUG mortbay.log: RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
> 14/06/24 17:11:50 DEBUG mortbay.log: resource=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
> 14/06/24 17:11:50 DEBUG mortbay.log: RESPONSE /ws-agent/v1/slider/agents/register 404
>
> The second request shows that the guice interaction did not yield a response and the next filter (default) is attempted.
>
> Anyone have any experience with this sort of configuration (multiple instantiated web apps/guice containers)?
>
> — Jon
>
>
Re: Help with Guice/Jersey
Posted by Steve Loughran <st...@hortonworks.com>.
guava is "controversial" -its too brittle to update as it has atrocious
compatibility and even though there's a Hadoop patch to update, we worry
about downstream apps
On 25 June 2014 15:16, Jon Maron <jm...@hortonworks.com> wrote:
> Spent today trying to get the approach indicated in the link below to
> work, but the version of Guice in yarn pre-dates a required change. Moving
> on to Plan B: creating a completely separate jetty embedded instance w/o
> the reliance on guice.
>
> — Jon
>
> On Jun 25, 2014, at 11:18 AM, Jon Maron <jm...@hortonworks.com> wrote:
>
> > For the curious, this appears to be the issue:
> >
> >
> http://stackoverflow.com/questions/9074704/embedded-jetty-different-ports-for-internally-and-externally-visible-endpoints
> >
> > I may undertake to implement the specified approach (though the package
> scope constructor trick is a little…hokey?) just to see if:
> >
> > 1) It does in fact solve the issue and
> > 2) Allows for leveraging the existing HTTP yarn infrastructure pending
> a potential fix in guice
> >
> > Alternatively, I imagine the ambari server exposes multiple endpoints,
> some secure, some not, so if the approach above proves troublesome we many
> need to go down a similar path of instantiating a separate HTTP stack.
> >
> > — Jon
> >
> > On Jun 25, 2014, at 11:05 AM, Jon Maron <jm...@hortonworks.com> wrote:
> >
> >> I would agree as well. My concern is introducing yet another HTTP
> layer that ultimately would need to be tracked for alignment with any
> security layers introduced (knox, cert stores, credential stores, etc). I
> think the ideal is to have a single HTTP implementation that can be
> leveraged by AM developers that fulfills expected requirements (multiple
> listeners, secure listeners)
> >>
> >> — Jon
> >>
> >> On Jun 25, 2014, at 10:52 AM, Josh Elser <jo...@gmail.com> wrote:
> >>
> >>> Totally agree. Writing code that makes it more "amenable" to accepting
> the objects it's operating on is much easier in the long run.
> >>>
> >>> FWIW, I have recently been playing with Dropwizard[1] and really like
> it from a perspective of staying out of the way and just letting me write a
> REST service. I know that's not an answer to the question you asked, but
> thought it might be relevant :)
> >>>
> >>> [1] https://github.com/dropwizard/dropwizard
> >>>
> >>> On 6/24/14, 7:59 PM, Steve Loughran wrote:
> >>>> I always find Injection troublesome too. It helps with mocking, it
> helps if
> >>>> you want spring-style config wiring up of an app from components, but
> the
> >>>> classic "pass things as constructors" strategy often works too -and
> its
> >>>> essentially what I've resorted to in places
> >>>>
> >>>>
> >>>> On 24 June 2014 12:36, Jon Maron <jm...@hortonworks.com> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I am attempting to split out the Slider agent-based HTTP resources
> into
> >>>>> a separate web application in order to explicit secure those
> interactions
> >>>>> (SSL etc). In doing so I am leveraging the Jersey/Guice/Jetty based
> web
> >>>>> app infrastructure in Yarn.
> >>>>>
> >>>>> It appears that even though I have split off a separate yarn web app
> >>>>> instance, configured with the associated agent resources, those new
> >>>>> resources can not be reached/found (the other non-agent resources
> still
> >>>>> managed by the SliderAMWebApp still work). In other words, even
> though
> >>>>> each WebApp instance is configured with its own GuiceContainer, for
> some
> >>>>> reason the agent web app can not return those resources when
> requested (my
> >>>>> understanding is that a GuiceContainer will scan the classes bound
> to the
> >>>>> servlet module to identify configured resources and providers. In a
> >>>>> debugger I’ve also seen that that scan appears to take place).
> >>>>>
> >>>>> A successful, non-agent request looks like this:
> >>>>>
> >>>>> 14/06/24 17:26:28 DEBUG mortbay.log: REQUEST /ws/v1/slider/mgmt/app
> on
> >>>>> org.mortbay.jetty.HttpConnection@d2c5c4d
> >>>>> 14/06/24 17:26:28 DEBUG mortbay.log:
> >>>>> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@6602b61b
> >>>>> 14/06/24 17:26:28 DEBUG mortbay.log: session=null
> >>>>> 14/06/24 17:26:28 DEBUG mortbay.log: servlet=default
> >>>>> 14/06/24 17:26:28 DEBUG mortbay.log:
> >>>>> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
> >>>>> 14/06/24 17:26:28 DEBUG mortbay.log: servlet holder=default
> >>>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter NoCacheFilter
> >>>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter safety
> >>>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter AM_PROXY_FILTER
> >>>>> 14/06/24 17:26:28 DEBUG web.SliderAmIpFilter: Remote address for
> request
> >>>>> is: 192.168.64.1
> >>>>> 14/06/24 17:26:30 WARN web.SliderAmIpFilter: Could not find
> proxy-user
> >>>>> cookie, so user will not be set
> >>>>> 14/06/24 17:26:31 DEBUG mortbay.log: call filter guice
> >>>>> 14/06/24 17:26:31 DEBUG mortbay.log: RESPONSE /ws/v1/slider/mgmt/app
> 200
> >>>>>
> >>>>> Whereas an unsuccessful agent request looks like this:
> >>>>>
> >>>>> 14/06/24 17:11:46 DEBUG mortbay.log: REQUEST
> >>>>> /ws-agent/v1/slider/agents/register on
> >>>>> org.mortbay.jetty.HttpConnection@1ad901b1
> >>>>> 14/06/24 17:11:46 DEBUG mortbay.log:
> >>>>> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@372cab4
> >>>>> 14/06/24 17:11:46 DEBUG mortbay.log: session=null
> >>>>> 14/06/24 17:11:46 DEBUG mortbay.log: servlet=default
> >>>>> 14/06/24 17:11:46 DEBUG mortbay.log:
> >>>>> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
> >>>>> 14/06/24 17:11:46 DEBUG mortbay.log: servlet holder=default
> >>>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter NoCacheFilter
> >>>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter safety
> >>>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter AM_PROXY_FILTER
> >>>>> 14/06/24 17:11:46 DEBUG web.SliderAmIpFilter: Remote address for
> request
> >>>>> is: 192.168.64.1
> >>>>> 14/06/24 17:11:47 DEBUG mortbay.log: EOF
> >>>>> 14/06/24 17:11:49 WARN web.SliderAmIpFilter: Could not find
> proxy-user
> >>>>> cookie, so user will not be set
> >>>>> 14/06/24 17:11:50 DEBUG mortbay.log: call filter guice
> >>>>> 14/06/24 17:11:50 DEBUG mortbay.log: call servlet default
> >>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
> >>>>>
> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register.gz
> >>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
> >>>>>
> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
> >>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
> >>>>>
> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
> >>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
> >>>>>
> resource=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
> >>>>> 14/06/24 17:11:50 DEBUG mortbay.log: RESPONSE
> >>>>> /ws-agent/v1/slider/agents/register 404
> >>>>>
> >>>>> The second request shows that the guice interaction did not yield a
> >>>>> response and the next filter (default) is attempted.
> >>>>>
> >>>>> Anyone have any experience with this sort of configuration (multiple
> >>>>> instantiated web apps/guice containers)?
> >>>>>
> >>>>> — Jon
> >>>>>
> >>>>>
> >>>>> --
> >>>>> CONFIDENTIALITY NOTICE
> >>>>> NOTICE: This message is intended for the use of the individual or
> entity to
> >>>>> which it is addressed and may contain information that is
> confidential,
> >>>>> privileged and exempt from disclosure under applicable law. If the
> reader
> >>>>> of this message is not the intended recipient, you are hereby
> notified that
> >>>>> any printing, copying, dissemination, distribution, disclosure or
> >>>>> forwarding of this communication is strictly prohibited. If you have
> >>>>> received this communication in error, please contact the sender
> immediately
> >>>>> and delete it from your system. Thank You.
> >>>>>
> >>>>
> >>
> >
>
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Help with Guice/Jersey
Posted by Jon Maron <jm...@hortonworks.com>.
On Jun 25, 2014, at 6:16 PM, Jon Maron <jm...@hortonworks.com> wrote:
> Spent today trying to get the approach indicated in the link below to work, but the version of Guice in yarn pre-dates a required change. Moving on to Plan B: creating a completely separate jetty embedded instance w/o the reliance on guice.
Or the GuiceFilter, with its static pipeline, to be more exact...
>
> — Jon
>
> On Jun 25, 2014, at 11:18 AM, Jon Maron <jm...@hortonworks.com> wrote:
>
>> For the curious, this appears to be the issue:
>>
>> http://stackoverflow.com/questions/9074704/embedded-jetty-different-ports-for-internally-and-externally-visible-endpoints
>>
>> I may undertake to implement the specified approach (though the package scope constructor trick is a little…hokey?) just to see if:
>>
>> 1) It does in fact solve the issue and
>> 2) Allows for leveraging the existing HTTP yarn infrastructure pending a potential fix in guice
>>
>> Alternatively, I imagine the ambari server exposes multiple endpoints, some secure, some not, so if the approach above proves troublesome we many need to go down a similar path of instantiating a separate HTTP stack.
>>
>> — Jon
>>
>> On Jun 25, 2014, at 11:05 AM, Jon Maron <jm...@hortonworks.com> wrote:
>>
>>> I would agree as well. My concern is introducing yet another HTTP layer that ultimately would need to be tracked for alignment with any security layers introduced (knox, cert stores, credential stores, etc). I think the ideal is to have a single HTTP implementation that can be leveraged by AM developers that fulfills expected requirements (multiple listeners, secure listeners)
>>>
>>> — Jon
>>>
>>> On Jun 25, 2014, at 10:52 AM, Josh Elser <jo...@gmail.com> wrote:
>>>
>>>> Totally agree. Writing code that makes it more "amenable" to accepting the objects it's operating on is much easier in the long run.
>>>>
>>>> FWIW, I have recently been playing with Dropwizard[1] and really like it from a perspective of staying out of the way and just letting me write a REST service. I know that's not an answer to the question you asked, but thought it might be relevant :)
>>>>
>>>> [1] https://github.com/dropwizard/dropwizard
>>>>
>>>> On 6/24/14, 7:59 PM, Steve Loughran wrote:
>>>>> I always find Injection troublesome too. It helps with mocking, it helps if
>>>>> you want spring-style config wiring up of an app from components, but the
>>>>> classic "pass things as constructors" strategy often works too -and its
>>>>> essentially what I've resorted to in places
>>>>>
>>>>>
>>>>> On 24 June 2014 12:36, Jon Maron <jm...@hortonworks.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am attempting to split out the Slider agent-based HTTP resources into
>>>>>> a separate web application in order to explicit secure those interactions
>>>>>> (SSL etc). In doing so I am leveraging the Jersey/Guice/Jetty based web
>>>>>> app infrastructure in Yarn.
>>>>>>
>>>>>> It appears that even though I have split off a separate yarn web app
>>>>>> instance, configured with the associated agent resources, those new
>>>>>> resources can not be reached/found (the other non-agent resources still
>>>>>> managed by the SliderAMWebApp still work). In other words, even though
>>>>>> each WebApp instance is configured with its own GuiceContainer, for some
>>>>>> reason the agent web app can not return those resources when requested (my
>>>>>> understanding is that a GuiceContainer will scan the classes bound to the
>>>>>> servlet module to identify configured resources and providers. In a
>>>>>> debugger I’ve also seen that that scan appears to take place).
>>>>>>
>>>>>> A successful, non-agent request looks like this:
>>>>>>
>>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: REQUEST /ws/v1/slider/mgmt/app on
>>>>>> org.mortbay.jetty.HttpConnection@d2c5c4d
>>>>>> 14/06/24 17:26:28 DEBUG mortbay.log:
>>>>>> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@6602b61b
>>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: session=null
>>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: servlet=default
>>>>>> 14/06/24 17:26:28 DEBUG mortbay.log:
>>>>>> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
>>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: servlet holder=default
>>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter NoCacheFilter
>>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter safety
>>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter AM_PROXY_FILTER
>>>>>> 14/06/24 17:26:28 DEBUG web.SliderAmIpFilter: Remote address for request
>>>>>> is: 192.168.64.1
>>>>>> 14/06/24 17:26:30 WARN web.SliderAmIpFilter: Could not find proxy-user
>>>>>> cookie, so user will not be set
>>>>>> 14/06/24 17:26:31 DEBUG mortbay.log: call filter guice
>>>>>> 14/06/24 17:26:31 DEBUG mortbay.log: RESPONSE /ws/v1/slider/mgmt/app 200
>>>>>>
>>>>>> Whereas an unsuccessful agent request looks like this:
>>>>>>
>>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: REQUEST
>>>>>> /ws-agent/v1/slider/agents/register on
>>>>>> org.mortbay.jetty.HttpConnection@1ad901b1
>>>>>> 14/06/24 17:11:46 DEBUG mortbay.log:
>>>>>> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@372cab4
>>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: session=null
>>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: servlet=default
>>>>>> 14/06/24 17:11:46 DEBUG mortbay.log:
>>>>>> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
>>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: servlet holder=default
>>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter NoCacheFilter
>>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter safety
>>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter AM_PROXY_FILTER
>>>>>> 14/06/24 17:11:46 DEBUG web.SliderAmIpFilter: Remote address for request
>>>>>> is: 192.168.64.1
>>>>>> 14/06/24 17:11:47 DEBUG mortbay.log: EOF
>>>>>> 14/06/24 17:11:49 WARN web.SliderAmIpFilter: Could not find proxy-user
>>>>>> cookie, so user will not be set
>>>>>> 14/06/24 17:11:50 DEBUG mortbay.log: call filter guice
>>>>>> 14/06/24 17:11:50 DEBUG mortbay.log: call servlet default
>>>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>>>>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register.gz
>>>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>>>>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>>>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>>>>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>>>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>>>>> resource=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>>>>>> 14/06/24 17:11:50 DEBUG mortbay.log: RESPONSE
>>>>>> /ws-agent/v1/slider/agents/register 404
>>>>>>
>>>>>> The second request shows that the guice interaction did not yield a
>>>>>> response and the next filter (default) is attempted.
>>>>>>
>>>>>> Anyone have any experience with this sort of configuration (multiple
>>>>>> instantiated web apps/guice containers)?
>>>>>>
>>>>>> — Jon
>>>>>>
>>>>>>
>>>>>> --
>>>>>> CONFIDENTIALITY NOTICE
>>>>>> NOTICE: This message is intended for the use of the individual or entity to
>>>>>> which it is addressed and may contain information that is confidential,
>>>>>> privileged and exempt from disclosure under applicable law. If the reader
>>>>>> of this message is not the intended recipient, you are hereby notified that
>>>>>> any printing, copying, dissemination, distribution, disclosure or
>>>>>> forwarding of this communication is strictly prohibited. If you have
>>>>>> received this communication in error, please contact the sender immediately
>>>>>> and delete it from your system. Thank You.
>>>>>>
>>>>>
>>>
>>
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Help with Guice/Jersey
Posted by Jon Maron <jm...@hortonworks.com>.
Spent today trying to get the approach indicated in the link below to work, but the version of Guice in yarn pre-dates a required change. Moving on to Plan B: creating a completely separate jetty embedded instance w/o the reliance on guice.
— Jon
On Jun 25, 2014, at 11:18 AM, Jon Maron <jm...@hortonworks.com> wrote:
> For the curious, this appears to be the issue:
>
> http://stackoverflow.com/questions/9074704/embedded-jetty-different-ports-for-internally-and-externally-visible-endpoints
>
> I may undertake to implement the specified approach (though the package scope constructor trick is a little…hokey?) just to see if:
>
> 1) It does in fact solve the issue and
> 2) Allows for leveraging the existing HTTP yarn infrastructure pending a potential fix in guice
>
> Alternatively, I imagine the ambari server exposes multiple endpoints, some secure, some not, so if the approach above proves troublesome we many need to go down a similar path of instantiating a separate HTTP stack.
>
> — Jon
>
> On Jun 25, 2014, at 11:05 AM, Jon Maron <jm...@hortonworks.com> wrote:
>
>> I would agree as well. My concern is introducing yet another HTTP layer that ultimately would need to be tracked for alignment with any security layers introduced (knox, cert stores, credential stores, etc). I think the ideal is to have a single HTTP implementation that can be leveraged by AM developers that fulfills expected requirements (multiple listeners, secure listeners)
>>
>> — Jon
>>
>> On Jun 25, 2014, at 10:52 AM, Josh Elser <jo...@gmail.com> wrote:
>>
>>> Totally agree. Writing code that makes it more "amenable" to accepting the objects it's operating on is much easier in the long run.
>>>
>>> FWIW, I have recently been playing with Dropwizard[1] and really like it from a perspective of staying out of the way and just letting me write a REST service. I know that's not an answer to the question you asked, but thought it might be relevant :)
>>>
>>> [1] https://github.com/dropwizard/dropwizard
>>>
>>> On 6/24/14, 7:59 PM, Steve Loughran wrote:
>>>> I always find Injection troublesome too. It helps with mocking, it helps if
>>>> you want spring-style config wiring up of an app from components, but the
>>>> classic "pass things as constructors" strategy often works too -and its
>>>> essentially what I've resorted to in places
>>>>
>>>>
>>>> On 24 June 2014 12:36, Jon Maron <jm...@hortonworks.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am attempting to split out the Slider agent-based HTTP resources into
>>>>> a separate web application in order to explicit secure those interactions
>>>>> (SSL etc). In doing so I am leveraging the Jersey/Guice/Jetty based web
>>>>> app infrastructure in Yarn.
>>>>>
>>>>> It appears that even though I have split off a separate yarn web app
>>>>> instance, configured with the associated agent resources, those new
>>>>> resources can not be reached/found (the other non-agent resources still
>>>>> managed by the SliderAMWebApp still work). In other words, even though
>>>>> each WebApp instance is configured with its own GuiceContainer, for some
>>>>> reason the agent web app can not return those resources when requested (my
>>>>> understanding is that a GuiceContainer will scan the classes bound to the
>>>>> servlet module to identify configured resources and providers. In a
>>>>> debugger I’ve also seen that that scan appears to take place).
>>>>>
>>>>> A successful, non-agent request looks like this:
>>>>>
>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: REQUEST /ws/v1/slider/mgmt/app on
>>>>> org.mortbay.jetty.HttpConnection@d2c5c4d
>>>>> 14/06/24 17:26:28 DEBUG mortbay.log:
>>>>> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@6602b61b
>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: session=null
>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: servlet=default
>>>>> 14/06/24 17:26:28 DEBUG mortbay.log:
>>>>> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: servlet holder=default
>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter NoCacheFilter
>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter safety
>>>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter AM_PROXY_FILTER
>>>>> 14/06/24 17:26:28 DEBUG web.SliderAmIpFilter: Remote address for request
>>>>> is: 192.168.64.1
>>>>> 14/06/24 17:26:30 WARN web.SliderAmIpFilter: Could not find proxy-user
>>>>> cookie, so user will not be set
>>>>> 14/06/24 17:26:31 DEBUG mortbay.log: call filter guice
>>>>> 14/06/24 17:26:31 DEBUG mortbay.log: RESPONSE /ws/v1/slider/mgmt/app 200
>>>>>
>>>>> Whereas an unsuccessful agent request looks like this:
>>>>>
>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: REQUEST
>>>>> /ws-agent/v1/slider/agents/register on
>>>>> org.mortbay.jetty.HttpConnection@1ad901b1
>>>>> 14/06/24 17:11:46 DEBUG mortbay.log:
>>>>> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@372cab4
>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: session=null
>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: servlet=default
>>>>> 14/06/24 17:11:46 DEBUG mortbay.log:
>>>>> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: servlet holder=default
>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter NoCacheFilter
>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter safety
>>>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter AM_PROXY_FILTER
>>>>> 14/06/24 17:11:46 DEBUG web.SliderAmIpFilter: Remote address for request
>>>>> is: 192.168.64.1
>>>>> 14/06/24 17:11:47 DEBUG mortbay.log: EOF
>>>>> 14/06/24 17:11:49 WARN web.SliderAmIpFilter: Could not find proxy-user
>>>>> cookie, so user will not be set
>>>>> 14/06/24 17:11:50 DEBUG mortbay.log: call filter guice
>>>>> 14/06/24 17:11:50 DEBUG mortbay.log: call servlet default
>>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>>>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register.gz
>>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>>>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>>>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>>>> resource=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>>>>> 14/06/24 17:11:50 DEBUG mortbay.log: RESPONSE
>>>>> /ws-agent/v1/slider/agents/register 404
>>>>>
>>>>> The second request shows that the guice interaction did not yield a
>>>>> response and the next filter (default) is attempted.
>>>>>
>>>>> Anyone have any experience with this sort of configuration (multiple
>>>>> instantiated web apps/guice containers)?
>>>>>
>>>>> — Jon
>>>>>
>>>>>
>>>>> --
>>>>> CONFIDENTIALITY NOTICE
>>>>> NOTICE: This message is intended for the use of the individual or entity to
>>>>> which it is addressed and may contain information that is confidential,
>>>>> privileged and exempt from disclosure under applicable law. If the reader
>>>>> of this message is not the intended recipient, you are hereby notified that
>>>>> any printing, copying, dissemination, distribution, disclosure or
>>>>> forwarding of this communication is strictly prohibited. If you have
>>>>> received this communication in error, please contact the sender immediately
>>>>> and delete it from your system. Thank You.
>>>>>
>>>>
>>
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Help with Guice/Jersey
Posted by Jon Maron <jm...@hortonworks.com>.
For the curious, this appears to be the issue:
http://stackoverflow.com/questions/9074704/embedded-jetty-different-ports-for-internally-and-externally-visible-endpoints
I may undertake to implement the specified approach (though the package scope constructor trick is a little…hokey?) just to see if:
1) It does in fact solve the issue and
2) Allows for leveraging the existing HTTP yarn infrastructure pending a potential fix in guice
Alternatively, I imagine the ambari server exposes multiple endpoints, some secure, some not, so if the approach above proves troublesome we many need to go down a similar path of instantiating a separate HTTP stack.
— Jon
On Jun 25, 2014, at 11:05 AM, Jon Maron <jm...@hortonworks.com> wrote:
> I would agree as well. My concern is introducing yet another HTTP layer that ultimately would need to be tracked for alignment with any security layers introduced (knox, cert stores, credential stores, etc). I think the ideal is to have a single HTTP implementation that can be leveraged by AM developers that fulfills expected requirements (multiple listeners, secure listeners)
>
> — Jon
>
> On Jun 25, 2014, at 10:52 AM, Josh Elser <jo...@gmail.com> wrote:
>
>> Totally agree. Writing code that makes it more "amenable" to accepting the objects it's operating on is much easier in the long run.
>>
>> FWIW, I have recently been playing with Dropwizard[1] and really like it from a perspective of staying out of the way and just letting me write a REST service. I know that's not an answer to the question you asked, but thought it might be relevant :)
>>
>> [1] https://github.com/dropwizard/dropwizard
>>
>> On 6/24/14, 7:59 PM, Steve Loughran wrote:
>>> I always find Injection troublesome too. It helps with mocking, it helps if
>>> you want spring-style config wiring up of an app from components, but the
>>> classic "pass things as constructors" strategy often works too -and its
>>> essentially what I've resorted to in places
>>>
>>>
>>> On 24 June 2014 12:36, Jon Maron <jm...@hortonworks.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am attempting to split out the Slider agent-based HTTP resources into
>>>> a separate web application in order to explicit secure those interactions
>>>> (SSL etc). In doing so I am leveraging the Jersey/Guice/Jetty based web
>>>> app infrastructure in Yarn.
>>>>
>>>> It appears that even though I have split off a separate yarn web app
>>>> instance, configured with the associated agent resources, those new
>>>> resources can not be reached/found (the other non-agent resources still
>>>> managed by the SliderAMWebApp still work). In other words, even though
>>>> each WebApp instance is configured with its own GuiceContainer, for some
>>>> reason the agent web app can not return those resources when requested (my
>>>> understanding is that a GuiceContainer will scan the classes bound to the
>>>> servlet module to identify configured resources and providers. In a
>>>> debugger I’ve also seen that that scan appears to take place).
>>>>
>>>> A successful, non-agent request looks like this:
>>>>
>>>> 14/06/24 17:26:28 DEBUG mortbay.log: REQUEST /ws/v1/slider/mgmt/app on
>>>> org.mortbay.jetty.HttpConnection@d2c5c4d
>>>> 14/06/24 17:26:28 DEBUG mortbay.log:
>>>> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@6602b61b
>>>> 14/06/24 17:26:28 DEBUG mortbay.log: session=null
>>>> 14/06/24 17:26:28 DEBUG mortbay.log: servlet=default
>>>> 14/06/24 17:26:28 DEBUG mortbay.log:
>>>> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
>>>> 14/06/24 17:26:28 DEBUG mortbay.log: servlet holder=default
>>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter NoCacheFilter
>>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter safety
>>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter AM_PROXY_FILTER
>>>> 14/06/24 17:26:28 DEBUG web.SliderAmIpFilter: Remote address for request
>>>> is: 192.168.64.1
>>>> 14/06/24 17:26:30 WARN web.SliderAmIpFilter: Could not find proxy-user
>>>> cookie, so user will not be set
>>>> 14/06/24 17:26:31 DEBUG mortbay.log: call filter guice
>>>> 14/06/24 17:26:31 DEBUG mortbay.log: RESPONSE /ws/v1/slider/mgmt/app 200
>>>>
>>>> Whereas an unsuccessful agent request looks like this:
>>>>
>>>> 14/06/24 17:11:46 DEBUG mortbay.log: REQUEST
>>>> /ws-agent/v1/slider/agents/register on
>>>> org.mortbay.jetty.HttpConnection@1ad901b1
>>>> 14/06/24 17:11:46 DEBUG mortbay.log:
>>>> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@372cab4
>>>> 14/06/24 17:11:46 DEBUG mortbay.log: session=null
>>>> 14/06/24 17:11:46 DEBUG mortbay.log: servlet=default
>>>> 14/06/24 17:11:46 DEBUG mortbay.log:
>>>> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
>>>> 14/06/24 17:11:46 DEBUG mortbay.log: servlet holder=default
>>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter NoCacheFilter
>>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter safety
>>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter AM_PROXY_FILTER
>>>> 14/06/24 17:11:46 DEBUG web.SliderAmIpFilter: Remote address for request
>>>> is: 192.168.64.1
>>>> 14/06/24 17:11:47 DEBUG mortbay.log: EOF
>>>> 14/06/24 17:11:49 WARN web.SliderAmIpFilter: Could not find proxy-user
>>>> cookie, so user will not be set
>>>> 14/06/24 17:11:50 DEBUG mortbay.log: call filter guice
>>>> 14/06/24 17:11:50 DEBUG mortbay.log: call servlet default
>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register.gz
>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>>> resource=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>>>> 14/06/24 17:11:50 DEBUG mortbay.log: RESPONSE
>>>> /ws-agent/v1/slider/agents/register 404
>>>>
>>>> The second request shows that the guice interaction did not yield a
>>>> response and the next filter (default) is attempted.
>>>>
>>>> Anyone have any experience with this sort of configuration (multiple
>>>> instantiated web apps/guice containers)?
>>>>
>>>> — Jon
>>>>
>>>>
>>>> --
>>>> CONFIDENTIALITY NOTICE
>>>> NOTICE: This message is intended for the use of the individual or entity to
>>>> which it is addressed and may contain information that is confidential,
>>>> privileged and exempt from disclosure under applicable law. If the reader
>>>> of this message is not the intended recipient, you are hereby notified that
>>>> any printing, copying, dissemination, distribution, disclosure or
>>>> forwarding of this communication is strictly prohibited. If you have
>>>> received this communication in error, please contact the sender immediately
>>>> and delete it from your system. Thank You.
>>>>
>>>
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Help with Guice/Jersey
Posted by Jon Maron <jm...@hortonworks.com>.
I would agree as well. My concern is introducing yet another HTTP layer that ultimately would need to be tracked for alignment with any security layers introduced (knox, cert stores, credential stores, etc). I think the ideal is to have a single HTTP implementation that can be leveraged by AM developers that fulfills expected requirements (multiple listeners, secure listeners)
— Jon
On Jun 25, 2014, at 10:52 AM, Josh Elser <jo...@gmail.com> wrote:
> Totally agree. Writing code that makes it more "amenable" to accepting the objects it's operating on is much easier in the long run.
>
> FWIW, I have recently been playing with Dropwizard[1] and really like it from a perspective of staying out of the way and just letting me write a REST service. I know that's not an answer to the question you asked, but thought it might be relevant :)
>
> [1] https://github.com/dropwizard/dropwizard
>
> On 6/24/14, 7:59 PM, Steve Loughran wrote:
>> I always find Injection troublesome too. It helps with mocking, it helps if
>> you want spring-style config wiring up of an app from components, but the
>> classic "pass things as constructors" strategy often works too -and its
>> essentially what I've resorted to in places
>>
>>
>> On 24 June 2014 12:36, Jon Maron <jm...@hortonworks.com> wrote:
>>
>>> Hi,
>>>
>>> I am attempting to split out the Slider agent-based HTTP resources into
>>> a separate web application in order to explicit secure those interactions
>>> (SSL etc). In doing so I am leveraging the Jersey/Guice/Jetty based web
>>> app infrastructure in Yarn.
>>>
>>> It appears that even though I have split off a separate yarn web app
>>> instance, configured with the associated agent resources, those new
>>> resources can not be reached/found (the other non-agent resources still
>>> managed by the SliderAMWebApp still work). In other words, even though
>>> each WebApp instance is configured with its own GuiceContainer, for some
>>> reason the agent web app can not return those resources when requested (my
>>> understanding is that a GuiceContainer will scan the classes bound to the
>>> servlet module to identify configured resources and providers. In a
>>> debugger I’ve also seen that that scan appears to take place).
>>>
>>> A successful, non-agent request looks like this:
>>>
>>> 14/06/24 17:26:28 DEBUG mortbay.log: REQUEST /ws/v1/slider/mgmt/app on
>>> org.mortbay.jetty.HttpConnection@d2c5c4d
>>> 14/06/24 17:26:28 DEBUG mortbay.log:
>>> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@6602b61b
>>> 14/06/24 17:26:28 DEBUG mortbay.log: session=null
>>> 14/06/24 17:26:28 DEBUG mortbay.log: servlet=default
>>> 14/06/24 17:26:28 DEBUG mortbay.log:
>>> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
>>> 14/06/24 17:26:28 DEBUG mortbay.log: servlet holder=default
>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter NoCacheFilter
>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter safety
>>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter AM_PROXY_FILTER
>>> 14/06/24 17:26:28 DEBUG web.SliderAmIpFilter: Remote address for request
>>> is: 192.168.64.1
>>> 14/06/24 17:26:30 WARN web.SliderAmIpFilter: Could not find proxy-user
>>> cookie, so user will not be set
>>> 14/06/24 17:26:31 DEBUG mortbay.log: call filter guice
>>> 14/06/24 17:26:31 DEBUG mortbay.log: RESPONSE /ws/v1/slider/mgmt/app 200
>>>
>>> Whereas an unsuccessful agent request looks like this:
>>>
>>> 14/06/24 17:11:46 DEBUG mortbay.log: REQUEST
>>> /ws-agent/v1/slider/agents/register on
>>> org.mortbay.jetty.HttpConnection@1ad901b1
>>> 14/06/24 17:11:46 DEBUG mortbay.log:
>>> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@372cab4
>>> 14/06/24 17:11:46 DEBUG mortbay.log: session=null
>>> 14/06/24 17:11:46 DEBUG mortbay.log: servlet=default
>>> 14/06/24 17:11:46 DEBUG mortbay.log:
>>> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
>>> 14/06/24 17:11:46 DEBUG mortbay.log: servlet holder=default
>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter NoCacheFilter
>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter safety
>>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter AM_PROXY_FILTER
>>> 14/06/24 17:11:46 DEBUG web.SliderAmIpFilter: Remote address for request
>>> is: 192.168.64.1
>>> 14/06/24 17:11:47 DEBUG mortbay.log: EOF
>>> 14/06/24 17:11:49 WARN web.SliderAmIpFilter: Could not find proxy-user
>>> cookie, so user will not be set
>>> 14/06/24 17:11:50 DEBUG mortbay.log: call filter guice
>>> 14/06/24 17:11:50 DEBUG mortbay.log: call servlet default
>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register.gz
>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>>> 14/06/24 17:11:50 DEBUG mortbay.log:
>>> resource=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>>> 14/06/24 17:11:50 DEBUG mortbay.log: RESPONSE
>>> /ws-agent/v1/slider/agents/register 404
>>>
>>> The second request shows that the guice interaction did not yield a
>>> response and the next filter (default) is attempted.
>>>
>>> Anyone have any experience with this sort of configuration (multiple
>>> instantiated web apps/guice containers)?
>>>
>>> — Jon
>>>
>>>
>>> --
>>> CONFIDENTIALITY NOTICE
>>> NOTICE: This message is intended for the use of the individual or entity to
>>> which it is addressed and may contain information that is confidential,
>>> privileged and exempt from disclosure under applicable law. If the reader
>>> of this message is not the intended recipient, you are hereby notified that
>>> any printing, copying, dissemination, distribution, disclosure or
>>> forwarding of this communication is strictly prohibited. If you have
>>> received this communication in error, please contact the sender immediately
>>> and delete it from your system. Thank You.
>>>
>>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Help with Guice/Jersey
Posted by Josh Elser <jo...@gmail.com>.
Totally agree. Writing code that makes it more "amenable" to accepting
the objects it's operating on is much easier in the long run.
FWIW, I have recently been playing with Dropwizard[1] and really like it
from a perspective of staying out of the way and just letting me write a
REST service. I know that's not an answer to the question you asked, but
thought it might be relevant :)
[1] https://github.com/dropwizard/dropwizard
On 6/24/14, 7:59 PM, Steve Loughran wrote:
> I always find Injection troublesome too. It helps with mocking, it helps if
> you want spring-style config wiring up of an app from components, but the
> classic "pass things as constructors" strategy often works too -and its
> essentially what I've resorted to in places
>
>
> On 24 June 2014 12:36, Jon Maron <jm...@hortonworks.com> wrote:
>
>> Hi,
>>
>> I am attempting to split out the Slider agent-based HTTP resources into
>> a separate web application in order to explicit secure those interactions
>> (SSL etc). In doing so I am leveraging the Jersey/Guice/Jetty based web
>> app infrastructure in Yarn.
>>
>> It appears that even though I have split off a separate yarn web app
>> instance, configured with the associated agent resources, those new
>> resources can not be reached/found (the other non-agent resources still
>> managed by the SliderAMWebApp still work). In other words, even though
>> each WebApp instance is configured with its own GuiceContainer, for some
>> reason the agent web app can not return those resources when requested (my
>> understanding is that a GuiceContainer will scan the classes bound to the
>> servlet module to identify configured resources and providers. In a
>> debugger I’ve also seen that that scan appears to take place).
>>
>> A successful, non-agent request looks like this:
>>
>> 14/06/24 17:26:28 DEBUG mortbay.log: REQUEST /ws/v1/slider/mgmt/app on
>> org.mortbay.jetty.HttpConnection@d2c5c4d
>> 14/06/24 17:26:28 DEBUG mortbay.log:
>> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@6602b61b
>> 14/06/24 17:26:28 DEBUG mortbay.log: session=null
>> 14/06/24 17:26:28 DEBUG mortbay.log: servlet=default
>> 14/06/24 17:26:28 DEBUG mortbay.log:
>> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
>> 14/06/24 17:26:28 DEBUG mortbay.log: servlet holder=default
>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter NoCacheFilter
>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter safety
>> 14/06/24 17:26:28 DEBUG mortbay.log: call filter AM_PROXY_FILTER
>> 14/06/24 17:26:28 DEBUG web.SliderAmIpFilter: Remote address for request
>> is: 192.168.64.1
>> 14/06/24 17:26:30 WARN web.SliderAmIpFilter: Could not find proxy-user
>> cookie, so user will not be set
>> 14/06/24 17:26:31 DEBUG mortbay.log: call filter guice
>> 14/06/24 17:26:31 DEBUG mortbay.log: RESPONSE /ws/v1/slider/mgmt/app 200
>>
>> Whereas an unsuccessful agent request looks like this:
>>
>> 14/06/24 17:11:46 DEBUG mortbay.log: REQUEST
>> /ws-agent/v1/slider/agents/register on
>> org.mortbay.jetty.HttpConnection@1ad901b1
>> 14/06/24 17:11:46 DEBUG mortbay.log:
>> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@372cab4
>> 14/06/24 17:11:46 DEBUG mortbay.log: session=null
>> 14/06/24 17:11:46 DEBUG mortbay.log: servlet=default
>> 14/06/24 17:11:46 DEBUG mortbay.log:
>> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
>> 14/06/24 17:11:46 DEBUG mortbay.log: servlet holder=default
>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter NoCacheFilter
>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter safety
>> 14/06/24 17:11:46 DEBUG mortbay.log: call filter AM_PROXY_FILTER
>> 14/06/24 17:11:46 DEBUG web.SliderAmIpFilter: Remote address for request
>> is: 192.168.64.1
>> 14/06/24 17:11:47 DEBUG mortbay.log: EOF
>> 14/06/24 17:11:49 WARN web.SliderAmIpFilter: Could not find proxy-user
>> cookie, so user will not be set
>> 14/06/24 17:11:50 DEBUG mortbay.log: call filter guice
>> 14/06/24 17:11:50 DEBUG mortbay.log: call servlet default
>> 14/06/24 17:11:50 DEBUG mortbay.log:
>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register.gz
>> 14/06/24 17:11:50 DEBUG mortbay.log:
>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>> 14/06/24 17:11:50 DEBUG mortbay.log:
>> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>> 14/06/24 17:11:50 DEBUG mortbay.log:
>> resource=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
>> 14/06/24 17:11:50 DEBUG mortbay.log: RESPONSE
>> /ws-agent/v1/slider/agents/register 404
>>
>> The second request shows that the guice interaction did not yield a
>> response and the next filter (default) is attempted.
>>
>> Anyone have any experience with this sort of configuration (multiple
>> instantiated web apps/guice containers)?
>>
>> — Jon
>>
>>
>> --
>> CONFIDENTIALITY NOTICE
>> NOTICE: This message is intended for the use of the individual or entity to
>> which it is addressed and may contain information that is confidential,
>> privileged and exempt from disclosure under applicable law. If the reader
>> of this message is not the intended recipient, you are hereby notified that
>> any printing, copying, dissemination, distribution, disclosure or
>> forwarding of this communication is strictly prohibited. If you have
>> received this communication in error, please contact the sender immediately
>> and delete it from your system. Thank You.
>>
>
Re: Help with Guice/Jersey
Posted by Steve Loughran <st...@hortonworks.com>.
I always find Injection troublesome too. It helps with mocking, it helps if
you want spring-style config wiring up of an app from components, but the
classic "pass things as constructors" strategy often works too -and its
essentially what I've resorted to in places
On 24 June 2014 12:36, Jon Maron <jm...@hortonworks.com> wrote:
> Hi,
>
> I am attempting to split out the Slider agent-based HTTP resources into
> a separate web application in order to explicit secure those interactions
> (SSL etc). In doing so I am leveraging the Jersey/Guice/Jetty based web
> app infrastructure in Yarn.
>
> It appears that even though I have split off a separate yarn web app
> instance, configured with the associated agent resources, those new
> resources can not be reached/found (the other non-agent resources still
> managed by the SliderAMWebApp still work). In other words, even though
> each WebApp instance is configured with its own GuiceContainer, for some
> reason the agent web app can not return those resources when requested (my
> understanding is that a GuiceContainer will scan the classes bound to the
> servlet module to identify configured resources and providers. In a
> debugger I’ve also seen that that scan appears to take place).
>
> A successful, non-agent request looks like this:
>
> 14/06/24 17:26:28 DEBUG mortbay.log: REQUEST /ws/v1/slider/mgmt/app on
> org.mortbay.jetty.HttpConnection@d2c5c4d
> 14/06/24 17:26:28 DEBUG mortbay.log:
> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@6602b61b
> 14/06/24 17:26:28 DEBUG mortbay.log: session=null
> 14/06/24 17:26:28 DEBUG mortbay.log: servlet=default
> 14/06/24 17:26:28 DEBUG mortbay.log:
> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
> 14/06/24 17:26:28 DEBUG mortbay.log: servlet holder=default
> 14/06/24 17:26:28 DEBUG mortbay.log: call filter NoCacheFilter
> 14/06/24 17:26:28 DEBUG mortbay.log: call filter safety
> 14/06/24 17:26:28 DEBUG mortbay.log: call filter AM_PROXY_FILTER
> 14/06/24 17:26:28 DEBUG web.SliderAmIpFilter: Remote address for request
> is: 192.168.64.1
> 14/06/24 17:26:30 WARN web.SliderAmIpFilter: Could not find proxy-user
> cookie, so user will not be set
> 14/06/24 17:26:31 DEBUG mortbay.log: call filter guice
> 14/06/24 17:26:31 DEBUG mortbay.log: RESPONSE /ws/v1/slider/mgmt/app 200
>
> Whereas an unsuccessful agent request looks like this:
>
> 14/06/24 17:11:46 DEBUG mortbay.log: REQUEST
> /ws-agent/v1/slider/agents/register on
> org.mortbay.jetty.HttpConnection@1ad901b1
> 14/06/24 17:11:46 DEBUG mortbay.log:
> sessionManager=org.mortbay.jetty.servlet.HashSessionManager@372cab4
> 14/06/24 17:11:46 DEBUG mortbay.log: session=null
> 14/06/24 17:11:46 DEBUG mortbay.log: servlet=default
> 14/06/24 17:11:46 DEBUG mortbay.log:
> chain=NoCacheFilter->safety->AM_PROXY_FILTER->guice->default
> 14/06/24 17:11:46 DEBUG mortbay.log: servlet holder=default
> 14/06/24 17:11:46 DEBUG mortbay.log: call filter NoCacheFilter
> 14/06/24 17:11:46 DEBUG mortbay.log: call filter safety
> 14/06/24 17:11:46 DEBUG mortbay.log: call filter AM_PROXY_FILTER
> 14/06/24 17:11:46 DEBUG web.SliderAmIpFilter: Remote address for request
> is: 192.168.64.1
> 14/06/24 17:11:47 DEBUG mortbay.log: EOF
> 14/06/24 17:11:49 WARN web.SliderAmIpFilter: Could not find proxy-user
> cookie, so user will not be set
> 14/06/24 17:11:50 DEBUG mortbay.log: call filter guice
> 14/06/24 17:11:50 DEBUG mortbay.log: call servlet default
> 14/06/24 17:11:50 DEBUG mortbay.log:
> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register.gz
> 14/06/24 17:11:50 DEBUG mortbay.log:
> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
> 14/06/24 17:11:50 DEBUG mortbay.log:
> RESOURCE=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
> 14/06/24 17:11:50 DEBUG mortbay.log:
> resource=file:/tmp/Jetty_0_0_0_0_36606_slideragent____.aojpr6/webapp/ws-agent/v1/slider/agents/register
> 14/06/24 17:11:50 DEBUG mortbay.log: RESPONSE
> /ws-agent/v1/slider/agents/register 404
>
> The second request shows that the guice interaction did not yield a
> response and the next filter (default) is attempted.
>
> Anyone have any experience with this sort of configuration (multiple
> instantiated web apps/guice containers)?
>
> — Jon
>
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.