CDI 2.0 (JSR365) Implementation for JSF 2.3 CDI Activation [SPR-17202]

[spring-projects-issues]

Ronel Manata opened SPR-17202 and commented

I require a way to properly implement @Inject @Push PushContext for <f:websocket> support (along with their WebsocketEvent listeners), but in their documentation, the only way for that to be properly implemented is for JSF 2.3 to be properly integrated because JSF manages these only by CDI 2.0.

However, in order to properly integrate JSF 2.3 (setting faces-config.xml version to 2.3), you need a BeanManager instance, which can only be achieved by properly implementing JSR365 (CDI 2.0).

The only alternative for me would be adding Weld (or OpenWebBeans) as a CDI, which can get ugly pretty fast without downright migrating.

PS: As for integrating CDI and JSR356, there should be no problem as Spring Websockets does implement JSR356 as far as I know.

PSS: I know the workaround here will only be to actually implement a websocket client within the xhtml file and bootstrapping WebSockets as normal, but that either defeats the purpose of JSF to a degree or requires a custom JSF tag to mimic f:websocket functionality.

---

No further details from SPR-17202

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid that this won't be happening, at least not as a full-scale CDI implementation.

They chose to base recent versions of JSF on CDI, for the flow scope as well as WebSocket support, with no proper SPI for those features but rather direct CDI dependencies within the JSF provider. We had a look at what it would take to implement CDI adaptation for flow-scoped beans a few years ago but it turned out to be impossible without a full CDI implementation (an intentional design decision by the JSF expert group, deeply baked into the Mojarra and MyFaces engines). And since CDI is really a complete framework with its very own rules, we can't simply adapt to it either (a design decision by the CDI expert group... which is why there are just Weld and OpenWebBeans as clean-room implementations but no existing DI frameworks implementing CDI).

What I would recommend for modern-day JSF is to take it as designed and use CDI with it for the immediate JSF managed bean layer, with a CDI-Spring bridge (there are several out there) connecting those user interface beans to Spring-managed services and repositories. Alternatively, even when going full scale on JSF-CDI, many parts of Spring can be used in a CDI environment without using a Spring application context (a design decision on our end: Spring components are as decoupled from the Spring container as possible, allowing for standalone use as well as use with other DI environments).