Metaclass not found


I came across this strange error. I think I had a similar one a couple months back, and got solved by clearing and redeploying. However this one is more perseverant.

Here the stacktrace to hint out a possible solution. A remarkable feature of my project is that I update sources from a git repo, to enable code migration in a dev and a uat machine. Recently I added the REST API Plugin in the dev machine, committed changes and updated in the UAT machine. Can that be an issue?

The error appears so far only upon opening one editor screen in the application, among roughly 70 or 80 pages. So it seems to be something very particular and elusive.

Any hints are greatly appreciated.

Regards and happy new year.


java.lang.IllegalArgumentException: MetaClass not found for test1_ReciboIndividualizado
at com.haulmont.cuba.core.sys.CachingMetadataSession.getClassNN(
at com.haulmont.cuba.core.sys.MetadataImpl.create(
at com.haulmont.cuba.gui.config.MenuItemCommands$ScreenCommand.getEntityToEdit(
at com.haulmont.cuba.gui.config.MenuItemCommands$
at com.haulmont.cuba.web.sys.MenuBuilder$MenuCommandExecutor.accept(
at com.haulmont.cuba.web.sys.MenuBuilder$MenuCommandExecutor.accept(
at com.haulmont.cuba.web.gui.components.mainwindow.WebAppMenu$MenuItemImpl.menuSelected(
at com.vaadin.ui.MenuBar.changeVariables(
at com.vaadin.server.communication.ServerRpcHandler.changeVariables(
at com.vaadin.server.communication.ServerRpcHandler.handleInvocation(
at com.vaadin.server.communication.ServerRpcHandler.handleInvocations(
at com.vaadin.server.communication.ServerRpcHandler.handleRpc(
at com.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(
at com.vaadin.server.SynchronizedRequestHandler.handleRequest(
at com.vaadin.server.VaadinService.handleRequest(
at com.vaadin.server.VaadinServlet.service(
at com.haulmont.cuba.web.sys.CubaApplicationServlet.serviceAppRequest(
at com.haulmont.cuba.web.sys.CubaApplicationServlet.service(
at javax.servlet.http.HttpServlet.service(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.tomcat.websocket.server.WsFilter.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFilter(
at org.springframework.web.filter.CompositeFilter.doFilter(
at com.haulmont.cuba.web.sys.CubaHttpFilter.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.StandardWrapperValve.invoke(
at org.apache.catalina.core.StandardContextValve.invoke(
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.valves.ErrorReportValve.invoke(
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(
at org.apache.catalina.core.StandardEngineValve.invoke(
at org.apache.catalina.connector.CoyoteAdapter.service(
at org.apache.coyote.http11.Http11Processor.service(
at org.apache.coyote.AbstractProcessorLight.process(
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
at java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.util.concurrent.ThreadPoolExecutor$
at org.apache.tomcat.util.threads.TaskThread$


I have discovered that the issue has its root cause at: line 358

The error occurs because I launch an editor FROM THE MENUBAR (not from a browse table) which is not the main entity editor. Say we have entity A, so I would have the standard A.edit. But this editor is an extension of the main one because the entity A is constructed in a very different manner in this extended editor, named let’s say A2.edit.

I have been able to use it for a long time and all of a sudden it stopped working.

The error in that line occurs, because when the getEntityToEdit() method in the mentioned class is called, if there’s no entity passed as parameter, it solely checks the screenId and splits the string to extract the metaClassName, hence not being found since the screenId is A2.edit, and A2 doesn’t correspond to any metaClassName.

Can I workaround that? How can I set the entity instance being edited in the ScreenCommand parameter or anywhere else to avoid the piece of code that concludes that the metaClassName derives from the screenId.

I see it as an important design mistake, then you must be able to approach the edition of an entity in many different ways.



Finally solved it by creating a web bean and launching the screen via screenBuilders according to the solution proposed in this link

Thanks and hope this might help someone.



1 Like