Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

spring-projects-issues opened this issue Aug 22, 2018 · 1 comment
in: core status: declined type: enhancement


Copy link

@spring-projects-issues spring-projects-issues commented Aug 22, 2018

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

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 22, 2018

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).

@spring-projects-issues spring-projects-issues added status: declined type: enhancement in: core labels Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core status: declined type: enhancement
None yet

No branches or pull requests

2 participants