Spring MVC - Can I autowire HttpServletRequest in RestController - spring-mvc

Can I autowire HttpServletRequest in my RestController like following and will it returns different servletRequest even if it is executed in highly concurrent environment. I have a restriction that I can not have as method parameter because I am implementing an interface which is auto generated and will not have HttpServletRequest as the method parameter.
#RestController
public class MyController implements MyInterface {
#Autowired
private HttpServletRequest servletRequest;
#Override
#RequestMapping(value = "/test", produces = {"application/json"}, consumes = {"application/json"}, method = RequestMethod.POST)
public ResponseEntity<MyResponse> test(#RequestBody final MyRequest payload){
...
}
...
}
I have gone through these SO questions and some other articles on this. But just wanted to ensure that when we autowire HttpServletRequest in the controller then its Scope is Request?
Spring 3 MVC accessing HttpRequest from controller
How are Threads allocated to handle Servlet request?
Scope of a Spring-Controller and its instance-variables
How do I get a HttpServletRequest in my spring beans?
How To Get HTTP Request Header In Java
Note: I did try this and it seems to work fine. But just wanted to confirm that it's a foolproof solution even in a highly concurrent environment.
Also if this is the correct way to do it, I would appreciate if someone can explain how exactly it works.

I have used this and it works fine. But unfortunately I did not find any official documentation which mentions that this should work.
Here is the explanation based on my understanding from debugging the code with running multiple requests with different headers/payload etc.:
Whether we autowire on field or through the constructor, servletRequest acts like a Proxy object which delegates the call to Current HttpServletRequest which is different for each request. Thus, even though it's injected through constructor in a Singleton RestController, it will still have the call delegated to corresponding HttpServletRequest for each new request. This utilizes AutowireUtils.ObjectFactoryDelegatingInvocationHandler to access the current HttpServletRequest object. The java doc for it also says Reflective InvocationHandler for lazy access to the current target object.
Thus even if the autowired Proxy object is always the same for all requests, the underlying target object to which the call is delegated is the current HttpServletRequest object which is per-request.
There is another way you can get HttpServletRequest is using RequestContextHolder as mentioned in this answer
HttpServletRequest currentRequest =
((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes())
.getRequest();
Note: As this explanation is based on my understanding, please do share any official documentation about this if anyone has it.

Related

Passing cookies from jax-rx rest api end point to ejb

I am looking for a solution related to passing cookies values from JAX-RX REST API endpoint to ejb layer.
I tried searching the solution and found some of them are using thread local. but and thread local supposed to be not working with executor services.
Is there any another solution that I can use to pass cookies values from web/rest later to ejb layer.
Note: I do not want to pass it as method parameter from rest layer to down the ejb layer. I would like to access the cookies values directly in ejb layer
Thanks
Lets say you have a class MyEJB, you can inject HttpServletRequest object to you ejb as follows:
public class MyEJB{
#Context
private HttpServletRequest httpRequest;
}
Now from this request object you can access your required cookies. As follows:
String rawCookie = request.getHeader("Cookie");
String[] rawCookieParams = rawCookie.split(";");
for(String rawCookieNameAndValue :rawCookieParams)
{
String[] rawCookieNameAndValuePair = rawCookieNameAndValue.split("=");
}

SessionAware design in Struts 2

I have been working with Struts 2 for a long time.
In case of implementing SessionAware interface to our action class we will get SessionMap but not HttpSession object.
In case of ServletRequestAware and ServletResposeAware we get HttpServletRequest and HttpServletResponse object but not wrapper objects like SessionMap in case of SessionAware.
My question is, if Struts is giving us SessionMap instead of HttpSession to decouple our action classes from Servlet API and Http protocol,then why it is giving us HttpServletRequest and HttpServletResponse objects in case ServletRequestAware and ServletResponseAware.
If Struts doesn't want to decouple Servlet API and HTTP protocol from the action classes then why it is giving us SessionMap in case of SessionAware interface.
Why we don't get HttpSession object?
In case of ServlectRequestAware and ServletResposeAware we get HttpServletRequest and HttpServletRespose object but not wrapper objects like SessionMap in case of SessionAware.
Because those directly expose the servlet request and response on rare occasions where they're actually necessary (or at least useful).
My question is, if struts is giving us SessionMap instead of HttpSession to decouple our action classes from Servlet API and Http protocol,then why it is giving us HttpServletRequest and HttpServletRespose objects in case ServlectRequestAware and ServletResposeAware.
Because it's much less likely you'd specifically need an HttpSession than the actual request or response.
If struts don't want to decouple Servlet API and HTTP protocol from the action classes then why it is giving us SessionMap in case of SessionAware interface.
It does want to decouple the Servlet API, for good reasons. It forces you to explicitly ask for Servlet API artifacts because they're a code smell. It doesn't prevent you from getting them because on rare occasions they're important.
An HttpSession is pretty much just an attribute map, it doesn't contain information generally useful in an action. On the even-rarer occasions you need one you can still get it.
Why we don't get HttpSession object?
You can get this object from the servlet's HTTP request. No reason to define additional interface to inject the HttpSession into the action. On the other hand Struts defines maps for HTTP request, session, application for easier access/modify its attributes using a Map interface. The servletConfig interceptor can inject these objects to the action if it implements corresponding xxxAware interface.
The list of interfaces that could be injected by this interceptor:
ServletContextAware
ServletRequestAware
ServletResponseAware
ParameterAware
RequestAware
SessionAware
ApplicationAware
PrincipalAware

Is there a way to access HTTP headers in a Java EE interceptor?

I have a JSP page that invokes an EJB method and I am using a Java EE interceptor for the EJB method. So the method checkHeaders of the interceptor will be executed before the EJB method
My question is: How can I access the HTTP headers in the interceptor method?
My application is running in JBOSS 6.1
// interceptor class
#AroundInvoke
public Object checkHeaders(InvocationContext invocationContext)
throws Exception {
// I need something here to access the HTTP headers:
invocationContext.getHTTPHeaders();
.....
//do something with the headers
//continue execution
invocationContext.proceed();
Thanks!
There is not way to access some HTTP request specific attributes in service layer (i.e. in EJB) until you explicitly pass them to EJB method. So if you really need it, you can add extra parameter to your EJB method, like List<String> headers or Map<String, String> headers and read parameter value in your interceptor:
public Object checkHeaders(InvocationContext context) throws
Exception{
if (ctx.getMethod().getName().equals("yourTargetMethod")) {
// assume your 'headers' parameter is first method param
List<String> headers = (List<String>) ctx.getParameters()[0]);
}
}
You can't access the HTTP headers from and EJB Interceptor because the EJB container is independent of the web tier. You would either pass the headers into your EJB method call and check them as part of its business logic or perform the check in the JSP/web tier. I would go with the latter since you won't be leaking web concerns / dependencies into your business/EJB tier.

When, exactly, #Inject annotation initiates injection of SessionScoped bean in Servlet?

I need to modify a user session object (SessionScoped bean - CDI) in a Servlet, so I have to obtain that bean somehow. I used injection in the following way:
#Inject
private UserSession user;
where UserSession is the SessionScoped CDI bean. user methods are called from either doPost or doGet servlet methods.
This works perfectly; every time the #Inject annotation injects the appropriate UserSession bean, but I don't understand how this behavior is achieved.
I assumed that the beans, annotated with #Inject, are injected only once (when the object - Servlet instance in this case - is created), but it is obviously a wrong presumption.
So, when are these beans injected into the servlet? Per request? And how does this approach avoids conflicts (one servlet instance - multiple threads to deal with it) when there are multiple UserSession objects?
The CDI uses the proxy pattern. The injected instance is actually not the real instance, but a proxy which locates the real instance depending on the current context and delegates all methods to it (like as how EJBs work). The autogenerated class of your UserSession bean looks roughly like this:
public UserSessionCDIProxy extends UserSession implements Serializable {
public String getSomeProperty() {
UserSession instance = CDI.resolveItSomehow();
return instance.getSomeProperty();
}
public void setSomeProperty(String someProperty) {
UserSession instance = CDI.resolveItSomehow();
instance.setSomeProperty(someProperty);
}
}
This mechanism allows you to inject instances of a narrower scope in instances of a broader scope and allows you to still get the expected instance in the current context. The standard JSF #ManagedProperty annotation doesn't support it, simply because it does not use a proxy, but injects the desired instance directly. That's why it's not possible to inject something of a narrower scope by #ManagedProperty.
See also:
Backing beans (#ManagedBean) or CDI Beans (#Named)?
Get JSF managed bean by name in any Servlet related class
When using #EJB, does each managed bean get its own #EJB instance?
How to choose the right bean scope?
Your answer lies in the C of CDI, which stands for Contexts.
What happens is that not the actual bean is injected, but a proxy. This proxy is contextual and resolves to the actual session scoped bean depending on the context of the caller on who's behalf the proxy is executed.

How do I get Web.xml context-param values in controller action method?

This feels like a basic question, but I haven't had much luck Googling.
My app connects to an SMTP server and sends mail through it. I need this SMTP server to be configurable based on which environment the app is deployed to.
How can I specify the specify the SMTP server name in my web.xml config file and access it from my Spring MVC 3.0 controller?
The controller does not extend or implement anything. It is completely annotation driven with #Controller and #RequestMapping. From what I have seen online, people access context-params via the servlet API. Being annotation driven, I do not have access to the servlet object.
I solved this.
Make your controller implement ServletContextAware, which requires a method called
setServletContext(ServletContext servletContext)
Spring MVC will inject the servlet context into this method if your controller is ServletContextAware.
Create a private variable on your controller to store the servletController that is injected into the above method. You can now use servletContext just as you would if you were using a regular servlet.
hth.
Adding an instance of Servletcontext and autowiring it worked for me
#Controller
public MyController {
// other instances relevant to your requirement
#Autowired
private ServletContext sCtx;
//other methods relevant to your requirement
}
I suppose following also should work:
void action(final HttpServletRequest request) {
final paramValue = request.getSession().getServletContext().getInitParameter("paramName");
...
}

Resources