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$DelegateInvocationHandl >>> er.invoke(BeanDelegator.java:257) >>> ? ?at $Proxy90.getActiveUrl(Unknown Source) >>> ? ?at >>> org.apache.shindig.auth.BlobCrypterSecurityToken.fromToken(BlobCrypterSecuri >>> tyToken.java:74) >>> ? ?at >>> org.apache.shindig.auth.BlobCrypterSecurityTokenCodec.encodeToken(BlobCrypte >>> rSecurityTokenCodec.java:171) >>> >>> Ideas? >>> >>> Doug >> > >
