HandlerAdapter + serving more than just Flex-based clients

[javaguy44]

Hi,

I'm currently doing a proof of concept converting my BlazeDS + Spring app(using Christophe's SpringFactory) into the spring-flex module. In this existing app, I access + use Spring Controller's using the ControllerClassNameHandlerMapping convention.

I've been following reference guide and have a couple issues / questions relating to this.

1. I tried to use the convention stated in ref guide, however this notation didn't receive request's from my Flex Client. See "doesn't work" below.

<flex:message-broker>
<flex:mapping pattern="/messagebroker/*" /> - ref guide ex doesn't work
<flex:mapping pattern="/amf" />
</flex:message-broker>

I did some debugging of the DispatcherServlet request, and the culprit was

UrlPathHelper.getPathWithinServletMapping(httpserv letrequest)

my web.xml servlet-mapping
<url-pattern>/messagebroker/*</url-pattern>

my channel definition in remoting-config.xml
<endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf" class="flex.messaging.endpoints.AMFEndpoint"/>

It appears the ref guide is incorrect but perhaps I am doing something wrong?



2. After integrating springflex, my Spring Controller's initially didn't receive requests. I got the following stacktrace:

javax.servlet.ServletException: No adapter for handler [webapp.controller.FileUploadController@135c592]: Does your handler implement a supported interface like Controller?
org.springframework.web.servlet.DispatcherServlet. getHandlerAdapter(DispatcherServlet.java:1100)
org.springframework.web.servlet.DispatcherServlet. doDispatch(DispatcherServlet.java:874)
org.springframework.web.servlet.DispatcherServlet. doService(DispatcherServlet.java:807)
org.springframework.web.servlet.FrameworkServlet.p rocessRequest(FrameworkServlet.java:571)
org.springframework.web.servlet.FrameworkServlet.d oPost(FrameworkServlet.java:511)
javax.servlet.http.HttpServlet.service(HttpServlet .java:710)
javax.servlet.http.HttpServlet.service(HttpServlet .java:803)

After debugging, I've found that:
a. when DispatcherServlet and invokes initHandlerAdapters, the MessageBrokerHandlerAdapter is detected. Consequently, none of the default HandlerAdapter's get loaded
b. My controller worked once I declared in dispatcher-servlet.xml <bean class="org.springframework.web.servlet.mvc. SimpleControllerHandlerAdapter"/ >


Will this always be required? It would be nice if:
- the default HandlerAdapter's in DispatcherServlet.properties were also loaded by default + the Framework were responsible as opposed to the developer user like myself having to declare all of them.
- Would also make things simpler for users when upgrading Spring in future releases.
- Also, I can't extend DispatcherServlet + override initHandlerAdapter in a nice way since it's private.

I can raise a jira issue for this if you wish / agree


I am using:
- BlazeDS turnkey 3.2.0.3978
- Spring 2.5.6
- SpringFlex 1.0.0 M2
- JDK 1.6.0_04
- XP
- FlexBuilder / SDK 3.2

Many thanks

[Marten Deinum]

The HandlerAdapter behavior is the behavior as it is inteded and as it has always been in Spring MVC. As soon as you override the defaults you will have to configure all the handlers yourself. The rational/idea behind this is that apparantly you want to influence/configure the behavior yourself. The same goes for HandlerMappings, ViewResolvers etc.

[javaguy44]

Hi Marten,

Yes I agreed what you are saying. Perhaps it wasn't clear -- I didn't override the defaults; the spring-flex module did. And as a result, I have to manually re-add the defaults in my appcontext if I want them, which I do not want to do. When the defaults change as new spring releases rollout, I don't want to keep checking DispatcherServlet.properties to re-add them etc. and I thought it would be best if the spring-flex module did this.

Thanks for the reply

[Marten Deinum]

Well as a good practice I think I would configure an additional DispatcherServlet. 1 for serving flex the other for serving the other resources. All the shared materials can be loaded with the ContextLoaderListener. That way you are also save for the future :).

[javaguy44]

Hi Marten,

Yes, I tried multiple DispatcherServlet's as well before I posted :-) But when DispatcherServlet is initialized, MessageBrokerHandlerAdapter will always be found in applicationcontext, and as a result default adapter's won't be loaded.

If you look at my original post:
After debugging, I've found that:
a. when DispatcherServlet and invokes initHandlerAdapters, the MessageBrokerHandlerAdapter is detected. Consequently, none of the default HandlerAdapter's get loaded

[Marten Deinum]

The DispatcherServlet will only find it if it is loaded into its OWN web application context. Multiple DispatcherServlets have different application contexts. So as long as 1 loads the flex stuff and another ONLY the plain mvc stuff there is no problem. They cannot see eachothers loaded beans, they only share the applicationcontext that is loaded by the ContextLoaderListener.

[javaguy44]

Of course it will work if running in separate web application contexts. But that would entail much work on my side + other spring-flex users who need beans across both appcontexts in terms of separating appcontexts appropriately, changing + fixing many many tests etc etc. It would definitely be a workaround by not a good way in terms of simple convention over configuration. As well I don't like the idea of running multiple web app contexts for 1 webapp...it certainly feels like a hack.

I would hope one of the mission statements of spring-flex + BlazeDS integration is to make life easier, not harder...

[javaguy44]

http://jira.springframework.org/browse/FLEX-34

[Marten Deinum]

You mentioned you already tried multiple DispatcherServlets so I don't see that concern you state. Also the different web application contexts only contain the explicit materials needed for that DispatcherServlet, your shared beans will still reside in the shared application context which should be loaded by the ContextLoaderListener...

But that is just me and as I recently read here on the forums my opinion doesn't count :)...

[bhorne]

I just ran into this same issue. I am prototyping a Flex client that connects to an existing Spring midtier. After working through several issues that were mainly due to my lack of Spring knowledge, I got the Flex client to successfully talk to the midtier. But then I discovered that the old clients no longer worked due to this issue.

In my case, I had to add this declaration:
<bean class="org.springframework.web.servlet.mvc.HttpRequestHan dlerAdapter"/>

Thanks for the post, and I agree this is a bug that should be fixed.

[sjlib]

I added <bean id="controllerHandlerAdapter" class="org.springframework.web.servlet.mvc.SimpleControll erHandlerAdapter"/>

and Spring MVC started working again. I'm not sure if this is in the Spring Blaze DS Integration docs, but if its not it should be.

Thanks.

[jeremyg484]

This is already fairly well spelled out in the Spring reference manual, but we will add more specific information in the BlazeDS Integration manual as well. See http://jira.springframework.org/browse/FLEX-53

[Celestemmcknight]

I tried that and this what I got -

This field cannot be modified as it is required for the application function.

So I think that means this is a required field for checking out, is there any way to do some voodoo magic to take this out?