I am trying to develop a simple JAX-RS based web service using Spring Boot version 1.4.1.RELEASE. However getting this exception -
java.lang.IllegalStateException: No generator was provided and there is no default generator registered at org.glassfish.hk2.internal.ServiceLocatorFactoryImpl.internalCreate(ServiceLocatorFactoryImpl.java:308) ~[hk2-api-2.5.0-b05.jar:na] at org.glassfish.hk2.internal.ServiceLocatorFactoryImpl.create(ServiceLocatorFactoryImpl.java:268) ~[hk2-api-2.5.0-b05.jar:na] at org.glassfish.jersey.internal.inject.Injections._createLocator(Injections.java:138) ~[jersey-common-2.23.2.jar:na] at org.glassfish.jersey.internal.inject.Injections.createLocator(Injections.java:123) ~[jersey-common-2.23.2.jar:na] at org.glassfish.jersey.server.ApplicationHandler.(ApplicationHandler.java:330) ~[jersey-server-2.23.2.jar:na] at org.glassfish.jersey.servlet.WebComponent.(WebComponent.java:392) ~[jersey-container-servlet-core-2.23.2.jar:na] at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:177) ~[jersey-container-servlet-core-2.23.2.jar:na] at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:369) ~[jersey-container-servlet-core-2.23.2.jar:na]
Here are my program details -
Dependencies included in POM.xml -
org.springframework.bootspring-boot-starter-jerseyorg.springframework.bootspring-boot-starter-testtest
And here is JerseyConfig file -
package com.test.main; import org.glassfish.jersey.server.ResourceConfig; import org.springframework.stereotype.Component; import com.test.resources.TutorialResource; @Component public class JerseyConfig extends ResourceConfig{ public JerseyConfig() { register(TutorialResource.class); packages("com.test.resources"); } }
Important: Looks like this issue is not present in most recent versions of Spring Boot. However the content of this answer can still be used as a guide when you want to create an application with Spring Boot and Jersey.
The layout of the JAR has changed in Spring Boot 1.4.1
The layout of executable jars has changed in Spring Boot 1.4.1: application’s dependencies are now packaged in BOOT-INF/lib rather than lib, and application’s own classes are now packaged in BOOT-INF/classes rather than the root of the jar. And it affects Jersey:
Jersey classpath scanning limitations
The change to the layout of executable jars means that a limitation in Jersey’s classpath scanning now affects executable jar files as well as executable war files. To work around the problem, classes that you wish to be scanned by Jersey should be packaged in a jar and included as a dependency in BOOT-INF/lib. The Spring Boot launcher should then be configured to unpack those jars on start up so that Jersey can scan their contents.
I've found that registering classes instead of packages works. See below the steps to create an application with Spring Boot and Jersey.
Creating a web application with Spring Boot and Jersey
Ensure your pom.xml file declares spring-boot-starter-parent as the parent project:
org.springframework.bootspring-boot-starter-parent1.4.1.RELEASE
You also need the following dependencies:
org.springframework.bootspring-boot-starter-weborg.springframework.bootspring-boot-starter-jerseyorg.springframework.bootspring-boot-starter-testtestjunitjunittest
And the Spring Boot Maven plugin:
org.springframework.bootspring-boot-maven-plugin
For example purposes, create a Jersey resource class annotated with @Path and define a resource method to handle GET requests, producing text/plain:
@Path("/greetings") public class GreetingResource { @GET @Produces(MediaType.TEXT_PLAIN) public Response getGreeting() { return Response.ok("Hello, World!").build(); } }
Then create a class that extends ResourceConfig or Application to register the Jersey resources and annotated it with @ApplicationPath. Registering classes instead of registering packages works with Spring Boot 1.4.1:
@Component @ApplicationPath("api") public class JerseyConfig extends ResourceConfig { @PostConstruct private void init() { registerClasses(GreetingResource.class); } }
And finally create a Spring Boot class to execute the application:
@SpringBootApplication public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
If you want to test this web service, you can use the JAX-RS Client API:
@RunWith(SpringRunner.class) @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) public class GreetingResourceTest { @LocalServerPort private int port; private URI uri; @Before public void setUp() throws Exception { this.uri = new URI("http://localhost:" + port); } @Test public void testGreeting() { Client client = ClientBuilder.newClient(); Response response = client.target(uri).path("api").path("greetings") .request(MediaType.TEXT_PLAIN).get(); String entity = response.readEntity(String.class); assertEquals("Hello, World!", entity); } }
To compile and run the application, follow these steps:
- Open a command line window or terminal.
- Navigate to the root directory of the project, where the
pom.xml resides. - Compile the project:
mvn clean compile. - Package the application:
mvn package. - Look in the target directory. You should see a file with the following or a similar name:
spring-jersey-1.0-SNAPSHOT.jar. - Change into the target directory.
- Execute the JAR:
java -jar spring-jersey-1.0-SNAPSHOT.jar. - The application should be available at
http://localhost:8080/api/greetings.
Note 1: Have a look at the Spring Boot documentation. There's a section dedicated to Jersey.
Note 2: When producing JSON, ensure you have a JSON provider registered. ResourceConfig should take care of that though (just ensure that the dependencies are on the classpath).
Although Jersey cannot scan your classes inside the new version of the fat boot jar, you can achieve the same effect using Spring classpath scanning facilities. This way you can scan a package similarly to ResourceConfig.packages():
ClassPathScanningCandidateComponentProvider scanner = new ClassPathScanningCandidateComponentProvider(false); scanner.addIncludeFilter(new AnnotationTypeFilter(Provider.class)); scanner.addIncludeFilter(new AnnotationTypeFilter(Path.class)); config.registerClasses(scanner.findCandidateComponents("your.package.to.scan").stream() .map(beanDefinition -> ClassUtils.resolveClassName(beanDefinition.getBeanClassName(), config.getClassLoader())) .collect(Collectors.toSet()));
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).
Update:
I had a custom config which didn't extend ResourceConfig but returned an instance of it as a bean. If you look at the official Spring example, you can insert the code above into the JerseyConfig() constructor (instead of the two register(...) calls). The only difference is that instead of calling config.registerClasses(...) you simply call registerClasses(...) in the constructor.
I think you should annotate your JerseyConfig with @Configuration and not @Component.
