Hi,
we stumbled over a problem using the BAP Services aka. rest-server-app aka. platform server.
Locally everything worked fine packaged into an docker image the application could not start:
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘versionInfoImpl’: Injection of autowired dependencies failed; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder ‘a12ServicesVersion’ in value “${a12ServicesVersion}”
We traced this problem to
com.mgmtp.a12.services.autoconfigure.ServicesCoreAutoconfiguration
where the a12ServicesVersion property is loaded.
The version.properties are loaded globally form the classpath. Unfortunately the classpath contains other dependencies that contain a version.properties file like (freemarker, apache cxf- core, httpclient, …)
So our conclusion is that its only luck that locally the right file is used.
Do you think we come to the right conclusion our did we miss something?
This could be a problem with all resources loaded from the classpath. Maybe all resources should be loaded absolute from /config/mgm/
Thx
hi @julian-typed-spruce, I deployed 1 application to our Docker environment in A12 QA server and I don’t have this problem. could you explain more details how you setup the war file, image and container?
Hi @tuan-stable-gale
Dockerfile:
FROM openjdk:8-jre-alpine
WORKDIR /app
COPY libs libs/
COPY resources resources/
COPY classes classes/
ENTRYPOINT [“java”, “-cp”, “/app/resources:/app/classes:/app/libs/*”, “com.mgmtp.howden.BrokerUIPlatformServer”]
EXPOSE 7766
The dependencies are the same like in the services-war-app:
com.mgmtp.a12.services:rest-server-app
com.mgmtp.a12:melies-model
com.mgmtp.a12:overview-model
If our conclusion is right and this behaviour is completely random and happen or not depending on os, jvm, docker base image, …
It should be reproducible starting the rest-server-app or the services-war-app with a manipulated classpath so one of the other jars containing a version.properties is before the a12 jar.
Thx
hi @julian-typed-spruce, why do you need to copy each libs, resources/ classes in to the image?
From the build time I put everything to a war file. Then start with this command
FROM java:8
COPY services-playground-war-app-0.0.1-SNAPSHOT.war target/services-playground-war-app-0.0.1-SNAPSHOT.war
COPY jetty-runner.jar target/dependency/jetty-runner.jar
EXPOSE 9090
CMD java -jar target/dependency/jetty-runner.jar --port 9090 target/*.war
All resources libs classes shoul dbe inside the war file and ready for start.
We don’t use a war we use spring boot non-fat jar with specifc layers for libs and resources so have smaller docker image layers.
But with a war or fat-jar it should be the same classpath scanning with random behaviour what is found first. There can be no guarantee that the services-core jar is before e.g. the freemarker jar on the classpath.
Hi,
it might be a problem because there are jar files like httpclient which contains version.properties. In the cxf I haven’t found it. Anyway we don’t know how spring behaves if there are multiple files.
We newer experience this problem and another reason might be that for whatever reason the version.properties is not found by the spring.
In order to drill it down I send you patched ServicesCoreAutoconfiguration which contains ref to mgm-version.properties. Then rename the file in the jar, replace the class and give a try.
We found a workaround by having our own version.properties that us found first.
The real solution will be done with: <INTERNAL_LINK>
Thx all.
From <INTERNAL_LINK> it’s named services-version.properties. No more conflict expected 