We have a service which uses a custom context path. In order to correctly register our Service on Eureka Server, we've set the following:
eureka.instance.statusPageUrl=http://xxx/custom/info
eureka.instance.healthCheckUrl=http://xxx/custom/health
eureka.instance.homePageUrl=http://xxx/custom/
This is working well, our application gets registered. However, although we have set the info.version information, it doesn't get displayed on the Spring Boot Admin homepage. For our application where we don't have a custom context path, it's working:
Any idea which property(ies) is/are eventually missing?
You need to add the following into your pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>build-info</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Documentation link
Related
How can I use properties from build-info.properties in application.properties?
pom.xml:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>build-info</goal>
</goals>
</execution>
</executions>
</plugin>
build-info.properties is correctly generated:
cat app/target/classes/META-INF/build-info.properties
build.artifact=foo-app
build.group=org.springframework.boot
build.name=foo-app
build.time=2021-10-13T12\:46\:08.326Z
build.version=9.9.0-9-5f12d7cd-bugfix_bar_3123_branch_name_123-dirty
How can I use them i application.properties?
foo=#project.artifactId#-sew2-san-#build.artifact#-${build.artifact}
only #project.artifactId# is resolved, neither #build.artifact# nor ${build.artifact} is resolved.
Is it possible to use properties from build-info.properties in application.properties?
If you add:
spring.config.import=classpath:META-INF/build-info.properties
to your application.properties file then interpolation with an expression like ${build.artifact} will start to work.
(Spring is loading build-info.properties with a weird manual way as you can see e.g. here https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/info/ProjectInfoAutoConfiguration.java)
I see on the web some images refferred to Spring Boot Admin showing the app version in the wallboard page.
I'm using latest version of SBA, currently 2.1.6 and i can't see the versions in the wallboard.
I see something like this.
Reading the documentation it seems that a maven plugin is needed:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>build-info</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
I added it in the pom.xml of a micro-service and I restarted all docker swarms stacks (including SBA) but no changes.
I did some search but I can't find any reference.
The 'spring-boot-maven-plugin' is required to generate the build-info in
/target/classes/META-INF/build-info.properties
Spring Boot Admin picks up the build info including the application version from this file. Please check if this file is generated.
You need to execute the maven plugin first or just run
mvn clean install
For Spring Boot applications
The easiest way 😄 to show the version, is to use the build-info goal from the spring-boot-maven-plugin, which generates the META-INF/build-info.properties.
1) Change/add the plugin in the pom.xml as below👇
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>build-info</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
2) Delete 🚮 your target folder and do a mvn clean install🧹
3) Restart your app and check the version is there 👏
I did so and it worked.
Src.➡Show Version in Application List
Dirty fix
If the previous solution does not work...
You can read the properties from the META-INF (in the jar) and concatenate it to the app name (here: myApp-service).
1) Do the previous step 👆 (add goal in maven plugin)
2) Add in the properties:
spring.config.import=classpath:META-INF/build-info.properties
spring.application.name=myApp-service ${build.version}
3) Check the result (image below 📸 )
Src.➡spring-boot-maven-plugin build-info.properties
Spring boot maven plugin stop goal fails to stop the application and leaves the application process hanging (and I and cannot start another process using the same port).
This is the plugin configuration I have:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>1.5.6.RELEASE</version>
<configuration>
<jvmArguments>-DCONFIG_ENVIRONMENT=functionaltest</jvmArguments>
<mainClass>...</mainClass>
<fork>true</fork>
</configuration>
<executions>
<execution>
<id>start-service</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop-service</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
I can't find any reference to a bug causing this behaviour. Am I using the plugin in a way it was not meant to be used maybe?
change config to this and if you want use remote debug uncomment
for start app in maven run : spring-boot:stop clean spring-boot:start
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<executable>true</executable>
<fork>true</fork>
<addResources>true</addResources>
<!-- <jvmArguments> -->
<!-- -agentlib:jdwp=transport=dt_socket,address=localhost:5005,server=y,suspend=n -->
<!-- </jvmArguments> -->
</configuration>
</plugin>
I found the problem: the spring boot application (in its main thread) starts a new thread that prevents the jvm from shutting down. Changing the "child" thread to be a daemon thread solved the issue.
Code with issue
private ExecutorService executorService = Executors.newSingleThreadExecutor(r -> {
Thread t = new Thread(r);
return t;
});
Code that solved the issue
private ExecutorService executorService = Executors.newSingleThreadExecutor(r -> {
Thread t = new Thread(r);
t.setDaemon(true);
return t;
});
Check out this SO question for more details about daemon thrreads in Java.
I'm trying to run a jar file of my Spring boot project on a Amazon AWS ec2 instance, but when I try this I get a message i do not understand (i have limited knowledge of linux...). Click the link below to see the screenhot with the message:
link to screenshot
As you can see i've installed Java and copied the jar file to /home/ec2-user.
Can anyone explain me how to proceed?
Many thanks in advance!
you need rapackage the jar, if you use maven you do like this :
1-add this in your pom:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<mainClass>your.main.calss.path</mainClass>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
2- run this commande for packaiging:
mvn package
3- run your jar
java -jar <jar-file-name>.jar
I have a Maven-built web-app that uses JPA 2.0 at the back end. The JPA provider is EclipseLink 2.3.2.
When I build the project (and it deploys runs successfully) it builds the JPA meta-model in the directory
${basedir}/target/generated-sources/annotations/
Yet the IDE doesn't see the classes defined there. Little red dots with an exclamation point everywhere. Yet I can navigate to those files in the Projects window and open the generated source files.
Does this happen to anyone else and does anyone know of a way to fix it?
UPDATE:
As a work-around I have discovered that I can exit NetBeans, delete the NetBeans cache directory, then restart. This forces NetBeans to rebuild the cache and then the classes become visible again. Should I submit a bug to the NetBeans bug tracker? I can't come up with a test case to make it happen, but it does fairly often.
If you go to project properties/sources there is a note about this: you need to generate sources under
${basedir}/target/generated-sources/FOOBAR
where FOOBAR is the name of your plugin.
After reading #jeqo answer, I tested if, by manually renaming:
"${project.build.directory}/generated-sources/annotations" to ".../generated-sources/hibernate-jpamodelgen"
would make a difference to Nebeans (I'm using v8.2 on ubuntu 16.04).
Everything worked like a charm.
I then modified the pom file as follows:
1) removed the "org.hibernate: hibernate.jpamodelgen" dependency.
2) configured the maven-compiler-plugin as follows:
<plugin>
<groupId>>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.6.1</version>
<configuration>
<compilerArgument>-proc:none</compilerArgument>
</configuration>
</plugin>
These two steps is to make sure that the hibernate-jpamodelgen does
not run on auto-pilot just by adding it in the project dependency
list. Please refer to JPA Static MetaModel Generator doc.
3) added the following plugin with configuration
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<processors>
<processor>org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor</processor>
</processors>
<defaultOutputDirectory>${project.build.directory}/generated-sources/hibernate-jpamodelgen/</defaultOutputDirectory>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-jpamodelgen</artifactId>
<version>5.2.9.Final</version>
</dependency>
</dependencies>
</plugin>
This config is directly from the Hibernate JPA Static Metamodel Generator documentation page except for the following line:
<defaultOutputDirectory>${project.build.directory}/generated-sources/hibernate-jpamodelgen/</defaultOutputDirectory>
This line simply generates the metamodel in the directory named after the maven plugin name. From this point, I got all Netbeans references working at design time as if the generated classes were in the src directory subtree.
Hope this helps,
J
Sometimes Netbeans has troubles refreshing. Perhaps clean and rebuild the project and restart Netbeans?
Today I did more experiments on this topic because it is so annoying for me as well. Finally I have realized it is only a problem related how NetBeans deal with indexing classes. This is not a problem of the target directory name and not a problem of the project. It is only NetBeans' mistake. So I have created an issue as well hopefully NetBeans Team can bring the final solution soon. You can see my ticket here https://issues.apache.org/jira/browse/NETBEANS-4191
In my environment the NetBeans 11.3 (x64) with openJDK 1.8.0_242-b08 and apache-maven 3.6.3 version is used under Windows 10 (1607).
But until the final solution arrives here is what I did as a workaround solving the symbol not found problem.
I have added a profile section to my pom file:
<profile>
<id>nb-modelgen-fix</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>modelgen-touch-files</id>
<phase>install</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<touch>
<fileset id="model.elements" dir="src/main/java" includes="**/*.java">
<containsregexp expression="(#Entity|#MappedSuperclass|#Embeddable)" casesensitive="yes" />
</fileset>
</touch>
</target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
I am using the following simple solution to generate the metamodel classes in my project:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<annotationProcessors>
<annotationProcessor>
org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor
</annotationProcessor>
</annotationProcessors>
<compilerArgs>
<arg>-Aeclipselink.persistenceunits=MY-PU</arg>
</compilerArgs>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
And of course a maven-build-helper adding the generated source folders to the project:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/annotations</source>
<source>${project.build.directory}/generated-sources/wsimport</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
And also I have created a file in the same place where the pom.xml is located called nbactions.xml with the following content (to activate this profile in NetBeans IDE only)
<?xml version="1.0" encoding="UTF-8"?>
<actions>
<action>
<actionName>rebuild</actionName>
<packagings>
<packaging>*</packaging>
</packagings>
<goals>
<goal>clean</goal>
<goal>install</goal>
</goals>
<activatedProfiles>
<activatedProfile>nb-modelgen-fix</activatedProfile>
</activatedProfiles>
</action>
</actions>
What it does? When you execute the "Clean and Build" action in NetBeans IDE it activates a task (implemented easily with maven-antrun-plugin) which just a simple touch on all JPA annotated with #Entity, #MappedSuperClass or #Embeddable theese are the sources for the metamodel generations. I have attached this task to the install phase but it worked as well in other phases as well. It lookes that this way NetBeans wake up and makes for the missing indexes for the metamodel classess.
You can read more on this in my NetBeans' issue ticket.
I hope this can save time for anybody else.
If you are using jaxws then make sure you add a <sourceDestDir> node to the <configuration> section of the jaxws plug-in "artifact" in the appropriate pom. For example:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>dojaxws</goal>
</goals>
<configuration>
<sourceDestDir>${project.build.directory}/generated-sources/jaxws</sourceDestDir>
....
</configuration>
</execution>
</executions>
<configuration>
<wsdlDirectory>src/main/resources/com/mystuff/ws</wsdlDirectory>
<bindingDirectory>src/jaxws/binding</bindingDirectory>
<target>2.0</target>
</configuration>
</plugin>
As explained above and as noted by netbeans, you must use the generate-sources path appended with the "plug-in" name. Hopefully the above clears up what "plug-in name" means and how exactly one is supposed to get jaxws to put the generated sources where netbeans need them to be. Clearly the "configuration" section will be different for each plugin... The node <sourceDestDir> is needed for jaxws, other plugins may use something else.
For me it worked after I added <endorsed.dir>${project.build.directory}/endorsed</endorsed.dir> to the <properties> of the pom.xml, e.g.:
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<endorsed.dir>${project.build.directory}/endorsed</endorsed.dir>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<jakartaee>8.0</jakartaee>
</properties>
But I have no explanation why.