I'm trying to get restart working with Spring Boot DevTools. I have been following the instructions provided here: https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-devtools.html
I am using gradle and included this in my build.gradle file:
bootJar {
excludeDevtools = false
}
I create the jar file and run the jar file:
java -jar app.jar
I am able to connect to the running application through Intellij. When I make a change I can see in the Intellij console that the updated classes are uploaded to the running process. And in the logs of the running process, I see the process attempts to restart. However, the process quits and spits out this log:
org.springframework.beans.factory.BeanDefinitionStoreException: Failed to parse configuration class [com.example.BootApplication]; nested exception is java.io.FileNotFoundException: class path resource [com/example/ExampleService.class] cannot be opened because it does not exist.
ExampleService is the class I modified.
I attempted to google the heck out of this, but could find nothing. I looked at many tutorials online, but could find nothing.
Has anyone encountered this or has anything I can try, would be much appreciated.
The issue is based on how compilation of a file works.
When you compile a file, it first deletes the already compiled file and then adds a new one. During this process, file system watcher consider it as two different updates (deletion of file and addition of a new file) if the poll time is too low. And deletion of file triggers deletion of file from the remote application and tries to restart the application without the file you changed and therefore, you get this error.
I was facing the similar problem but solved it by adding following in application.properties
spring.devtools.restart.pollInterval=10s
You can change the pollInterval that suits you
Related
I am new at Docker and trying to build and run my own container with Spring Boot Application. It runs on Kotlin and Gradle.
I have built the image with simply this command, provided by gradle with spring boot plugin (id("org.springframework.boot") version "2.7.0-SNAPSHOT")
gradlew bootBuildImage
As a result i am getting this. Here are the logs: https://pastebin.com/xMW82vcw
The problem is, while trying to run my built image i am getting this error.
C:\projects\monetka-app>docker run docker.io/library/monetka-app:0.0.1-SNAPSHOT
Setting Active Processor Count to 6
unable to determine class count
unable to walk /workspace
unable to open ZIP /workspace/META-INF/licenses/client-2.1.jar
read /workspace/META-INF/licenses/client-2.1.jar: is a directory
ERROR: failed to launch: exec.d: failed to execute exec.d file at path '/layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/memory-calculator': exit status 1
Here are the docker images i have locally
in docker desktop.
My gradle version is 7.4.1, and JDK in use is 17.
When you run gradlew bootBuildImage, you're using Cloud-Native buildpacks to generate the image. This is a bug in a tool installed by the buildpack.
The Java Cloud-Native buildpack will install a tool called memory-calculator. This tool runs prior to your application starting up and sets up all the JVM memory flags that are required to keep the JVM from going past the defined memory limit you set. For example, if you set the memory limit of your container to be 1G, the memory calculator will adjust settings like -Xmx accordingly.
To do this, the memory calculator needs to know how many class files you have in your application, so it searches for them. This process is failing because it sees something with an extension of .jar and so it's trying to read the number of class files in that JAR, however, what it's seeing META-INF/licenses/client-2.1.jar isn't actually a JAR. It's a directory.
I opened a bug report for you here: https://github.com/paketo-buildpacks/libjvm/issues/160
If you are able to remove the file META-INF/licenses/client-2.1.jar (or change so it doesn't have a .jar extension) you should be able to work around this until we can resolve the issue.
I am using IntelliJ Idea 2017.3 and on any Gradle project (even for simple 'hello world' from GitHub) I always got next error:
"Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at https://docs.gradle.org/3.5-rc-2/userguide/gradle_daemon.html
Please read the following process output to find out more:
-----------------------
Error: Could not find or load main class 1.8"
Meanwhile, if I run an application with Gradle wrapper (gradlew.bat in my case) everything works perfectly. For me it looks like misconfiguration issue, but I cannot find what I am doing wrongly in Idea configuration or any other place. I appreciate any help with it or clue where to dig.
The issue was resolved and I would like to share this knowledge with all those who encounter a similar problem.
In my case, I had to delete two configuration files gradle.experimental.xml and gradle.settings.xml from IDEA configuration directory %IDEA_HOME%\config\options. I suppose they were created at the time when I installed Gradle globally on my PC. Somehow these settings were persisted, even after I removed globally installed Gradle and started to use Gradle's wrapper.
I try to migrate an eclipse plugin from Java8 to Java9. If I start a debug session (Run as Eclipse Application...) all works fine.
However, after installing my plugin I am not able to use it. If I use ss in the OSGI console I get following status for my plugin:
1102 STARTING org.treez.core_1.0.0.201712191435
and if I manually try to start it I get
osgi> start 1102
gogo: BundleException: Error loading bundle activator.
I tried to start a remote debug session, as suggested here:
Debugging Eclipse plug-ins
I set a break point in the constructor of my Activator but that break point is never reached.
=> How can I get additional information about why the loading of the bundle activator fails? Is there some log file? Can I somewhere set a logging level to TRACE?
I assume that the issue might be that a resource can be found while debugging the Eclipse Application but not when using the bundled jar. More info, e.g. the name of the resource that could not be found, would be very helpful.
Related questions:
Debugging Eclipse plug-ins
CQ5 OSGi bundle does not start:- Activator cannot be found
When plugins fail to start there is normally a message in the .log file in the workspace .metadata directory.
On Linux, Unix and macOS this file and directory are hidden so you may need to do something special to see them.
I'm working on a springboot 1.5.1 application that I'm trying to load a WSDL included in my resources directory in the wsdl directory. Depending on where my application executes I'm getting different results (command line, intellij, cloud foundry) and I can't seem to get all three to work at the same time.
I've tried several ways of locating the resource:
From prior to the migration to springboot we had this (worked in IntelliJ but not java -jar myboot.jar):
this.getClass().getResource("/wsdl/my.wsdl");
I switched it to the typically more correct version and got it to work in IntelliJ and java -jar but not Cloud Foundry:
this.getClass().getClassLoader().getResource("/wsdl/my.wsdl");
I switched it to use the Spring Resource Loader version and it worked in IntelliJ and CloudFoundry but not java -jar:
#Value("classpath:/wsdl/my.wsdl")
private Resource wsdlResource;
wsdlResource.getURL();
On the command line what I've noticed is that it seems to be thinking that BOOT-INF/classes is a JAR file (Note the ! after classes):
Caused by: javax.xml.ws.WebServiceException: Failed to access the WSDL at: jar:file:/C:/dev/redacted/build/libs/redacted.jar!/BOOT-INF/classes!/wsdl/my.wsdl. It failed with:
JAR entry BOOT-INF/classes!/wsdl/my.wsdl not found in C:\dev\redacted\build\libs\redacted.jar.
From looking at IntelliJ's URL, it's referring to the actual source folder which explains why it seems to always work.
What is causing this and how might I universally load these class path resources successfully with springboot?
I have an application which uses Equinox as an osgi framework for a while now. Until now I used the system property osgi.install.area to specify where my bundles are like so
${osgi.install.area}/
plugins/
org.eclipse.osgi_3.7.0.v20110613.jar
... my app bundles
Equinox then automatically uses ${osgi.install.area}/configuration as the configuration area.
Everything works fine.
Now I need to move the configuration area out of ${osgi.install.area} because that may be read-only and I thought it was as simple as setting ${osgi.configuration.area} to a suitable path but when I do this the application no longer starts and I have the following stack trace in the logs:
java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini).
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:74)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at org.eclipse.core.runtime.adaptor.EclipseStarter.main(EclipseStarter.java:150)
...
The path is used because at that location the log file is created and a directory "org.eclipse.osgi".
Paths to bundles are referenced in my config.ini like so:
osgi.bundles=de.mycomp.app-0.6.0.20121116-1834.jar#start, ...
The error message does not really give a hint where to look. It must be something rather simple but I am rather clueless at the moment.
Thanks in advance,
Robert
I tested changing the configuration area an existing osgi app and it worked, with the following argument below in the .ini file in the root of the install. Are you sure you are setting the config param correctly like this:
-Dosgi.configuration.area=c:\mytest
After doing that and running the app again, it created the folder and a new configuration.
Here is a copy of my .ini file that works, also it's important that osgi params come after and vm args.
-loglevel=trace
-vmargs
-Dosgi.configuration.area=c:\mytest
-Dorg.osgi.service.http.port=8094
-Declipse.ignoreApp=true
-Dosgi.noShutdown=true
-Dequinox.ds.print=true