New Grid component throwing ConversionException

I am trying out the new Grid component in my Application, replacing the Table component. So far it is quite easy to migrate (great job!). However, when using the Grid component with an existing (and working custom Indexed Container) i get:$ConversionException: Unable to convert value of type java.lang.Integer to presentation type java.lang.String. No converter is set and the types are not compatible. This is just a “normal” integer column for which a default Converter is present in Vaadin. Is this a know problem? Or is this intended? So what is the best approach?

Hi Ronald,

Could you copypaste the whole stack trace, including any “cause” exceptions? Plus a test case would be nice if you can reduce your application into one. An integer column should “just work” so this is either a bug or perhaps some issue in your code.

Stacktrace is:

12:12:06.030 |ERROR| Unable to convert value of type java.lang.Integer to presentation type java.lang.String. No converter is set and the types are not compatible. | >>>>>>$ConversionException: Unable to convert value of type java.lang.Integer to presentation type java.lang.String. No converter is set and the types are not compatible.$900($2.requestRows( sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke( sun.reflect.DelegatingMethodAccessorImpl.invoke( java.lang.reflect.Method.invoke( com.vaadin.server.ServerRpcManager.applyInvocation( com.vaadin.server.ServerRpcManager.applyInvocation( com.vaadin.server.communication.ServerRpcHandler.handleInvocations( com.vaadin.server.communication.ServerRpcHandler.handleRpc( com.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest( com.vaadin.server.SynchronizedRequestHandler.handleRequest( com.vaadin.server.VaadinService.handleRequest( com.vaadin.server.VaadinServlet.service( javax.servlet.http.HttpServlet.service( org.eclipse.jetty.servlet.ServletHolder.handle( org.eclipse.jetty.servlet.ServletHandler.doHandle( org.eclipse.jetty.server.handler.ScopedHandler.handle( org.eclipse.jetty.server.session.SessionHandler.doHandle( org.eclipse.jetty.server.handler.ContextHandler.doHandle( org.eclipse.jetty.servlet.ServletHandler.doScope( org.eclipse.jetty.server.session.SessionHandler.doScope( org.eclipse.jetty.server.handler.ContextHandler.doScope( org.eclipse.jetty.server.handler.ScopedHandler.handle( org.eclipse.jetty.server.handler.ContextHandlerCollection.handle( org.eclipse.jetty.server.handler.HandlerCollection.handle( org.eclipse.jetty.server.handler.HandlerWrapper.handle( org.eclipse.jetty.server.Server.handle( org.eclipse.jetty.server.HttpChannel.handle( org.eclipse.jetty.server.HttpConnection.onFillable($ org.eclipse.jetty.util.thread.QueuedThreadPool.runJob( org.eclipse.jetty.util.thread.QueuedThreadPool$ Creating a test case wil take some more time … :slight_smile: I do not know if that is feasable, because the code is quite large. Howver it worked with a Table component and will come back with some details.

Hmm, strange.

It seems that exception should only occur if the converter for that column is explicitly set to null - otherwise, when the column is created, it should find a suitable converter from the column type to String. And indeed, in our test case it does find StringToIntegerConverter without problems.

I found it (i assume). We use a property type “Object” for a column (table shows key/value pairs where the key title is always a String and the value type differs from row to row), so Property#getType() returns Object.class. However the actual type in the reported case is an Integer. This use case is handled by the Table component, but not by the Grid component, which is more strict.

Ah, all right! I knew this sounded familiar but couldn’t find the ticket. This is stricter than Table semi-by-design; I think Table just falls back to Object.toString if there’s no converter set. However, the exception message is indeed not very helpful, and there’s a recent ticket about adding a
for this use case. Or we could maybe add a toString fallback to Grid too; in fact, the client-side Grid already has one.

Thanks for your fast and very helpful comments!

IMHO Vaadin should strive for making the behaviour as similar as possible. For many users the Grid will be used as a more flexible, powerful and performant drop-in replacement for the Table component.
In this case i would suggest for the same fallback scenario as Table uses.