ClassNotFound after migration to Vaadin 8

I used the migration tool and everything seem fine. Everything compiled but I’m having runtime exception about the old classes. In my case is Tree.

I’m using:

<dependency> <groupId>com.vaadin</groupId> <artifactId>vaadin-compatibility-server</artifactId> <version>8.0.0</version> </dependency> Same with vaadin-client-compiled, vaadin-client, vaadin-push and vaadin-themes.

Code can be found
here
.

Here’s the stack trace:

SEVERE:
java.lang.NoClassDefFoundError: com/vaadin/ui/Table
    at net.sourceforge.javydreamercsw.validation.manager.web.ValidationManagerUI.buildProjectTree(ValidationManagerUI.java:688)
    at net.sourceforge.javydreamercsw.validation.manager.web.ValidationManagerUI.updateProjectList(ValidationManagerUI.java:1051)
    at net.sourceforge.javydreamercsw.validation.manager.web.ValidationManagerUI.init(ValidationManagerUI.java:1032)
    at com.vaadin.ui.UI.doInit(UI.java:738)
    at com.vaadin.server.communication.UIInitHandler.getBrowserDetailsUI(UIInitHandler.java:214)
    at com.vaadin.server.communication.UIInitHandler.synchronizedHandleRequest(UIInitHandler.java:74)
    at com.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:41)
    at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1464)
    at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:380)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:217)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
    at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:673)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: com.vaadin.ui.Table
    at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1333)
    at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1167)
    ... 34 more

