support spring-core websocket/stomp/sock.js stack

[zyro23]

its just a matter of time when spring-4 will be ga and then make it - someday ;) - into grails-core.

it would be really nice if then, events-push would support spring-4's built-in websocket/stomp/sock.js based stack.

just gave it a whirl with spring-boot and gotta say - does feel clean. as i understand, reactor integration (poking grails-events here) is also getting attention / will be supported.

[smaldini]

Agree, I look forward to seeing what we can do here. In fact it would rather require decoupling events-push from atmosphere, hence why I plan to rename to events-atmosphere. But the conventions could remain. Might require some help here if you want to pursue the discussion offline ping me :D

[zyro23]

a first step could/should be a grails plugin that just makes the spring-websocket stack useable in a grails-app. thinking of sth like

• leverage @EnableWebSocketMessageBroker
• see how everything fits in with urlMappings and the grailsDispatcherServlet
• make @MessageMapping, @sendto, etc. compatible with grails controllers

much like other plugins that do "just" provide integration with another spring-framework component

event/reactor/etc. integration on top of that would be a step 2 imho?

maybe i can come up with sth in the next two days or so, ill let you know.

[zyro23]

you could risk a look ;)

• https://github.com/zyro23/grails-spring-websocket
• https://github.com/zyro23/grails-spring-websocket-sample

its just a first "it does work" proof. not tested spring-security integration etc. yet but i think the sample shows that once the plugin reaches a useable state, there is almost everything we need right inside spring-core by now.

given we are somewhat at the bleeding edge here, app and plugin are using grails-2.4.0.BUILD-SNAPSHOT, spring-4.0.0-RC1, grails-tomcat8-8.0.0-RC5 ...

[smaldini]

That's awesome, much more readable API and there is Stomp, which is
awesome... I think we could continue that route, all we would need would be
an integration with grails-events (for common semantic).

On Mon, Nov 18, 2013 at 5:06 PM, zyro [email protected] wrote:

you could risk a look ;)

• https://github.com/zyro23/grails-spring-websocket
• https://github.com/zyro23/grails-spring-websocket-sample

its just a first "it does work" proof. not tested spring-security
integration etc. yet but i think the sample shows that once the plugin
reaches a useable state, there is almost everything we need right inside
spring-core by now.

given we are somewhat at the bleeding edge here, app and plugin are using
grails-2.4.0.BUILD-SNAPSHOT, spring-4.0.0-RC1, grails-tomcat8-8.0.0-RC5 ...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/50#issuecomment-28716773
.

Stéphane

[zyro23]

up until now i was keeping the spring-websocket plugin in sync with the (often breaking) spring core api changes. now, with spring-4.0.0.RELEASE, my current focus is to get a stable M1 out once grails-2.4-M1 hits the floor.

however, i am intentionally limiting functionality to plain spring-core adaptation, i.e. use the spring-core websocket support in grails controllers (with springs annotations).

other goodies like a dsl/security integration/etc. --> thats where i see events/-push/etc. joining the picture. i have already some ideas in mind regarding mapping the dynamic methods, adapting browserFilter, etc...

however given the broad range of new possibilities and options (not only event-handling...), i am still struggling to get a clear view of a healthy future plugin landscape/stack regarding websockets in my head.

one approach could be:

• grails-events (dep. reactor)
  • grails-events-push("-atmosphere") (dep. grails-events/atmosphere)
  • grails-events-push-spring (dep. grails-events/grails-spring-websocket)
• grails-spring-websocket (dep. spring-messaging/spring-websocket)

or, as you already suggested, decoupling events-push:

• grails-events (dep. reactor)
  • grails-events-push (dep. grails-events)
    • grails-events-push("-atmosphere") (dep. grails-events-push/atmosphere)
    • grails-events-push-spring (dep. grails-events-push/grails-spring-websocket)
• grails-spring-websocket (dep. spring-messaging/spring-websocket)

with both options, the respective push plugin can take care of the specifics of its supported push-implementation and there would still be room in grails-spring-websocket for further grails websocket support (controller-actions/url-mappings/etc.)

i think a clear picture of that target inter-plugin-arch is a prerequisite for further activities like branching, repo creation, concrete idea generation and so on?