Yay! Thanks for verifying it Doug =)
- Henry On Wed, Mar 7, 2012 at 11:36 AM, daviesd <davi...@oclc.org> wrote: > Yep. Works. Thanks! > > > On 3/7/12 2:22 PM, "Henry Saputra" <henry.sapu...@gmail.com> wrote: > >> Done, could you try the fix by pulling from trunk? >> >> - Henry >> >> On Wed, Mar 7, 2012 at 10:45 AM, daviesd <davi...@oclc.org> wrote: >>> Thank you. I've been banging my head on this all morning. ?Now if I can get >>> Paul to look at the guava collections stuff I might be good to go. :) >>> >>> doug >>> >>> >>> On 3/7/12 1:31 PM, "Henry Saputra" <henry.sapu...@gmail.com> wrote: >>> >>>> I think I know whats the problem, I remove the check for the >>>> UnsupportedOperationException in the >>>> BlobCrypterSecurityTokenCodec.fromToken to get activeUrl. >>>> >>>> The gadget handler code use the "delegator" to mock the security token >>>> instance and miss setting the active URL. >>>> >>>> Hence when the call to token.getActiveUrl it chokes. >>>> >>>> Honestly I think the whole delegator stuff is not working well. ?I >>>> will put up the patch to fix this. >>>> >>>> - Henry >>>> >>>> On Wed, Mar 7, 2012 at 8:11 AM, daviesd <davi...@oclc.org> wrote: >>>>> Henry, >>>>> >>>>> I changed our security token implementation to extend >>>>> AbstractSecurityToken >>>>> instead of just implementing SecurityToken. ?No difference. ?As I said, if >>>>> I >>>>> use a non-encrypted security token I don't see this error. ?I'm fighting a >>>>> couple of issues (including the one I mentioned to Paul earlier concerning >>>>> the google collection changes he made). ?Getting a little frustrating >>>>> getting things back in synch. >>>>> >>>>> doug >>>>> >>>>> >>>>> On 3/6/12 4:41 PM, "Henry Saputra" <henry.sapu...@gmail.com> wrote: >>>>> >>>>>> Do you extend the OurDefaultSecurityTokenCodec from >>>>>> AbstractSecurityToken? >>>>>> >>>>>> If you do then you dont need to do anything I think >>>>>> >>>>>> - Henry >>>>>> >>>>>> On Tue, Mar 6, 2012 at 1:03 PM, daviesd <davi...@oclc.org> wrote: >>>>>>> Ya it's the difference between insecure and secure. ?If I use insecure >>>>>>> tokens it works. ?If I switch to secure (our default) it gets this >>>>>>> exception >>>>>>> when encoding the token. >>>>>>> >>>>>>> doug >>>>>>> >>>>>>> >>>>>>> On 3/6/12 3:29 PM, "Henry Saputra" <henry.sapu...@gmail.com> wrote: >>>>>>> >>>>>>>> Hey Doug, >>>>>>>> >>>>>>>> Sorry about the trouble. >>>>>>>> >>>>>>>> How do you reproduce this? >>>>>>>> >>>>>>>> - Henry >>>>>>>> >>>>>>>> On Tue, Mar 6, 2012 at 12:13 PM, daviesd <davi...@oclc.org> wrote: >>>>>>>>> Henry, >>>>>>>>> >>>>>>>>> I¹m having issues with the fix for SHINDIG-1719. ? The stacktrace >>>>>>>>> looks >>>>>>>>> as >>>>>>>>> follows: >>>>>>>>> >>>>>>>>> Mar 6, 2012 3:04:20 PM >>>>>>>>> org.apache.shindig.gadgets.servlet.GadgetsHandlerService >>>>>>>>> createErrorResponse >>>>>>>>> WARNING: Error handling request: >>>>>>>>> java.lang.UnsupportedOperationException: Unsupported function: >>>>>>>>> getActiveUrl >>>>>>>>> ? ?at >>>>>>>>> >>>>> org.apache.shindig.protocol.conversion.BeanDelegator$DelegateInvocationHand >>>>> >> >>>>>>> >>>>> l >>>>>>>>> er.invoke(BeanDelegator.java:257) >>>>>>>>> ? ?at $Proxy90.getActiveUrl(Unknown Source) >>>>>>>>> ? ?at >>>>>>>>> >>>>> org.apache.shindig.auth.BlobCrypterSecurityToken.fromToken(BlobCrypterSecur >>>>> >> >>>>>>> >>>>> i >>>>>>>>> tyToken.java:74) >>>>>>>>> ? ?at >>>>>>>>> >>>>> org.apache.shindig.auth.BlobCrypterSecurityTokenCodec.encodeToken(BlobCrypt >>>>> >> >>>>>>> >>>>> e >>>>>>>>> rSecurityTokenCodec.java:171) >>>>>>>>> >>>>>>>>> Ideas? >>>>>>>>> >>>>>>>>> Doug >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > >
