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 >>> >> >> >
