Be able to specify a default content type when no extension is used in ContentNegotiatingViewResolver [SPR-6130]

[spring-projects-issues]

Ken Egervari opened SPR-6130 and commented

I'm having a problem where I am trying to get xml, json, html, etc. to work using the content negotiator. It works perfectly... almost. The main problem I'm having is that the default content type is coming up as XML. Here is the dispatcher servlet xml:

<bean id="contentNegotiatingViewResolver"
      class="org.springframework.web.servlet.view.ContentNegotiatingViewResolver">
    <property name="order" value="2"/>
    <property name="mediaTypes">
        <map>
            <entry key="ftl" value="text/html"/>
            <entry key="xml" value="application/xml"/>
            <entry key="json" value="application/json"/>
            <entry key="atom" value="application/atom+xml"/>
            <entry key="rss" value="application/rss+xml"/>
        </map>
    </property>
    <property name="defaultViews">
        <list>
            <bean class="org.springframework.web.servlet.view.xml.MarshallingView">
                <property name="marshaller">
                    <bean class="org.springframework.oxm.xstream.XStreamMarshaller">
                        <property name="autodetectAnnotations" value="true"/>
                    </bean>
                </property>
            </bean>
            <bean class="org.springframework.web.servlet.view.json.MappingJacksonJsonView"/>
        </list>
    </property>
    <property name="viewResolvers">
        <list>
            <bean id="viewResolver" class="org.springframework.web.servlet.view.freemarker.FreeMarkerViewResolver">
                <property name="order" value="1"/>
                <property name="cache" value="false"/>
                <property name="prefix" value=""/>
                <property name="suffix" value=".ftl"/>
                <property name="exposeSpringMacroHelpers" value="true"/>
            </bean>
        </list>
    </property>
</bean>

As it stands, mapping to "/" results in Spring trying to get to "/.xml", which is terrible since it really needs to get mapped to what I have in @RequestMapping in a controller (mine points to "index", which in turns should get mapped to "index.ftl" in the view resolver)

Ultimately though, despite the above mentioned problem, having to specify ".ftl" whenever I want a text/html view is somewhat annoying. It's workable mind you... but then there is no change of having a proper index page.

If there is quick workaround, would you please email me? Maybe I set it up incorrectly too... and if that's the case, I apologize for posting this.

Thanks for all of your help!

---

Affects: 3.0 M4

Reference URL: http://forum.springsource.org/showthread.php?p=261035#post261035

Issue Links:

• ContentNegotiatingViewResolver picks first media type from Accept header which is not consistent across browsers [SPR-5706] #10376 ContentNegotiatingViewResolver picks first media type from Accept header which is not consistent across browsers

Referenced from: commits 5faa4d9

[spring-projects-issues]

Ken Egervari commented

