Add back AuthInfo class

AuthInfo class was removed by http://codereview.appspot.com/3305041
We are using it internally for injection, so this change add it as a wrapper to the AuthInfoUtil

(the other option is to rollback the AuthInfoUtil change)

[plindner1, 2010-12-06 23:23:38]

I'm confused about the inejction of HttpServletRequest, how does that work in a
non-request scope context?

To get around your compatibility problem I'm +1 on this change.

[zhoresh, 2010-12-06 23:29:02]

On Mon, Dec 6, 2010 at 3:23 PM, <plindner@google.com> wrote:

> I'm confused about the inejction of HttpServletRequest, how does that
> work in a non-request scope context?
>
Does not, it is always in the context of a Request, but the "client" just
see it as a token provider not as request provider.


> To get around your compatibility problem I'm +1 on this change.
>
>
> http://codereview.appspot.com/3477042/
>

[henry.saputra, 2010-12-07 00:31:04]

So Guice is able to know that for HttpServletRequest object its using the right
HttpServletRequest created by the servlet container?

So you were using the AuthInfo as @request scope object?

On 2010/12/06 23:29:02, zhoresh wrote:
> On Mon, Dec 6, 2010 at 3:23 PM, <mailto:plindner@google.com> wrote:
> 
> > I'm confused about the inejction of HttpServletRequest, how does that
> > work in a non-request scope context?
> >
> Does not, it is always in the context of a Request, but the "client" just
> see it as a token provider not as request provider.
> 
> 
> > To get around your compatibility problem I'm +1 on this change.
> >
> >
> > http://codereview.appspot.com/3477042/
> >

[henry.saputra, 2010-12-07 00:51:42]

Ok, that was bad comment/question =P

+1 to accomodate the Request scoped injection scenario.

But I think the AuthInfo class need have comment to note that it should be used
in a context of a Request scope. 

On 2010/12/07 00:31:04, henry.saputra wrote:
> So Guice is able to know that for HttpServletRequest object its using the
right
> HttpServletRequest created by the servlet container?
> 
> So you were using the AuthInfo as @request scope object?
> 
> On 2010/12/06 23:29:02, zhoresh wrote:
> > On Mon, Dec 6, 2010 at 3:23 PM, <mailto:plindner@google.com> wrote:
> > 
> > > I'm confused about the inejction of HttpServletRequest, how does that
> > > work in a non-request scope context?
> > >
> > Does not, it is always in the context of a Request, but the "client" just
> > see it as a token provider not as request provider.
> > 
> > 
> > > To get around your compatibility problem I'm +1 on this change.
> > >
> > >
> > > http://codereview.appspot.com/3477042/
> > >

[zhoresh, 2010-12-07 00:59:47]

Code snippet with in one of our modules:

  @Provides @RequestScoped
  SecurityToken provideSecurityToken(AuthInfo authInfo) {
    return authInfo.getSecurityToken();
  }

so yes it is within context of a request.
will add comment and commit.

Thanks


On Mon, Dec 6, 2010 at 4:51 PM, <henry.saputra@gmail.com> wrote:

> Ok, that was bad comment/question =P
>
> +1 to accomodate the Request scoped injection scenario.
>
> But I think the AuthInfo class need have comment to note that it should
> be used in a context of a Request scope.
>
>
> On 2010/12/07 00:31:04, henry.saputra wrote:
>
>> So Guice is able to know that for HttpServletRequest object its using
>>
> the right
>
>> HttpServletRequest created by the servlet container?
>>
>
>  So you were using the AuthInfo as @request scope object?
>>
>
>  On 2010/12/06 23:29:02, zhoresh wrote:
>> > On Mon, Dec 6, 2010 at 3:23 PM, <mailto:plindner@google.com> wrote:
>> >
>> > > I'm confused about the inejction of HttpServletRequest, how does
>>
> that
>
>> > > work in a non-request scope context?
>> > >
>> > Does not, it is always in the context of a Request, but the "client"
>>
> just
>
>> > see it as a token provider not as request provider.
>> >
>> >
>> > > To get around your compatibility problem I'm +1 on this change.
>> > >
>> > >
>> > > http://codereview.appspot.com/3477042/
>> > >
>>
>
>
>
> http://codereview.appspot.com/3477042/
>