This topic tells you what to do when you encounter issues with VMware Tanzu Developer Tools for Visual Studio Code (VS Code).
{{> 'partials/ide-extensions/ki-cannot-view-workloads' }}
After live-update has synchronized changes you made locally to the running workload, the workload pods start failing with an error message similar to the following:
Caused by: org.springframework.beans.factory.CannotLoadBeanClassException: Error loading class
[com.example.springboot.HelloController] for bean with name 'helloController' defined in file
[/workspace/BOOT-INF/classes/com/example/springboot/HelloController.class]: problem with class file
or dependent class; nested exception is
java.lang.UnsupportedClassVersionError: com/example/springboot/HelloController has been compiled by
a more recent version of the Java Runtime (class file version 61.0), this version of the
Java Runtime only recognizes class file versions up to 55.0
The classes produced locally on your machine are compiled to target a later Java virtual machine (JVM).
The error message mentions class file version 61.0
, which corresponds to Java 17.
The buildpack, however, is set up to run the application with an earlier JVM.
The error message mentions class file versions up to 55.0
, which corresponds to Java 11.
The root cause of this is a misconfiguration of the Java compiler that VS Code uses. The cause might be a suspected issue with the VS Code Java tooling, which sometimes fails to properly configure the compiler source and target compatibility-level from information in the Maven POM.
For example, in the tanzu-java-web-app
sample application the POM contains the following:
<properties>
<java.version>11</java.version>
...
</properties>
This correctly specifies that the app must be compiled for Java 11 compatibility. However, the VS Code Java tooling sometimes fails to take this information into account.
Force the VS Code Java tooling to re-read and synchronize information from the POM:
- Right-click the
pom.xml
file. - Click Reload Projects.
This causes the internal compiler level to be set correctly based on the information from pom.xml
.
For example, Java 11 in tanzu-java-web-app
.
{{> 'partials/ide-extensions/ki-timeout-err-live-updating' }}
When you attempt to run a Tanzu Debug launch configuration, you see a task-related error message similar to the following:
Could not find the task 'tanzuManagement: Kill Port Forward my-app
The task you're trying to run is no longer supported.
Delete the launch configuration from your launch.json
file in your .vscode
directory.
{{> 'partials/ide-extensions/ki-tnz-panel-actions-unavail' }}
{{> 'partials/ide-extensions/ki-projects-with-spaces' }}
You cannot apply a workload. You see an error message when you attempt to do so.
Your kubeconfig file (~/.kube/config
) is malformed.
Fix your kubeconfig file.
Live Update deploys your workload but changes are not visible when using development containers on Windows.
Monitoring file system changes on Windows directories, while mounted in a Docker container, is very slow and might not work in your specific setup.
-
Clone the repository inside of a container volume instead of mounting a local directory in the container. This improves I/O performance.
-
Run the
Dev Containers: Clone Repository in Container Volume...
command while the project is open to get started. For more information about this command, see the Visual Studio Code documentation.
When using a development container, and creating a new project using the Application Accelerator extension in VS Code, the only available location to store the project is inside the development container.
VS Code is running inside a development container. Therefore the development container file system is the file system made available when creating a new project.
Use local file mounts to expose additional directories in the host file system to the development container. For more information, see Use Mounts.
When an application is applied from VS Code it restarts frequently.
An application or environment behavior is triggering the application to restart.
Observed trigger behaviors include:
- The application itself writing logs to the file system in the application directory that Live Update is watching
- Autosave being set to a very high frequency in the IDE configuration
Prevent the trigger behavior. Example solutions include:
- Prevent 12-factor applications from writing to the file system.
- Reduce the autosave frequency to once every few minutes.