The exception complaints about the missing table-component, which really isn`t there anymore but might be found under com.vaadin.v7.ui.table. Welcome to the growing crowd of people migrating to grid sometime in the future.

What does an IVY file look like that allows for V7 classes? We changed ivy.xml from

<!DOCTYPE ivy-module [

]>

to

<!DOCTYPE ivy-module [

]>

But this appears insufficient as the V7 classes are not there even with the new com.vaadin.v7… imports.

Also, my ivy has this line, but I don’t know if needs to be changed to v8proj or not:

<info organisation="org.vaadin.openesignforms" module="v7proj" />

Sorry, but we don’t otherwise use Ivy and thus are not sure. Or do we need to create all new V8 projects using the Eclipse plugin and then migrate the code into it? Or can we just take our existing V7 code and update IVY to get going with Vaadin 8?


https://vaadin.com/vaadin-fw8-documentation-portlet/framework/migration/migrating-to-vaadin8.html

Well, I confess that’s just hard enough that I hope Vaadin keeps V7 going indefinitely. Even with those instructions, I couldn’t get my addon to compile again, so at this point, I’ll be skipping V8 as the time commitment to migrate first in a “compatible” way and then adjust libraries as code is converted (rather than understanding that old V7 code will likely remain V7 code forever unless there’s a reason for the developer to rewrite it for V8 to get a real benefit). I am worried that V8 could be the beginning of the end for us who started under V6. New stuff is great, but when it makes all of the existing code developed over many years an issue, it’s clearly going to be massive trouble.

I’m absolutely with you there. I converted my Vaadin 7 / Viritin table-using toy-project to pure Vaadin 8 last weekend and had to jump through quite a lot of loops. (Rendering a Link in a Grid? Who would think of such a nasty thing?) I won’t even consider introducing version 8 at work before 8.1 is released. The new data-binding is great though.

I just wish they had kept their existing APIs and added to them to define the new capabilities rather than replacing them (they do work after all). I’d be happy to create new forms and the like using the new schemes and data models, like we did when we upgraded from V6 to V7 for FieldGroup, which also subjected us to a substantial rewrite effort and yet we still have a large number of old style Forms. But it’s surprisingly confusing just trying to get a project to rebuild using V8 even with the compatibility library.

New features are great. I’m happy they are on Java 8 and I’m happy there may be new data binding that’s even easier to use. But they will have no value if my large Vaadin6/7 project and ckeditor add-on are too hard to convert when I should just be recompiling and making use of the new stuff as I saw fit.

Ok, I have an Eclipse project built originally for V6, now under V8. I created a branch to work on V8 with V7-compatibility, but I don’t get anywhere easily.

I have ensured my project is using Java 8 instead of Java 6 as it was before.

I then updated my ivy.xml to look like this (my attempt to change the vaadin.version from 7.7.6 to 8.0.2. Because another error, I also tried changing the info module rom v7proj to v8proj. For the dependencies, I duplicated each row and referenced the compatibility name, with the end result being:

<?xml version="1.0"?>
<!DOCTYPE ivy-module [
    <!ENTITY vaadin.version "8.0.2">
]>
<ivy-module version="2.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd">
    <info organisation="org.vaadin.openesignforms" module="v8proj" />
    <configurations>
        <!-- The default configuration, which should be deployed to the server -->
        <conf name="default" />
        <!-- A configuration only needed when compiling the widget set. Should 
            not be deployed to the server -->
        <conf name="widgetset-compile" />
    </configurations>
    <dependencies defaultconf="default" defaultconfmapping="default->default">
        <!-- The core server part of Vaadin -->
        <dependency org="com.vaadin" name="vaadin-server" rev="&vaadin.version;" />
        <dependency org="com.vaadin" name="vaadin-compatibility-server" rev="&vaadin.version;" />

        <!-- Vaadin themes -->
        <dependency org="com.vaadin" name="vaadin-themes" rev="&vaadin.version;" />
        <dependency org="com.vaadin" name="vaadin-compatibility-themes" rev="&vaadin.version;" />

        <!-- Precompiled DefaultWidgetSet -->
        <dependency org="com.vaadin" name="vaadin-client-compiled"
            rev="&vaadin.version;" />
        <dependency org="com.vaadin" name="vaadin-compatibility-client-compiled"
            rev="&vaadin.version;" />

        <!-- Vaadin client side, needed for widget set compilation -->
        <dependency org="com.vaadin" name="vaadin-client" rev="&vaadin.version;"
             conf="widgetset-compile->default" />
       <dependency org="com.vaadin" name="vaadin-compatibility-client" rev="&vaadin.version;"
             conf="widgetset-compile->default" />

        <!-- Compiler for custom widget sets. Should not be deployed -->
        <dependency org="com.vaadin" name="vaadin-client-compiler"
            rev="&vaadin.version;" conf="widgetset-compile->default" />
        <dependency org="com.vaadin" name="vaadin-compatibility-client-compiler"
            rev="&vaadin.version;" conf="widgetset-compile->default" />
    </dependencies>
</ivy-module>

I also updated my VaadinCKEditorWidgetset.gwt.xml file to chagne the inherits from com.vaadin.DefaultWidgetSet to com.vaadin.v7.Vaadin7WidgetSet so it looks like this (our widget extends AbstractField and implements LegacyComponent):

[code]

<?xml version="1.0" encoding="UTF-8"?>
<!-- <script src='ckeditor/ckeditor.js' /> -->

<replace-with class="org.vaadin.openesignforms.ckeditor.widgetset.client.ui.ModalFixVWindow">
    <when-type-is class="com.vaadin.client.ui.VWindow"/>
</replace-with>

<inherits name="com.vaadin.v7.Vaadin7WidgetSet" />
[/code]But when I do an IVY resolve, I get this IVYDE resolve has encountered a problem:

Some projects fail to be resolved
Impossible to resolve dependencies of org.vaadin.openesignforms#v8proj;working@David-MBP-2015
unresolved dependency: com.vaadin#vaadin-compatibility-client-compiler;8.0.2: not found
unresolved dependency: org.ow2.asm#asm;working@David-MBP-2015: not found
unresolved dependency: org.ow2.asm#asm-commons;working@David-MBP-2015: not found
unresolved dependency: org.ow2.asm#asm-util;working@David-MBP-2015: not found

Do we need to use a special version of Eclipse? I am using Eclipse Luna and “Check for Updates” indicated no new Vaadin plugin was found (“No updates were found”), which seemed a bit odd.

Hi David,

I have a V8 project working with IVY. By “working” I mean I’m in the midst of a multi-hundred hour exercise with everything now converted but about 60 Grids. Trial and error resulted in an IVY file with:

  1. vaadin-compatibility-server, but not vaadin-server
  2. vaadin-compatibility-themes AND vaadin-themes
  3. vaadin-compatibility-client-compiled, but not vaadin-client-compiled
  4. vaadin-compatibility-client AND vaadin-compatibility-shared, but not vaadin-client
  5. vaadin-client-compiler

… and a bunch of addons and other dependencies. That’s a little different than yours and I have no idea if it’s optimum.

Apart from compiling themes and widgetsets I don’t do any client side work. Here’s the corresponding parts of my ivy.xml file. Configurations came from an old post from Marko Grönoos if I remember correctly.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE ivy-module [
    <!ENTITY vaadin.version "8.0.2">
    
    <!-- This is normally 'default' but 'build' for locally built Vaadin core. -->
    <!ENTITY defaultconf "default">
]>
<ivy-module version="2.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd">
    
    <info organisation="com.vaadin" module="v8proj" />
        
    <configurations>
        <!-- The default configuration, which should be deployed to the server -->
        <conf name="default" />
        
        <!-- A configuration only needed when compiling the widget set. Should 
            not be deployed to the server -->
        <conf name="widgetset-compile" />
        
        <!-- A configuration used in compilation of server side classes only.
            Should be deployed to the server -->
        <conf name="nodeploy" />
    </configurations>
    
    <dependencies defaultconf="default" defaultconfmapping="default->default">
        <!-- The core server part of Vaadin -->
       <dependency org="com.vaadin" name="vaadin-compatibility-server"
                   rev="&vaadin.version;" changing="true" conf="nodeploy,default->default"/>
       <dependency org="com.vaadin" name="vaadin-compatibility-themes"
                   rev="&vaadin.version;" conf="nodeploy,default,widgetset-compile->default"/>
       <dependency org="com.vaadin" name="vaadin-themes"
                   rev="&vaadin.version;" conf="nodeploy,default,widgetset-compile->default"/>
        <!-- Push support (I wonder if this is still needed?-->
       <dependency org="com.vaadin" name="vaadin-push"
                   rev="&vaadin.version;">
           <exclude org="org.slf4j" name="slf4j-api"/>
       </dependency>
        <!-- Precompiled DefaultWidgetSet -->
        <dependency org="com.vaadin" name="vaadin-compatibility-client-compiled"
            rev="&vaadin.version;" />
        <!-- Vaadin client side, needed for widget set compilation -->
       <dependency org="com.vaadin" name="vaadin-compatibility-client"
                 rev="&vaadin.version;"/>
       <dependency org="com.vaadin" name="vaadin-compatibility-shared"
                 rev="&vaadin.version;"/>
        <!-- Compiler for custom widget sets. Should not be deployed -->
        <dependency org="com.vaadin" name="vaadin-client-compiler"
            rev="&vaadin.version;" conf="widgetset-compile->default" />

// ...

Thanks. Somehow that managed to reduce on of the IVY resolve errors for “unresolved dependency: com.vaadin#vaadin-compatibility-client-compiler;8.0.2: not found”, but that may make sense I guess I tried to over-compatibility the ivy.xml with that vaadin-client-compiler entry.

I now just shows:

Some projects fail to be resolved
Impossible to resolve dependencies of org.vaadin.openesignforms#v8proj;working@David-MBP-2015
unresolved dependency: org.ow2.asm#asm;working@David-MBP-2015: not found
unresolved dependency: org.ow2.asm#asm-commons;working@David-MBP-2015: not found
unresolved dependency: org.ow2.asm#asm-util;working@David-MBP-2015: not found

I get a bit more info, but make so little progress that I’ll have to put this on the back burner until there’s some more clarity on what’s needed. I have no idea what “org.ow2.asm” is nor do I see it referenced anywhere.

Perhaps you should go to http://asm.ow2.org/ and see if you remember using it. Maybe you have some jar in your classpath that is trying to refer to it? It looks like you’re close.

Thanks, Steve, but I’m sure it’s not from any code we have. We don’t use IVY for anything in our code besides for Vaadin, and the only change we’ve made is trying to update the ivy.xml for V8 compatibility mode.

Hi - I’ve hit exactly the same issue and also have to put compatibility on hold. We don’t use asm for anything explictly in our code. Running an ivyReport when using 7.7.6 shows org.ow2.asm is not being used anywhere, it’s only trying to pull it in when I try to use the v8 compatibility jars.

Impossible to resolve dependencies of com.futrix#maverick;working@FUTRIXLT020
unresolved dependency: org.ow2.asm#asm;working@FUTRIXLT020: not found
unresolved dependency: org.ow2.asm#asm-util;working@FUTRIXLT020: not found
unresolved dependency: org.ow2.asm#asm-commons;working@FUTRIXLT020: not found

Does anyone have any idea what the solution to this is?

I found the solution (after a few hours!) - in my ivy cache directory the cache for com.google.gwt\gwt-dev in ivy-2.8.0.xml there were some enties like

    <dependency org="org.ow2.asm" name="asm" rev="working@FUTRIXLT020" force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
    <dependency org="org.ow2.asm" name="asm-util" rev="working@FUTRIXLT020" force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
    <dependency org="org.ow2.asm" name="asm-commons" rev="working@FUTRIXLT020" force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>

Which caused it to try and pull those in - I’ve no idea how they got there in the first place. I removed the com.google.gwt directory completely from my cache directory and did another ivyResolve and all is ok now.

Thanks for the discovery, Ray.

Did you find you were able to remove that without any issues? I mean, we still need to build under Vaadin 7.7 as well as looking to migrate to Vaadin 8, so we don’t want to break IVY for our current production system under 7.7.

After that it worked fine for me - we have the same situation (prod under 7.7 current dev migrating to 8). I’m not sure what caused it in the first place, some quirk with ivy I guess.

I doubt this is the root cause as I have the same issue in Maven.