OK I checked in the changes to the javadoc. -Ryan
From: A Clarke <cla...@gmail.com> To: dev@shindig.apache.org, Date: 06/12/2012 11:28 AM Subject: Re: OAuth2 token expiration and issue times broken Yes. On Tue, Jun 12, 2012 at 9:36 AM, Ryan J Baxter <rjbax...@us.ibm.com> wrote: > Adam is it just the javadoc for OAuth2Token.getIssueAt and > OAuth2Token.getExpiresAt that needs to be updated? > > -Ryan > > > > > From: A Clarke <cla...@gmail.com> > To: dev@shindig.apache.org, > Date: 06/12/2012 09:04 AM > Subject: Re: OAuth2 token expiration and issue times broken > > > > Looks like I forgot to update the interface javadoc. > > The intention is to use milliseconds now, this made it easier for other > teams to persist and compare values as timestamps. > > > > On Tue, Jun 12, 2012 at 8:23 AM, Ryan J Baxter <rjbax...@us.ibm.com> > wrote: > > > Doug, this was intentional I believe, although I can't remember the > reason > > exactly. Adam and Brian, can explain the logic behind this decision. > > > > > > > > -Ryan > > > > > > > > > > From: daviesd <davi...@oclc.org> > > To: shindig <dev@shindig.apache.org>, > > Date: 06/11/2012 04:15 PM > > Subject: OAuth2 token expiration and issue times broken > > > > > > > > The fix for SHINDIG-1732 introduces a bug with the oauth2 token expires > > and > > issue times (or at least a documentation change). The time stored in > > OAuth2Token use to be in seconds (and is documented that way). Now it¹s > > storing them in milliseconds in TokenAuthorizationResponseHandler. This > > causes me to blow up later when I persist them, since I was multiplying > by > > 1000 and the converting it to a Date. What is the correct behavior > here? > > > > doug > > > > > >
