Closed
Description
Hi
I just cloned the starter-jersey sample then tried to add dependency spring-boot-starter-actuator.
Looks like any context mapped by actuator are working
The trouble is stdout looks fine, saying all endpoints are added, but when doing /health or /metrics .... nothing appears in a browser.
In fact it's a 404 error (displayed woth curl -i)
Looks like error page are not working as well.
I guess all this is due to Jersey but not able to do more troubleshooting.
Tested on 1.2.0-BUILD-SNAPSHOT
Christophe
Activity
philwebb commentedon Dec 1, 2014
The actuator HTTP endpoints are exposed via Spring MVC and we currently don't provide equivalents for Jersey. I'm not sure if you can easily mix Jersey and Spring MVC (@dsyer might know).
celkins commentedon Dec 1, 2014
It can be done, but IME you do have to provide your own
FilterRegistrationBean
and tweak actuator endpoint paths. For example, with Jersey 1 (and Spring Boot 1.1):Jersey 2 would be trivially similar, with slightly different init parameter names. Getting it working with
spring-boot-starter-jersey
might be more problematic.ouaibsky commentedon Dec 1, 2014
@philwebb: if other starters cannot be used on top of spring-boot-starter-jersey, it doesn't make sense to provide support to another REST fwk
@celkins: Thx for jersey 1 clue. I'm gonna continue my investigation with Jersey 2 & starter-jersey but unfortunately, after playing a few day I'm wondering if philwebb is not right and probably give up jersey ... or find other alternatives.
Thx
Christophe
dsyer commentedon Dec 1, 2014
I don't understand what the problem is really. Jersey (1 or 2) can be installed as either a servlet or a filter, and if you map those to the same path as the Actuator endpoints, of course it's not going to work. You don't need a custom registration for Jersey 2 for vanilla use cases either (filter and servlet and custom paths are supported out of the box, and Jersey has a ton of options that are supported through
spring.jersey.*
). Or am I missing something?celkins commentedon Dec 1, 2014
@ouaibsky: One option is to set the
server.servletPath
property to move the defaultDispatcherServlet
out of the way. Alternatively, if you are willing and able to re-route your Jersey resources, you can add@ApplicationPath
to yourResourceConfig
class to move them out of the way.@dsyer: I think it's a matter of the perhaps unrealistic expectation that one can add a dependency on
spring-boot-starter-actuator
to aspring-boot-starter-jersey
-based application and have everything just work.ouaibsky commentedon Dec 3, 2014
@dsyer, I'm exactly in the situation describe by @celkins below. Just putting spring-boot-starter-actuator to a spring-boot-starter-jersey and expecting it should work out of the box
But I understand now it's a bit more tricky (and has been designed first to work with Spring MVC)
I'm not an expert of Filter nor DispatchingServlet, Likely I need to read documentation more in details about Jesey configuration and Spring MVC.
@celkins Meaning if I move out DispatcherServlet, request will be automatically handle by jerseyServlet ?
For information the output when I start the example and doing some REST requests (in facto no more output if a request works or not)
celkins commentedon Dec 3, 2014
@ouaibsky These lines indicate the crux of your problem:
jerseyServlet
effectively shadows everything under the root, sodispatcherServlet
never sees any requests that it would otherwise forward to the actuator endpoints.Compare that to what happens when you override
server.servletPath
to, for example,/spring
:With such a configuration, the actuator endpoints (as well as everything else handled by
dispatcherServlet
) are exposed as/spring/health
,/spring/metrics
, etc. For example,ouaibsky commentedon Dec 7, 2014
Thx @celkins
I confirm it works by adding a property server.servletPath.
Don know if it will be a "fragile" solution regarding future enhancement of spring-boot but it works
Thx
wujek-srujek commentedon Jul 15, 2015
I was also caught by this one, i.e. expecting the actuator to work with boot-starter-jersey. This was after we already committed to Jersey, so going back to webmvc is not an option. So now, it seems we have to depend on both webmvc (for example, via boot-starter-web) and jersey 2 (via boot-starter-jersey), i.e. have two REST libraries, which imho is not nice.
Anyways, I was able to configure it both ways:
add @ApplicationPath("api") on the ResourceConfig @component - in this case, all my custom resources are accessed with /api/hello etc.
remap the dispatcherServlet to /spring with server.servlet-path - the only thing I find strange is that while log says the dispatcher has been remapped, the endpoints are still reported under their original urls, for example:
2015-07-15 23:15:24.292 INFO 2272 --- [ main] o.s.b.c.e.ServletRegistrationBean : Mapping servlet: 'dispatcherServlet' to [/spring/]
2015-07-15 23:15:26.218 INFO 2272 --- [ main] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped "{[/error]}" onto public org.springframework.http.ResponseEntity<java.util.Map<java.lang.String, java.lang.Object>> org.springframework.boot.autoconfigure.web.BasicErrorController.error(javax.servlet.http.HttpServletRequest)
2015-07-15 23:15:26.219 INFO 2272 --- [ main] s.w.s.m.m.a.RequestMappingHandlerMapping : Mapped "{[/error],produces=[text/html]}" onto public org.springframework.web.servlet.ModelAndView org.springframework.boot.autoconfigure.web.BasicErrorController.errorHtml(javax.servlet.http.HttpServletRequest)
2015-07-15 23:15:26.249 INFO 2272 --- [ main] o.s.w.s.handler.SimpleUrlHandlerMapping : Mapped URL path [/webjars/] onto handler of type [class org.springframework.web.servlet.resource.ResourceHttpRequestHandler]
2015-07-15 23:15:26.249 INFO 2272 --- [ main] o.s.w.s.handler.SimpleUrlHandlerMapping : Mapped URL path [/] onto handler of type [class org.springframework.web.servlet.resource.ResourceHttpRequestHandler]
2015-07-15 23:15:26.290 INFO 2272 --- [ main] o.s.w.s.handler.SimpleUrlHandlerMapping : Mapped URL path [/*/favicon.ico] onto handler of type [class org.springframework.web.servlet.resource.ResourceHttpRequestHandler]
2015-07-15 23:15:26.661 INFO 2272 --- [ main] o.s.b.a.e.mvc.EndpointHandlerMapping : Mapped "{[/configprops],methods=[GET]}" onto public java.lang.Object org.springframework.boot.actuate.endpoint.mvc.EndpointMvcAdapter.invoke()
Above, the /configprops URL is still reported although the one to use is /spring/configprops. Also, I don't really know if the /webjars/** is now /spring/webjars/**, the same for /error etc.
What makes things very, very confusing is that it is not documented anywhere that the actuator depends on webmvc; what is more, the spring-boot-actuator/pom.xml says the dependency on webmvc is optional (
spring-boot/spring-boot-actuator/pom.xml
Lines 145 to 149 in de95012
snicoll commentedon Jul 16, 2015
I think the misunderstanding comes from the fact that the "web" exposure is just one feature of the actuator. You can access to the same features via JMX endpoints for instance. That's why it's optional
Granted it's not super obvious but this page on "Monitoring and management over HTTP" starts with:
I'll add an explicit tip in that section.
Clarify doc
wujek-srujek commentedon Jul 16, 2015
Now I understand why it's marked optional, I didn't know about the other options (JMX, shell), now I read the full docs and know better.
As for the note you added - do you think it would be worth adding how both MVC and Jersey can be used together? It seems, even in this very issue, even the Boot core devs weren't sure if and how to make it work.
snicoll commentedon Jul 17, 2015
I think we didn't try to make it work, indeed. You can always create a separate issue to ask for a sample. PR more than welcome.
21 remaining items