vaadin-core | This package contains all free Vaadin web components | Web Framework library

I think the only real thing that is missing is the vaadin.version...

I got an answer from Vaadin Team. I did not add @PWA annotation.

Answer from Vaadin Team: There is possibly sw.js registered by a previous app you have used on the same computer. So probably unregistering service workers from browser settings will help, Browser registers service workers against the URL, so if you try out different apps locally, the registrations collide with localhost.

Solution: After adding the annotation, the exception disappeared.

Thank you, very much, Mr.Tatu for your help.

I have found the solution, I was missing the annotation @Component in the class where the method is, and the annotation @Autowired where I want the instance of the class to be created.

Apache Tomcat and Eclipse Jetty are two competing implementations of the Servlet, JavaServer Pages, and a very few other specifications defined in Java EE. But Java EE defines dozens more specs that are not implemented in these products. Both of these products are quite popular, as they deliver just enough of Java EE to meet the needs of many people.

So you cannot specify the full Java EE API in your POM. Tomcat lacks an implementation for most of that API.

For more details, see my Answer to the Question, Java EE Web Profile vs Java EE Full Platform. Look especially for my section, Servlet-oriented (Tomcat & Jetty).

You can indeed build Vaadin web apps using only Tomcat or Jetty. I have delivered such apps myself, running very well when deployed to Apache Tomcat. And some of the default POMs for Vaadin include a Maven action to run Jetty within your IDE. We use that in the Steps section below.

Looking at the URL in your first sentence, I see you started your project by downloading the Skeleton Starter for CDI. “CDI” is Contexts and Dependency Injection, one of the many Java EE specs not implemented by Tomcat. Thus the POM being set for full Java EE API.

➥ You can download a different Skeleton Starter without CDI, and without the full Java EE API.

You said:

new to all of this and struggling quite a bit so any help is really greatly appreciated! :)

Yes, tooling for web apps, web containers, Maven/Gradle, Vaadin, Java, Servlets, and IDEs is complicated, fussy, frustrating, and annoying. And even worse, all of that is constantly changing! All I can say is be persistent, be stubborn, and keep at it. And search Stack Overflow repeatedly — many issues and aspects have been covered here, some of it by me with my own trials and tribulations.

Here is an outline of steps, but not really an entire tutorial.

Be sure to check for tutorials on the Vaadin.com site, as well as on YouTube. In particular, Marcus Hellberg has been posting good tutorials lately. Also, if you really get stuck, the Vaadin Ltd company sells consulting and training services.

If you have a Mac with Apple Silicon (M1 chip) rather than Intel, be sure you have Rosetta 2 installed. Installing an Intel-only app such as Unicode Checker will prompt the installation. The issue here is that Vaadin employs some JavaScript tools (Node.js & npm) that are still Intel-only, even now, a year later, in late 2021.

On the Start page at Vaadin.com, click the link further down for downloading a plain Java starter. On the next page, look for that Vaadin 14 - plain Java block. Notice that we do not want the Vaadin 14 - Spring Boot block, nor the Vaadin 14 - CDI block.

The link in that block downloads skeleton-starter-flow-14 folder. You may change the name, and relocate that folder to the usual place for your IDE projects.

Open that downloaded folder in your IDE. Wait a moment as Maven does its thing, unpacking, downloading, etc. In the mean time, read the README.md page.

After Maven quiets, build the project as-is. You IDE likely has a way to invoke Maven in its GUI. IntelliJ for example has a Maven tool pane. There we should run clean, then install.

If you get an error "No valid Maven installation found.", see this Question, and this Answer instructing you to switch "Maven wrapper" setting to "Bundled Maven". Yes, this is one of the many stupid speed bumps in all this tooling.

If you get an error "Cannot access defaults field of Properties", see this Question with this Answer, leading to this Maven documentation page telling you what to add to your POM. Yes, another of the many stupid speed bumps in tooling. Make Maven reprocess the POM — in IntelliJ this means clicking the tiny floating little windoid with a tiny Maven logo.

When you get your clean & install to run successfully, then you are ready to run the web app. In IntelliJ, I go to that Maven tool pane, then navigate to Project base for Vaadin > Plugins > jetty > jetty:run. Wait a few minutes, especially the first time as more items may need to be downloaded, and various tools utilized by Vaadin must run.

Eventually you will see a message on the console stating "Started Jetty Server". This means you can switch to your web browser, and point to http://localhost:8080/. There you should see the sample app, prompting for your name, with a "Say hello" button. Try that field and button, to make sure it all works.

Now go back to the IDE. Stop the Jetty web container. In IntelliJ, I click the red square icon in upper right corner of the overall window.

Update: Java 16 is now at end-of-life. I recommend you move to Java 17, the current Long-Term Support (LTS) version.

You want to use Java 16, so we need to go back to our POM again. Replace these two lines:

Are you only running mvn azure-webapp:deploy?

Make sure you run mvn package first, or mvn package azure-webapp:deploy. Otherwise it will just re-deploy the same WAR file. Include the -Pproduction flag if you want to run it in production mode.

Edit:

I set up a project myself and could reproduce your issue. After running mvn azure-webapp:config again twice and updating both Application and Runtime, it seems to work.

This did two changes to the pom.xml, try these out:

1. Add war under in the azure-webapp-maven-plugin.
2. Change jre8 to TOMCAT 9.0.

Having the same class name in multiple locations on your classpath is a bad idea.

This is the most common form of unstable operation on Java there is!

The classloaders in Java have no guarantee of load order behavior if the same class is present in multiple locations within the classloader.

In one run you might accidentally load the classes in the order you intend, and have it run properly, then at a future date you run the same program and the load order is different, now you are running with a different class version and you have unexpected behavior.

The only way to fix this is to clean up your classloader and ensure that you only have 1 version of the class you intend to use.

This is what Jetty is telling you.

As for this specific one, javax.websocket-api and javax.websocket-client-api, you want to exclude javax.websocket-client-api at the gradle level, as all of the websocket client classes are also present in the javax.websocket-api.

The javax.websocket-client-api jar is only intended for projects that only use the javax.websocket Client, without a javax.websocket Server.

Following the suggestion of joakim-erdfelt I have modified my gradle.build and this prevent the problem:

As is explained in a tutorial, you need to have an actual implementation class of a Jakarta Bean Validator available. In the linked tutorial there are a list of available dependencies shown that you can use, depending on your environment. I recommend reading the whole tutorial anyway.

So if you have a Java EE environment, add this to your pom:

You also need the heroku/nodejs buildpack, it will install node for you. You can add the buildpack either in your apps dashboard or by running heroku buildpacks:add heroku/nodejs -a your-app-name.