I am experiencing a weird issue using spring mvc and session items.
We have a controller class annotated as follows:
#SessionAttributes({"customerPosition"})
according to the Spring doc, if I put into the model an object with the key customerPosition it gets automatically put into the session.
When I "manually" set the item with session.setAttribute("customerPosition",customerPosition) I exepect the item to be saved in session. if I get this item from the session by means of session.getAttribute("customerPosition") I get a different Item, not the one I expect. Actually what I get is data from previous iterations of the software flow.
It looks like that session.setAttribute("customerPosition",customerPosition) is not overwriting the object in session.
Does using #SessionAttributes prevents the possibility to manually control the session by means of session.setAttribute("customerPosition", customerPosition)
Related
I'm having a hard time figuring out a specific time in which one would use #SessionAttribute over #ModelAttribute.
This question arose because after making a web application I realised that I have got a lot of methods that I passed in Principal principal to. In these methods, I use principal.getName() to get the username of the logged-in user and then retrieve the relevant data from the database using that username. In short, a lot of my methods needed access to the current user data and I resolved this in what I believe to be an inefficient manner.
To rectify this I was going to create a model attribute in a class annotated with #ControllerAdvice, in which I get the principal and get the user data from the database and add it to the model.
E.g model.addAttribute("currentUser", currentUser);
so that in the parameter list of these methods I can have (#ModelAttribute("currentUser") UserAccount currentUser)
saving unnecessary work by getting the principal and then proceeding to get the user from the database.
While I don't know a whole lot about #SessionAttribute, I feel like this sort of data(UserAccount currentUser) is more relevant to the session as opposed to the model. Am I Wrong?
I also heard that #SessionAttribute doesn't make its data available across multiple controllers which in this case I need. Hence why I'm using #ControllerAdvice.
My questions are as follows:
What is the best practice for implementing the above where I need to
repeatedly access the current users data. Maybe I can further increase efficiency by adding a current user bean on login and then use #Autowired so that I wouldn't even need to have currentUser in the parameter list. But I don't know if that's even possible. Is it?
Is it true that the method annotated with #ModelAttribute is called
prior to every #RequestMapping, #GetMapping, #PostMapping etc. call?
and that an object specific to #SessionAttribute remains in the
model for the duration of the session?
Also In what situation should I user #SessionAttribute over
#ModelAttribute?
The #SessionAttrributes annotation is for the use-case where you need to have a model attribute that you need to access over multiple screens. Like doing a checkout for a shopping cart, you would store the Order in the session, screen 1, confirm, screen 2 payment details, screen 3, delivery details, screen 4 OK. After screen 4 you would then call SessionStatus.setComplete() and it will clean that attribute.
That is the use case for #SessionAttributes and should be used in conjunction with #ModelAttribute. It is not intended to be used to store a, for instance, the user in the session for the duration of the HttpSession.
The #SessionAttribute (a different annotation!) is to retrieve an attribute from the HttpSession that was placed there earlier. In your case after authentication, you would place the User in the HttpSession with HttpSession.setAttribute("currentUser", user);. In a controller method, you could use #SessionAttribute("currentUser") User user to retrieve and use it. No need for an #ControllerAdvice or model attribute anymore.
However I would strongly to ditch your custom security implementation and use something like Spring Security instead. That way all that, and more, is already provided out of the box. In a controller method you can then use the #AuthenticationPrincipal annotation to retrieve the current user.
I'm using the #Scope annotation with value of "request".
How do I check if the given object with the "Scope" annotation is instantiated on each http request ?
Do the object (bean) have some identifier (hashcode ) ? And, I don't mean the bean id.
System.identityHashCode(theBeanVariable)
Print the hashes and check the objects are the same or not.
You gotta believe!
No, I'm kidding. Methods I used so far:
In eclipse if you stop application on a breakpoint you can check the id of every object in Variables tab. Every new instance of object has new id. You probably can find a place in your code that is executed after every (or some) request.
If you can set some fields of this bean via a web page, go and do it and then open the same page in new tab in your web browser. If request scope is working, fields you set should have old values (the one that are set on creation of object).
Maybe these are not uber-pro methods, but may be enough in some cases and you don't have to add anything in your code.
I have a page with a dataTable, which is populated based on the query parameters (e.g., username and pagenum). Each entry in the table has a delete commandButton
When the pagenum != 0 and we click delete, the list of records to display is generated during the "apply" phase. During this phase the view parameters have not been set, so the list of records is empty so nothing get's deleted (our delete method doesn't get called)
To work around this I've added a #PostConstruct method that retrieves the query parameters from the Servlet request and sets the values in the bean, so they are available when we get the list of away records, which allows my delete method to be called.
I'm certain that JSF has a better way of handling this scenario and the #PostConstruct work around is a hack.
What is the correct way to implement this scenario, without resorting to a View or Session scoped bean?
Surely there must be a way to just POST the form and delete the appropriate record without having to waste time regenerating the list of records.
What is the correct way to implement this scenario, without resorting to a View or Session scoped bean? Surely there must be a way to just POST the form and delete the appropriate record without having to waste time regenerating the list of records
Sorry, there's no way. At least not when using a standard <h:commandButton> inside a standard <h:dataTable>. This is the consequence of the stateful nature of JSF. JSF just wants to ensure that the view is exactly the same during processing the postback as it was during generating the HTML output.
This is part of JSF's safeguard against tampered requests wherein the enduser/hacker can manipulate the request parameters in such way that it could do hazardful things, e.g. changing the ID of entry to delete, or bypassing the check on rendered attribute, etc. All those things on which you would/should do additional pre-validation anyway if JSF didn't do that for you and are easily overlooked by starters (they would then blame JSF for being insecure instead of themselves). See also Why JSF saves the state of UI components on server? and commandButton/commandLink/ajax action/listener method not invoked or input value not updated.
In case of <h:commandButton> inside <h:dataTable>, JSF simply needs to have the data model available during the apply request values phase, so that it can iterate over the <h:dataTable> in the component tree in order to find the pressed button and queue the action event. If there's no datamodel, then it can't find the pressed button and the action event won't be queued. Normally, this is to be solved by placing the managed bean in the JSF view scope. See also How to choose the right bean scope?
In case of request scoped beans, the <f:viewParam> is indeed not the right tool for the job of preserving the data model before apply request values phase takes place. You need to do the job in a #PostConstruct annotated method instead. The request parameters can in case of JSF managed beans be injected via #ManagedProperty. See also ViewParam vs #ManagedProperty(value = "#{param.id}"). In case of CDI or Spring managed beans, there's no standard annotation available to inject a HTTP request parameter as a bean property. For CDI, the JSF utility library OmniFaces has a #Param for the very purpose. See also OmniFaces #Param showcase. For Spring, you'd need to homegrow it yourself. I, as non-Spring-user have however no idea how to do that. Google also doesn't seem to reveal much.
Alternatively, you can also just put the bean in the view scope by #ViewScoped. It'll then live as long as you postback to the same view. JSF 2.2 has a CDI compatible annotation for that in javax.faces.view package. The one in javax.faces.bean package is the old JSF 2.0/2.1 annotation for #ManagedBean. Spring has no annotation out the box for this as that would otherwise put a dependency on JSF API. You'd need to homegrow it yourself. Google shows several examples.
What is the correct way to implement this scenario
Before executing the any logic on the backing bean, JSF always have to rebuild the view in order to get information about what to execute. For displaying and updating purpose, the best (and correct) solution is certainly the #ViewScoped.
without resorting to a View or Session scoped bean?
If you insist on using #RequestScoped, I'd say there're no correct ways but work-arounds or hacks. One way is to initialise the list in a #PostConstruct method like you've mentioned. Another way may be to use a JavaScript function for the onclick attribute of your delete button. The JS function, for example, will make a call to the server using a URL to request a delete. Or else, you can also use PrimeFace's RemoteCommand for the JS function.
I am trying to share data between two controllers in a Spring mvc application.
In Controller A I have annotated the class with #SessionAttributes({"mymodel1"}) and in the method which receives the first GET request I add it to the ModelMap:
model.addAttribute("mymodel1", MyModel1);
I now want to read myModel1 from Controller B.
In this Controller I have the following method which intercepts the POST requests and already has a different model in its parameters:
public String processSubmit(#ModelAttribute("mymodel2") MyModel2 mymodel2, BindingResult result, SessionStatus status, HttpServletRequest httpRequest)
Up to this point everything works fine and I am able to read mymodel2 from processSubmit however if I now want to add another #ModelAttribute("mymodel1") MyModel1 mymodel1 to this method signature I would have expected to be able to read the value I was setting in Controller A however I'm getting exceptions that the first model is no longer recognised.
So my question is: how can I read mymodel2 from Controller B?
You can't do that with #SessionAttributes :
Session attributes as indicated using this annotation correspond to a specific handlers model attributes, getting transparently stored in a conversational session. Those attributes will be removed once the handler indicates completion of its conversational session. Therefore, use this facility for such conversational attributes which are supposed to be stored in the session temporarily during the course of a specific handlers conversation.
For example I use this annotation when I want to validate elements with Hibernate validation, and after I submit the page and SOME elements are invalid I want the rest to be still on the page, but this is not your case. I think that the only way to do it would be with:
HttpSession.getAttribute()
The javadoc excerpt above is the most typical way #SessionAttributes is used. However, what Joly is describing should also work. Session attributes are stored via DefaultSessionAttributeStore, which by default does not prefix attribute names when it stores them in the session. That means if ControllerA and ControllerB both list an attribute called "mymodel1", they're actually referring to the same session attribute. You'll need to provide a little more information on the error you're getting and the actual controller code.
I am working on a java MVC project. Currently i've a login.jsp, profile.jsp, ``CheckLogin servlet, User.java bean class and UserDAO dao class (the beans and jsp's and all other things are to be added also).
What i am currently doing here whenever the user gets logged in successfully it is redirected to the profile page which shows all the details of user.
My question here is:
Is it better to set a User type object for particular userID in the session object that prevails in whole session and retrieve all values directly as ${sessionScope.user.property} everywhere?
or
Is it better to set just a userID in the session object that prevails in whole session and retrieve the values in all pages using these lines of code :
<jsp:useBean id="userDAO" scope="page" type="com.project.dao.UserDAO" />
<c:set var="user" value="<%= userDAO.getUser(%>${sessionScope.userID}<%) %>" />
${user.property}
I hope i am clear to you in my question.
Please suggest me.
First rule: avoid scriptlets. The fact that you have no other solution than scriptlets shows a design problem. The controller should prepare the model for the view. The view should not call DAOs directly. That's the responsibility of the controller.
Now, storing the user in the session or loading it at each request (from the controller) is a matter of performance and stale data.
If the user only contains data that won't change through the whole session (or that could change, but only from this session, allowing to refresh the data when needed), then store it in the session. That's its goal: store data that have a session scope.
If there might be some external session or process modifying the data of the user, and you want to make sure you always display the freshest data, then reload it at every request.