Oh, this kind of an aside... is there a way to tell the web.xml that I only want a couple of patterns and not just /*? Currently, this will intercept *.gif and stuff like that... which is obviously bad. I really don't want to send those urls to the dispatcher servlet ;)

I can only come up with two ways to fix it. I can map to /spring/* for all my dispatcher servlet needs... which would make it possible for /images/blah.gif to be resolved normally. Or, I could create dispatcher servlets... but that defeats the whole point of content negotiation ;(

I wish Sun smartened up when they made the web.xml and let me people use a list of patterns :( They always mess things up for everybody on just about everything they touch.

[spring-projects-issues]

Arjen Poutsma commented

Fixed formatting

[spring-projects-issues]

Arjen Poutsma commented

Fixed formatting

[spring-projects-issues]

Ken Egervari commented

Thanks for fixing the formatting :)

I also want to add that using content negotiation does have a drawback with how the web.xml needs to be setup.

In order to get all the urls to be served correctly without extensions, we usually map like /*. This in turn blocks javascript, images, css, etc. as they are sent to the dispatcher servlet. So, we usually have to make our url-patterns more fine-grain with 2.5 servlet spec (2.4 won't help).

Honestly, what I think would help, once all the bugs are ironed out, is solid documentation showing how to configure a web.xml and xyz-servlet.xml properly with all the trimmings, just so people can get this up and running quickly and bug-free. Because honestly, I played with it for hours getting settings that worked reasonably well... and no sense why everyone should do that ;) You can use my code as a place to start even.

I think having a default content for no file extension would be very good... and possibly turning off reading the application type in the headers. I feel really confident I can develop the file names correctly... so this sort of thing can mess things up and become unpredictable. Turning it on/off would be a good idea as well.

[spring-projects-issues]

Arjen Poutsma commented

The issue you are describing initially is that you have listed the MarshallingView (with an XML content type) as default view. As such, you will end up with XML as default. It's better to have an alternative ViewResolver (such as the BeanNameViewResolver), and use that directly.

Additionally, using a /* pattern is typically not a good idea (especially when using JSPs, which you don't). Some parts of the web app do not have to be served by the DispatcherServlet (such as gifs, and other resources).

Finally, I will add a flag to disable reading the accept headers, as you suggest in your last comment.

[spring-projects-issues]

Ken Egervari commented

Hi Arien, Thanks for your response. I tried to respond early, but then the status was closed. I am glad you have reopened it.

I wanted to say that I misunderstood what defaultViews did - I thought that this view resolver would only use those views if xml or json was requested. I did not think it would default to them.

Even if that is the case... there is no way to know if xml or json is the prefered view, unless it just selects the first one in the last. And then if it does that... then why bother having a list in the first place?

And if the default views is only to select a default... then why does .xml and .json actually work? It kind of behaves like my assumption on how it worked.

Basically, I think the easiest way to get this to work as expected is by changing a couple of things

1. Make those json/xml views and turn them into view resolvers. As it stands, I don't know how to make those into view resolvers; or

2. Make default views only work for their respective content types. I'm actually thinking of a structure that is a bit different, and I think it makes sense.

<property name="mediaTypes">
	<list>
		<bean p:mediaType="application/xml" p:extension="xml" class="MediaType">
			<property name="defaultView">
				<bean class="org.springframework.web.servlet.view.xml.MarshallingView"> 
					<property name="marshaller"> 
						<bean class="org.springframework.oxm.xstream.XStreamMarshaller"> 
							<property name="autodetectAnnotations" value="true"/> 
						</bean> 
					</property> 
				</bean> 
			</property>
		</bean>
		<bean p:mediaType="application/json" p:extension="json" class="MediaType">
			<property name="defaultView">
				<bean class="org.springframework.web.servlet.view.json.MappingJacksonJsonView"/> 
			</property>
		</bean>
		<bean p:mediaType="text/html" p:extension="ftl" class="MediaType" />
	</list>
</property>
<property name="defaultRestMediaType" value="text/html" />

It's just an idea. It's different than how yours works now, but I think it's more intuitive. I dunno - this is how I thought about the problem, and this is what I wanted to express to spring.

I'm also aware that /* is a bad ;) Like I said, I narrowed it down to a subset. This was my guess since documentation is a bit brittle right now, and unfortunately, blogs and "advice" on the net actually says to do this. Other blogs giving advice say /rest/*, but I think that's just as bad. The last thing I want is /myproject/rest/login.ftl

Thanks so much for the help and for entertaining my ideas!

Ken

[spring-projects-issues]

Arjen Poutsma commented

Those default views are considered for each request, even when no view resolver resolves them. They are considered as candidates, and they still need to match the media type of the request (be it through file extension, parameter, or accept header).

[spring-projects-issues]

Ken Egervari commented

Well, that's behaviour I don't really want. I know that I am not the only one having problems wrapping my head around this. I've googled this a lot and read many spring posts before I posted a JIRA request and lots of people are having problems with this.

For example, I read about some browsers (I think it was firefox) having different priorities for xml and html content types than other browsers, so the result is unpredictable. This is very, very bad, and is a good reason to allow developers to turn it off.

I guess I want to be in control as to what happens... not the browser. I want my application to server what I tell it to, and there isn't enough options (at least I don't know of any) in this new view resolver to dictate what I want it to do.

What I want to do is simple... simple enough that I think most people using your framework will want to do it too.

I want to have urls like

/userAccount/list

go to freemarker. I also want

/userAccount/lists.ftl

to go to freemarker.

And if I allow it to, I want

/userAccount/list.xml
/userAccount/list.json

to work as well. It's really a very, very simple idea ;) And as a consequence, it should be simple to set this up ;)

[spring-projects-issues]

Arjen Poutsma commented

As stated before, I am adding a property to disable inspection of the Accept header, and also allow for a default content-type, that will be used when the other mechanisms (extension, parameter, accept header) fail.

In other words: don't worry, I am giving you what you want.

[spring-projects-issues]

Ken Egervari commented

Woo hoo!

Thanks Arjen Poutsma! ;)

[spring-projects-issues]

Arjen Poutsma commented

Done. Added ignoreAcceptHeader and defaultContentType properties.

[spring-projects-issues]

Ken Egervari commented

Yay! You rock Arjen! That's perfect! I can't wait to try it out when it becomes available.