Bauke Scholtz
Bauke Scholtz
I'm confused. I understood that `#{request}`, `#{session}` and `#{application}` are provided by Servlet API, not by Faces API. @arjantijms can you please clarify/confirm. As reference, this is mentioned in page...
Okay, summarized: CDI is basically responsible for `@Inject HttpServletRequest`, `@Inject HttpSession`, ` @Inject ServletContext` getting to work in managed beans. JSF (and thus not Servlet?) is basically responsible for virtually...
A real world use case / test case would be really helpful in order to understand what exactly needs to be done. Because, at the moment I'm really not seeing...
It's specified in [5.6.2.1. Implicit Objects for Facelets and Programmatic Access](https://jakarta.ee/specifications/faces/4.0/jakarta-faces-4.0#a2830) It's Object because Faces can run on Portlet instead of Servlet. HttpServletRequest would cause ClassCastException in Portlet where it's...
The main chapter is 5.6 CDI Integration. What you're requesting is unfortunately an incompatible spec change and this can't be done in a minor release 4.1. You as MyFaces might...
Yes move to 5.0 for now. The impl behavior wrt resolving of these things is also not yet verified by current TCK nonetheless so it's OK if MyFaces keeps using...
This is about SCIs coming from JEE spec. E.g. Faces, CDI, WebSocket. So there's a predefined set. User/3rd-party-library defined ones can safely be ignored because JEE impls usually won't depend...
Sorry I lost track of context. I actually meant that names like below, `Faces`, `CDI` and `WebSocket` can be predefined in JEE specs. The JEE impls won't care about user-defined...
> you seem to be saying that this annotation will only be used by JEE spec No. Only that the "web fragment" name such as "Faces", "CDI", "WebSocket" in above...
> but also says that these frameworks can instead be present inside the webapp, where they are subject to be excluded by ordering Yeah that's correct. But I was talking...