Fail by default when @EnableWebMvc is used or a WebMvcConfigurationSupport bean is configured

[xenoterracide]

http://stackoverflow.com/q/38935308/206466 I spent like 2 days trying to figure out why -Dspring.resources.static-locations wasn't working as expected (still fighting with it honestly...) all because I had @EnableWebMvc and that disables spring boot features. the fact that an Enable, disables something is hugely frustrating in its own right, but that aside I haven't noticed any warnings about it. So when using a feature that will "break" spring boot I'd like to see a warning, and maybe have a property per feature that disables said warning (if you've done that intentionally).

[wilkinsona]

I spent like 2 days trying to figure out why -Dspring.resources.static-locations wasn't working as expected

This is why it pays dividends to produce a minimal, verifiable example when you've got a problem. The questions/comments that I saw included lots of information about Docker, etc, but didn't share much/any of your actual configuration.

the fact that an Enable, disables something is hugely frustrating in its own right

Aside from the wasted time, why do you find it frustrating? It's the key to Boot having strong opinions about configuration but holding them weakly so that it can get out of your way when you want to take control. Using @Enable… is how you take that control.

[xenoterracide]

I get that Spring Boot is opinionated and that specific @Enable... is how you take control, I think that most of the time an @Enable... is required to actually get a feature at all... You want Spring Batch? or Spring Data JPA? how about Spring Session? OpenID AFAIK you have to @Enable them (there's another way), but that doesn't disable spring boot's default, maybe in part because those don't have defaults in spring boot. Thing is though more @Enable... annotations than not don't disable Spring Boot defaults. The docs on the annotations themselves don't say they will disable Spring Boot features because they aren't provided by Spring Boot.

I wasn't really looking at docker, I was showing evidence that the files were there (in fact I had some problems where they weren't at a couple of points because of npmignore and gitignore (speaking of surprising behavior not shipping files in gitignore...)). Thing is I was trying to think of anything that could be causing it, but I didn't notice any logs telling me why it couldn't find file X.

Sure a reproducible minimal project is a good idea, and in this case I might have been able to do it, the project is still small. In the non boot scenario I work on is a 400k line project, when something goes wrong producing a minimal project is often not viable. I'm slowly working towards making it a Boot-able project. This project is already over 2000 lines, so how do I know which of those configs are relevant? I might produce a project that works, but all that would tell me is I had a conflict which I already suspected. I didn't really think that it didn't work at all, just that it wasn't working in my situation, and that that didn't make sense to me, and I thought I was showing the relevant configuration, which was the property, and the logs showed the property was recognized, and it showed it trying to match the property. So why would I think that it wasn't working at all?

Now there are certain scenario's where I don't think adding warnings would be useful, e.g. adding an EntityManager @Bean is pretty obviously going to override a Boot Default. I'm mostly concerned about the couple of cases where @enable disables something, because @enable seems like a "Boot Feature", something written for the "Boot will make this easy for me" case.

[xenoterracide]

as a side note there were also no warnings about file:/package/dist vs file:/package/dist/**vs file:/package/dist/. As far as I can tell the first 2 don't do what I mean.

[snicoll]

Actually you're wrong. Taking spring session as an example, it is auto-configured and we'll back-off if you use one of the EnableXYZ of Spring Session. It's the exact same thing. The difference is that @EnableSpringMvc has a much larger scope and the relationships with message converters or static locations may not be obvious at first. But don't take control of something (don't add code) unless you really have to.

I am with Andy regarding the sample project: we do our best to monitor gitter, stackoverflow, twitter, this tracker and people pinging us privately. This is a lot of work so the least you can do is try to focus on the problem at hand and try to minimize both the dependencies and the code that actually shows the problem.

[bclozel]

We could turn the last sentence of that section into an asciidoctor TIP. But I'm not sure that would improve the experience of developers if they don't have the reference documentation handy.

[xenoterracide]

Actually you're wrong. Taking spring session as an example, it is auto-configured and we'll back-off if you use one of the EnableXYZ of Spring Session.

when was that added? (largely rhetorical) following the Spring Session docs doesn't make this obvious, I'm guessing 1.4. Even this code is an upgrade from 1.3. I've been using Boot for side projects since 1.1, and so some of these haven't always been the case.

I am with Andy regarding the sample project: we do our best to monitor gitter, stackoverflow, twitter, this tracker and people pinging us privately.

there's a gitter? I must have missed that channel in the docs.

This is a lot of work so the least you can do is try to focus on the problem at hand and try to minimize both the dependencies and the code that actually shows the problem.

Oh I can respect open source is a lot of work, I have a number of now Perl projects, that I maintained for a couple of years. Don't take this as disrespecting the support aspect. I didn't provide sufficient information to say why it wasn't working, but from the logs, I didn't know that.

the point I'm trying to reach here as I think that I should have been able to figure this out by reading the logs. But the logs made it look like it was searching that path, even at trace level.

That said I don't want to argue about this, I'm simply trying to improve this situation so I can support myself better, without having to ask for help.

We could turn the last sentence of that section into an asciidoctor TIP

that might work? I'm not sure how TIPS output... without reference documentation I'm not sure how you would figure this out currently.

[wilkinsona]

https://dzone.com/articles/spring-boot-enablewebmvc-and-common-use-cases

My suggestion in situations like this is: log a warning. And require explicitly disabling autoconfiguration in order to get rid of the warning. I had to turn on debug to see what gets autoconfigured, and then explore a bunch of classes to check the necessary conditions in order to figure out the situation.