No type for token

Showing 1-6 of 6 messages
No type for token oerten25 12/11/11 5:08 PM
When i try to use a proxy class which extends ValueProxy in an rf
request, i encounter UnexpectedException: No type for token
ecB9B47$c3vaX2Yv_$wIVBNodOw=  . The stack trace is as following :

SEVERE: Unexpected error
com.google.web.bindery.requestfactory.server.UnexpectedException: No
type for token ecB9B47$c3vaX2Yv_$wIVBNodOw=
        at
com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.die(ServiceLayerDecorator.java:
216)
        at
com.google.web.bindery.requestfactory.server.ResolverServiceLayer.resolveClass(ResolverServiceLayer.java:
59)
        at
com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.resolveClass(ServiceLayerDecorator.java:
136)
        at
com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.resolveClass(ServiceLayerDecorator.java:
136)
        at
com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.resolveClass(ServiceLayerDecorator.java:
136)
        at
com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.resolveClass(ServiceLayerDecorator.java:
136)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at
com.google.web.bindery.requestfactory.server.ServiceLayerCache.getOrCache(ServiceLayerCache.java:
233)
        at
com.google.web.bindery.requestfactory.server.ServiceLayerCache.resolveClass(ServiceLayerCache.java:
156)
        at com.google.web.bindery.requestfactory.server.RequestState
$1.getTypeFromToken(RequestState.java:77)
        at
com.google.web.bindery.requestfactory.shared.impl.IdFactory.getId(IdFactory.java:
159)
        at
com.google.web.bindery.requestfactory.server.RequestState.getBeansForPayload(RequestState.java:
143)
        at
com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.processOperationMessages(SimpleRequestProcessor.java:
501)
        at
com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:
210)
        at
com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:
127)
        at
com.google.web.bindery.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java:
133)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at
com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:
263)
        at
com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:
178)
        at
com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:
91)
        at
com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:
62)
        at
com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:
118)
        at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:
113)
        at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1088)
        at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:
360)
        at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:
216)
        at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:
181)
        at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:
729)
        at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:
405)
        at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:
152)
        at
org.mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java:
49)
        at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:
152)
        at org.mortbay.jetty.Server.handle(Server.java:324)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:
505)
        at org.mortbay.jetty.HttpConnection
$RequestHandler.content(HttpConnection.java:843)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:647)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
        at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
395)
        at org.mortbay.thread.QueuedThreadPool
$PoolThread.run(QueuedThreadPool.java:488)

Does anyone have an idea why this exception could occur?

Re: No type for token Marco Asteriti 2/18/12 11:54 AM
I have the same exact issue while expanding my test project to incorporate  simple @Embedded value type.

I have a simple Person entity with a few property fields (name, phone) I set up and got it to do all basic crud operations without any problems.  I added an Address POJO as an additional property field embedded in my person entity.  Everything works as expected up to and through firing of my RequestContext firing.  Here's the Code:

  PersonRequest req = requestFactory.personRequest();
  PersonProxy person = req.create(PersonProxy.class);
  AddressProxy address = req.create(AddressProxy.class);
  address.setStreet("Elm St.")
  person.setName("Joe");
  person.setAddress(address);
  req.save(person).fire();

Once it fires, I get the error above with the same stack as shown by the original post.  Apparently it doesn't like AddressProxy.class at all.  If I comment out the person.setAddress() line in my code, but leave AddressProxy address = req.create(AddressProxy.class) above it, I still get the same error.

Following it on the debugger the problem is here in the ResolverServiceLayer class:

    @Override
    public Class<? extends BaseProxy> resolveClass(String typeToken) {
      String deobfuscated = deobfuscator.getTypeFromToken(typeToken);
      if (deobfuscated == null) {
        die(null, "No type for token %s", typeToken);
      }

What am I missing??

Re: No type for token Brandon Donnelson 2/19/12 8:30 PM
I've had that too, but I can't remember what I did. 

Re: No type for token Marco Asteriti 2/20/12 5:59 AM
Thanks Brandon, I tied cleaning and GWT compile just in case (it did work for getting request factory validation to work, once) but it didn't have the desired effect.  My request context is very similar to the one you linked, the difference is I used only Request<T> for all my method invocations, not the InstanceRequest<T, T>. Here's the code bit:

@ServiceName(value = "com.masteriti.manager.server.access.PersonDao"
             locator = "com.masteriti.manager.server.locator.DaoServiceLocator")
public interface PersonRequest extends RequestContext {
Request<List<PersonProxy>> listAll();
Request<Void> save(PersonProxy person);
Request<PersonProxy> saveAndReturn(PersonProxy person);
Request<Void> delete(PersonProxy person);
}

The other thing I noticed looking around demo source code is that hardly anyone uses @Embedded objects in their entities.  Even the DynaTableRF source doesn't use the @Embedded notation as shown in Google's RequestFactory Tutorial, instead it simply has 

  private Address address = new Address();

I'll try that today and see if it works, but any other suggestions would be welcome!

Marco
Re: No type for token Thomas Broyer 2/20/12 6:29 AM
Several things:
  • InstanceRequest vs. Request doesn't matter
  • Your AddressProxy is obviously referenced from PersonProxy (I suppose you have a getter in addition to the setter?)
  • The DynaTableRf doesn't use JPA or JDO or whatever, it stores everything in-memory, so it doesn't need any annotation on the domain objects. http://code.google.com/p/listwidget/ (by David Chandler, Google Developer Advocate for GWT) uses EntityProxy and ValueProxy if you want some example with an @Embedded annotation (if that can reassure you), it's the @Embedded annotation from Objectify though, not JPA or JDO.
  • I suppose your AddressProxy is a ValueProxy?
  • Annotation processing in Eclipse a barely usable. I battled for hours yesterday to make it refresh the generated DeobfuscatorBuilder. IIRC, I refresh the project in eclipse, then restarted it, then disabled annotation processing, deleted the .apt_generated folder and re-enabled annotation processing. If you can use Maven for your project, then I'd bet it works much better there! (I had the issue on the gwt-user project itself, so it wasn't an option for me) Next time, I'll try setting up a build action (or whatever) to run "javac -proc:only" instead of relying of Eclipse's built-in (and awfully buggy) APT.
  • If it's not an issue with Eclipse's annotation processing but rather with GWT, try launching the ValidationTool (or javac) on your classes, it'll log issues with your classes that makes it exclude them from the generated DeobfuscationBuilder.
Re: No type for token Marco Asteriti 2/20/12 7:37 AM


On Monday, February 20, 2012 9:29:54 AM UTC-5, Thomas Broyer wrote:
Several things:
  • Annotation processing in Eclipse a barely usable. I battled for hours yesterday to make it refresh the generated DeobfuscatorBuilder. IIRC, I refresh the project in eclipse, then restarted it, then disabled annotation processing, deleted the .apt_generated folder and re-enabled annotation processing. If you can use Maven for your project, then I'd bet it works much better there! (I had the issue on the gwt-user project itself, so it wasn't an option for me) Next time, I'll try setting up a build action (or whatever) to run "javac -proc:only" instead of relying of Eclipse's built-in (and awfully buggy) APT.
Thanks for the reply, Thomas.  This item did the trick.  Following your procedure to refresh the project took care of the "No type for token..." error.  The code now runs without errors although its still not saving  addresses, but at least I'll have an opportunity to debug it in my code.  I've never used maven, and have been resistant to adding more new stuff on my plate, but I may have to at this point.  Thanks