I'm stuck behind this error in IDEA. I was working as usual debugging some classes and everything was working just fine. But at a given moment my spring application stopped initializing and this line appear on the console every time now, and the application remains in a infinite loop, trying to initialize:
The Class-Path manifest attribute in /home/user/maven/repository/com/sun/xml/bind/jaxb-impl/2.2.3-1/jaxb-impl-2.2.3-1.jar referenced one or more files that do not exist: file:/home/user/maven/repository/com/sun/xml/bind/jaxb-impl/2.2.3-1/jaxb-api.jar,file:/home/user/maven/repository/com/sun/xml/bind/jaxb-impl/2.2.3-1/activation.jar,file:/home/user/maven/repository/com/sun/xml/bind/jaxb-impl/2.2.3/jsr173_1.0_api.jar,file:/home/user/maven/repository/com/sun/xml/bind/jaxb-impl/2.2.3-1/jaxb1-impl.jar
And these lines :
project: 1.1.0-iron-man-SNAPSHOT
Spring Boot version: (v1.5.10.RELEASE)
Java Version: 1.8.0_141
Source Encoding: UTF-8
turned out to this:
project: #project.version#
Spring Boot version: (v1.5.10.RELEASE)
Java Version: #java.version#
Source Encoding: #project.build.sourceEncoding#
I'm didn't change any config files in the project.
I have tried mvn clean install.
I have tried to force IDEA to read the maven dependecies again.
None of them have worked.
Maybe File -> Invalidate Caches / Restart helps
First Picture MANIFEST.MF defines the classpath
But they are stored in different maven repository forlders
Related
In our Pipeline I have a surprising situation. If I using Gradle 6.8.x and higher a COPY *.jar to /opt/file.jar inside an unchanged Dockerfile did not work with:
Step 21/33 : COPY *.jar /opt/file.jar
When using COPY with more than one source file, the destination must be a directory and end with a /
Using Gradle with version 6.5.x and early it works.
Which different behavore has Gradle with 6.8.x and higher, which ends in conflicts with a Dockerfile and how can I solve this?
Thx in advance
Not sure if this helps, but I had the same problem (updating from Gradle 6.5 to 7.3), and also simultaneously updating from Spring Boot 2.4 to 2.6, which was actually my problem.
Spring Boot starts to create plain.jar by default next to your jar (documentation) since version 2.5.0, so in my build folder were actually 2 *.jar files and the COPY error was correct.
How to disable creation of plain.jar file is answered here
If this is not your case, please check what actually gets created in your build folder and if there are multiple files.
I thought I had this working because in my IDE the correct environment properties file was being used, and a local application.properties was being correctly used. I am trying to use profile specific properties to determine various values throughout my Spring-Boot 1.3.5 app.
My src/main/resources/application.properties is:
spring.profiles.active=test
server.port=8080
deploy.server=http://localhost
liquibase.change-log:classpath:/db/changelog/db.changelog-master.xml
liquibase.check-change-log-location=true
spring.thymeleaf.prefix=classpath:/templates/
spring.thymeleaf.suffix=.html
logging.file=myapp.log
spring.jackson.serialization.write_dates_as_timestamps=false
And I have a src/main/resources/application-test.properties:
server.port=8081
deploy.server=https://test.myapp.com
logging.level.liquibase:TRACE
logging.level.org.springframework.security:DEBUG
Now I apparently have two problems:
After I run "gradle clean build" I get my jar and trying to run via:
java -jar build/libs/app.jar -Dspring.profiles.active=local
I see the message:
The following profiles are active: test
So it picking that up from the application.properties file and I can't seem to override it, which I think is causing my second problem:
My Jenkins build fails when I try to use a parameterized build with the values:
spring.profiles.active set to "test".
The error I get is Tomcat in a failed state. If I take that parameter out of the build, it works. But that build will not run from the command line unless I copy the application-{env}.properties to the run directory (which might be best practice anyway?).
I am not sure if the problem is the location of the properties files or the way I am trying to build 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?
The closest stackoverflow question that explains my symptoms is here - How can I deploy a Grails 3.0.1 war file in Tomcat7?
I am in the process of upgrading a Grails 2.3.4 application to Grails 3.1.10 and everything is working with 'grails run-app'.
When i deploy to a war i get nothing but 404's for any url.
The war deploys without any error messages in catalina.out.
The tomcat access logs show my access attempts. (not linux problem?)
I can get to the tomcat manager, and the tomcat manager shows my app as "running" as true. (no errors)
Manager shows myapp-0.1 because the war file was myapp-0.1.war .. this is fine for now.
I am running Grails 3.1.10.
I have tried against Tomcat 7.0.55 as well as 8.0.92.
I have tried changing grails.serverUrl in application.groovy to various values. It is now:
//fix war name after get working
grails.serverUrl = "/myapp-0.1"
System.setProperty("server.contextPath","/myapp-0.1")
I have tried the above without "-0.1". (i was suprised to learn this was necessary - https://stackoverflow.com/a/23664531/104993)
I have tried changing "org.springframework.boo:spring-boot-starter-tomcat" from "compile" to "provided" in the build.gradle file.
Please let me know what I need to elaborate on. It's difficult to paste log outputs and config files. (i'm behind a firewall)
You add the following task to your build.gradle it will name the war what ever you want:
task wrapper(type:Wrapper){
war.archiveName='myWar.war'
}
Then when you deploy it should have the correct name and you can go to https://localhost:8080/myWar
I am trying to configure console appender in my project. It works fine when I launch my app in debug locally. However, when I build it my jar in Gradle and launch it as a standalone app I get following error:
[0]; Could not resolve type id 'console' into a subtype of [simple type, class io.dropwizard.logging.AppenderFactory]: known type ids = [AppenderFactory]
Here is the snippet of my .yml file:
logging:
appenders:
- type: console
timeZone: UTC
logFormat: '%-5level [%date{ISO8601}] [%X{requestId}] %c: %msg%n%rootException'
I was able to find posts about similar issues. For instance, this thread here suggests to check if file META-INF/services/io.dropwizard.logging.AppenderFactory is in the application jar and if it contents is as following:
io.dropwizard.logging.ConsoleAppenderFactory
io.dropwizard.logging.FileAppenderFactory
io.dropwizard.logging.SyslogAppenderFactory
I have verified it. In my case file is where it supposed to be and it has exactly the same contents.
Any help will be greatly appreciated.
Dropwizard version 0.9.2
Does the Gradle produce a Uber/Fat Jar (A jar with all it's dependencies inside itself) or a simple jar with only your Dropwizard app?
It's advisable to build an Fat-jar for Dropwizard deployments, so do switch over to this style if you're not doing so.
Now while building a Fat-Jar, you need to do the following to solve your problem (this was mentioned in the discussion you linked)
If you use maven-shade plugin for building a fat jar, don't forget about SPI resource transformer for collecting SPI resources into the jar.
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
To do the same in Gradle, check this discussion.
HTH.