Issue 1:
Ken Egervari opened SPR-7054 and commented

I am having a heck of a time doing complex Ajax stuff with Spring MVC 3.0. While I totally appreciate a lot of the advancements, there are a few features that are just "missing".

The one thing I am having problems with is @RequestBody. It seems that Spring is handling JSON mappings to Strings, ints, longs and other primitive types just fine. Unfortunately... and this is extremely disappointing... Spring does not also use the property editors.

So, in its current state, we can create an object with "long myDomainObjectId" but not "MyDomainObject myDomainObject" and have Spring do the mapping for us. Instead, Spring throws back:

The server refused this request because the request entity is in a format not supported by the requested resource for the requested method ().

In Firebug, it just says, "Unsupported Mime type". And before you say anything, I am sending "application/json" with the charset set to utf8 (as many examples say to do, although I've tried it all kinds of ways). I have used every option conceivable in jQuery - this is a problem with Spring.

So guys... are we supposed to do all this mapping ourselves? What if we are sending json data that is nested 2 or 3 times - do we manually traverse the "long[] ids" arrays and fetch everything ourselves? What if we have to do this for 100 controllers actions? My god, that is insane.

Now, I have tried to use GET instead of POST, even though POST is what I want. However, this causes all kinds of other problems with jQuery. For example,

{"activeQuestion":"551","categories":["129","129","128"],"categoryAnswers":["487","489","488"]}

You would think that this would transfer fine... but it doesn't. jQuery creates these GET Request headers:

?activeQuestion=551&
categories[]=129&
categories[]=128&
categoryAnswers[]=487&
categoryAnswers[]=488

As you can see, it doesn't put the indexes for the array notation, and it also chops out a duplicate. The only way to fix this via jQuery is to wrap the numbers in their own objects. Man, talk about bloated! That means we have to create bloated DTO objects that mirror the JSON data... and then convert to the "REAL" domain model afterward.

While this GET approach is slightly better because at least Spring does in fact do use the property editors... we still have to create a bunch of dummy objects that pollute the system for every controller action. Not to mention, we have to use GET for everything - even things that should be POST.

I will admit, maybe I don't know enough about Spring 3.0's new features and there is solutions around this stuff... but that only emphasizes the failure of your documentation then... as well as the failure in your "Spring 3.0 Simplications for Ajax" article, which doesn't talk about doing anything complicated.

And I'm just getting started... but it seems all Ajax examples in every framework - JavaScript or otherwise - just show really simple, easy examples. I guess they know their frameworks aren't up to snuff when it comes to something complex - like "a list of numbers".

Guys, why can't we just get this stuff to "Work"? :(

Thanks for listening. I apologize for venting, but I have went from YUI 3.0 -> jQuery... and now because of jQuery's poor API design as well as it's crappy .ajax implementation, I may have to try out Dojo to see if it's any better. YUI 3.0 is bloated beyond belief, it's ajax requests are 10x slower than jQuery's... and ultimately, the new sandbox model is terrible for trying to wrap YUI in an application core framework to make sure it doesn't get exposed to higher levels of the application-specific JavaScript.

It would seem that nobody has gotten this ajax stuff to work seamlessly. Yuck. No wonder I don't want to touch it. Now I have to.

Affects: 3.0.2

Issue Links:

#11397 MappingJacksonHttpMessageConverter's ObjectMapper does not use ConversionService when binding JSON to JavaBean properties ("duplicates")

#15394 Spring dependency injection for Jackson serializers

#16758 Support jackson mix-in classes in Jackson2ObjectMapperFactoryBean

#16918 Add serializerByType() deserializerByType() and mixIn() to Jackson2ObjectMapperBuilder

#11406 Spring MVC Binding Lifecycle differs between @RequestBody arguments and plain JavaBean arguments

7 votes, 12 watchers

Issue 2:
Paul Benedict opened SPR-3181 and commented

I have a custom instance of LocalizationContext and I'd like to use JstlUtils.exposeLocalizationContext to set it. However, the method accepts only a MessageSource. Let's refactor out this method:

public static void exposeLocalizationContext(HttpServletRequest request, LocalizationContext jstlContext);

Is this request in time for 2.0.3?

Affects: 2.0.2