search

allegro / handlebars-spring-boot-starter

Spring Boot auto-configuration for Handlebars
Apache License 2.0
109 stars 27 forks source link

View Resolving Breaks After .html Is Accessed #7

Closed dadepo closed 9 years ago

dadepo commented 9 years ago

The scenario:

http://localhost/home --> maps to /home --> resolves to home.hbs (Fine) http://locahost/randomlink --> no controller found --> resolves to error.hbs (Fine) http://localhost/randomlink.html --> no controller found --> resolves to error.hbs (Things start to go wrong) http://localhost/home --> controller is hit (thanks to breakpoints) --> but resolves to error.html.hbs (Not Fine)

Seems once a url with .html is accessed, things blow up and consequent navigation to url that has valid request mapping cease to work. (since the view resolution now looks for file with ".html.hbs" extension instead of ".hbs".

I am thinking this is a bug?...not a mis-configuration?

What do you advice? Thanks!

plesiecki commented 9 years ago

Hi there,

Thanks for pointing this out! I'll investigate on this issue. Stay tuned :wink:

plesiecki commented 9 years ago

For now what I can advice is to exclude ErrorMvcAutoConfiguration from your spring-boot app by @SpringBootApplication(exclude = ErrorMvcAutoConfiguration) or @EnableAutoConfiguration(exclude = ErrorMvcAutoConfiguration). I wonder if other starters like this one have similar issue. Let me see what I can find.

dadepo commented 9 years ago

Hi piesiecki, Thanks for the suggestion, Where you able to reproduce the scenerio?

I tried your suggestions, and I now got the exception in the logs also showin in the client: java.io.FileNotFoundException: classpath:myview/myview.html.hbs

I would investigate further and confirm if this is a bug (misconfiguration) somewhere else outside of handlebars-spring-boot-starter. I would update as necessary.

plesiecki commented 9 years ago

Sure, I had no problems to reproduce the scenario. As far as I noticed excluding ErrorMvcAutoConfiguration solved the issue but still I'm not sure exactly why this happened. From what I understand it didn't work in your case, right? I'm going to upload sample app on which I made my test.

dadepo commented 9 years ago

Nope. It did not work in my case. The view resolution still tries to fetch viewname.html.hbs after a wrong url with html extension was hit. :/

plesiecki commented 9 years ago

Actually you are right. I have changed the scenario which led me to the wrong conclusion. I'm still looking for the answers

dadepo commented 9 years ago

Cool! I also confirmed that this is specific to handlebars-spring-boot-starter. I temporarily switched to spring-boot-starter-freemarker and everything works as it should.

Although, my knowledge of the internals of Spring's view resolution is limited, I would try to debug the issue on my end too.

dadepo commented 9 years ago

Actually it does not matter if the url with .html is missing or not. I was able to reproduce even when /foo.html resolved into a foo.html file in the static (or public) folder.

The bug always triggers after a request with an html extension is made.

dadepo commented 9 years ago

From stepping through the code execution I think the issue has to do with the content negotiation process. When /foo.html is hit which returns a valid view name say "home", I actually see that the home.hbs is found and added to candidateViews in the ContentNegotiatingViewResolver class but the view resolving processes does not stop here but the content negotiation kicks in, and a view based on /foo.html is being sought...and due to what I cant explain yet, the initial view added to the candidateViews list is overwritten.

I have managed to put my app in a usable form for now by switching off the content negotiation as instructed in this issue https://github.com/spring-projects/spring-boot/issues/546. I would still like to be able to turn that back on and still be able to use handlebars-spring-boot-starter :)

Hope this helps you in looking for the answer on how to fix the issue? Thanks!

plesiecki commented 9 years ago

Thank you very much for your great effort which led me to the solution. Really appreciate that!

plesiecki commented 9 years ago

I'm happy to announce that the version 0.2.1 has been released

dadepo commented 9 years ago

Great! But not published to Maven Central yet?

platan commented 9 years ago

It's already there: http://search.maven.org/#artifactdetails|pl.allegro.tech.boot|handlebars-spring-boot-starter|0.2.1|jar

dadepo commented 9 years ago

Yes indeed! Thanks for the effort!