java.lang.NoSuchMethodError when using an Addon

Hi there,

I’m right now trying to get the Addon “ContextMenu” to work with my maven vaadin project. After long and strenous trial and error and countless hours of googling I got my maven plugin to accept that the contextmenu addon was reachable online.

So after I added ContextMenu Version 4.2.1 to my project I thought I was finally set. But after implementing it and trying to start up the war it gives me a java.lang.NoSuchMethodError.

I did the following things:

private ContextMenu contextMenu;
private Table table = new Table();
//All kinds of other mumbo jumbo for the table

ContextMenuOpenedListener.TableListener tableOpenListener = new ContextMenuOpenedListener.TableListener() {
			public void onContextMenuOpenFromRow(ContextMenuOpenedOnTableRowEvent event) {
				// TODO Auto-generated method stub
			public void onContextMenuOpenFromHeader(
					ContextMenuOpenedOnTableHeaderEvent event) {
				// TODO Auto-generated method stub
			public void onContextMenuOpenFromFooter(
					ContextMenuOpenedOnTableFooterEvent event) {
				// TODO Auto-generated method stub
		contextMenu = new ContextMenu();

My compiler found the import alright, for both the ContextMenu and the ContextMenuOpenedListener. But as soon as my server tries to acces either


it crashes with


Problem accessing /. Reason:

    java.lang.NoSuchMethodError: org.vaadin.peter.contextmenu.ContextMenu.setAsTableContextMenu(Lcom/vaadin/ui/Table;)V

Caused by:

com.vaadin.server.ServiceException: java.lang.NoSuchMethodError: org.vaadin.peter.contextmenu.ContextMenu.setAsTableContextMenu(Lcom/vaadin/ui/Table;)V
	at com.vaadin.server.VaadinService.handleExceptionDuringRequest(
	at com.vaadin.server.VaadinService.handleRequest(
	at com.vaadin.server.VaadinServlet.service(
	at javax.servlet.http.HttpServlet.service(
	at org.eclipse.jetty.servlet.ServletHolder.handle(
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(
	at org.eclipse.jetty.servlet.ServletHandler.doScope(
	at org.eclipse.jetty.server.session.SessionHandler.doScope(
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
	at org.eclipse.jetty.server.Server.handle(
	at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(
	at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(
	at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(
	at org.eclipse.jetty.http.HttpParser.parseNext(
	at org.eclipse.jetty.http.HttpParser.parseAvailable(
	at org.eclipse.jetty.server.AsyncHttpConnection.handle(
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
	at org.eclipse.jetty.util.thread.QueuedThreadPool$

Any clues on how to fix this? If you need more information just tell me so, I’ll happily provide.

Is it possible that you might have two different versions of the add-on on your classpath? Or maybe you compile your application against one version and deploy with another.

I just looked into the classpath and it didn’t list any jars for the addon. Is that a problem? TBH I’m not that good with the whole java/linux setup so I may make newbie mistakes.

And I don’t know if the second question may be the case. I installed the jar on our local repositories (I think…) and added it with maven from our local repository. And maven accepted that just fine. I can’t get maven to communicate with the online vaadin repository, so I had to take this route. I had another thread for that problem:!/thread/3687644

Any ideas?

The add-on should be on the classpath of your application, and also on the classpath of the widgetset compiler (which also needs its sources on its classpath, but those should be in the same JAR).

If your classpath is missing the add-on, I would expect a ClassNotFoundException rather than a NoSuchMethodError, though. A NSME means that something has been compiled against a class that has the method but executed with a version of the same class that does not have the method.