Menu
This question took off because I read Arjan Tijms blogpost about JSF 2.3. There, he list all JSF artifacts which can be injected via CDI. Although HttpServletRequest is mentioned, HttpServletResponse doesn't appear on the said list which I didn't believe at first.
To try things out, I setup a simple Server (JavaEE8, Wildfy22):
@Inject private HttpServletRequest req; works just fine@Inject private HttpServletResponse res; throws DeploymentException: WELD-001408: Unsatisfied dependencies for type HttpServletResponse
I don't see why HttpServletResponse should not be injectable. After all, the goal was to replace convulent method chains by a concise injection.
In case of HttpServletRequest, FacesContext.getCurrentInstance().getExternalContext().getRequest(); can now be shortened to the above injection.
Well, in case of HttpServletResponse, there is no injection candidate to replace FacesContext.getCurrentInstance().getExternalContext().getResponse(); as shown above.
Summarized: Why is HttpServletRequest injectable via CDI but HttpServletResponse isn't?
639
What is HttpServletRequest and It’s Methods? HttpServletRequest is an interface and extends the ServletRequest interface. By extending the ServletRequest this interface is able to allow request information for HTTP Servlets.
The ServletResponseis made available as a request-scoped bean. If the current request is an HTTP request, the produced bean is an HttpServletResponse. It can be injected safetly into any CDI bean as follows: @Injectprivate ServletResponse reponse; or, for HTTP requests @Injectprivate HttpServletResponse httpResponse;
To give you access to the request body of an HTTP POST request, you can obtain an InputStream pointing to the HTTP request body. Here is how it is done: HttpServletRequest interface provides a getSession () method, which returns the current session associated with this request, or if the request does not have a session, creates one.
The value of the specified request parameter is retrieved using the method ServletRequest.getParameter(String). It is then produced as a dependent-scoped bean of type String qualified @RequestParam.
There's not a single good answer here.
To start with, HttpServletRequest is produced by CDI, not Faces. As for HttpServletResponse I'm not sure why it wasn't original included in CDI, but I do know that all the Servlet artefacts should originally not have been provided by CDI.
Instead, CDI should have asked Servlet to provide "producers" for them (technically, build-in beans). Jakarta Transactions (JTA back then) did something similar)
Currently, CDI doesn't want to enhance or expand the Servlet artefacts, and with good reason. CDI is focussing on its core bean model and injection.
However, in Servlet there is a huge misunderstanding of what it means to provide producers. At least one person in Servlet thinks it's about providing integration points, or about Servlet having to become completely CDI based, or about Jetty having to support all 10 CDI implementations out there (there are only 2, but that aside).
This discussion has been going on for at least 8 years. Issues have been opened and closed again.
I'm a Servlet member myself so I hope I have some influence, but still have not been able to get this resolved.
We could alternatively have Faces provide HttpServletResponse, but Faces also does not own that type, and it would likely only contribute to the confusion.
167
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
