Ao executar um jar
de um projeto Spring boot com a dependência do Jersey ( spring-boot-starter-jersey
) estava me deparando com o seguinte erro:
java.base/sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:86) ~[na:na]
at java.base/sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:184) ~[na:na]
at java.base/java.net.URL.openStream(URL.java:1140) ~[na:na]
at org.glassfish.jersey.server.internal.scanning.JarZipSchemeResourceFinderFactory.getInputStream(JarZipSchemeResourceFinderFactory.java:154) ~[jersey-server-2.32.jar:na]
at org.glassfish.jersey.server.internal.scanning.JarZipSchemeResourceFinderFactory.create(JarZipSchemeResourceFinderFactory.java:64) ~[jersey-server-2.32.jar:na]
... 98 common frames omitted
Encontrei a salvação em um post no StackOverFlow que diz:
The problem is that Jersey cannot scan classes in the new “fat boot jar”. This occurs when you try to use the packages(“some.package.to.scan”) method of the ResourceConfig class.
However, you can achieve the same effect using Spring classpath scanning facilities. This way you can scan a package similar to config.packages():
Note: please have a look at the source of
org.glassfish.jersey.server.internal.scanning.AnnotationAcceptingListener
. This is the stock solution and you can see that it does the same: it scans for classes annotated with@Path
or@Provider
(but doesn’t manage to find anything because of the broken scanning mechanism).
No caso o problema é relacionado a classe que faz o Scan do jaxrs
, importado pelo ResourceConfig
do glassfish: org.glassfish.jersey.server.ResourceConfig
.
@Component
public class WebJerseyConfiguration extends ResourceConfig {
public WebJerseyConfiguration() {
packages("br.com.helpdev.controller.v1");
}
}
Para solucionar esse problema devemos utilizar o Scan do Spring Boot, veja: