It seems to me that "session" scope is another means to keep objects in session as
using setAttrubute / getAttribute
Correct?
You know, dont know why, it does not work for me.
<bean id="sabreUser" class="util.MyUser" factory-method="getSomeUser" scope="session">
<const args...>
What I see is that after the initialization and initial deploy the MyUser properties are correct.
Then, in the first session I change MyUser property, the session is closed.
The second session runs and it sees the last set value from the previous session!
What does that mean?
I expect this object to be initialized whenever a new session starts. But it better looks as singleton, though you see - "session" attribute is set.
I can see the cause of the problem in that a Servlet's fields is initialized with #Autowired
so, once it is initialized, every other session will see its fields set and does not "ReWire" this properties. It happens once? How to overcome this problem?
The Spring session does not exactly match the HttpSession, and even the Spring documentation on the #SessionAttributes annotation says that it might be stored in the session or "some conversational storage". I got that from The Spring docs for 2.5
I've basically quit trying to make sense of it, and just got on with my life, if I want something stored in the HttpSession, I just have Spring inject the HttpSession to me, assuming you're using Spring MVC its pretty easy, instructions on the same page.
Session-scoped beans are beans that live throughout the http session. They are stored in the session via setAttribute in some way.
So - yes.
Session scoped beans are stored in Http Session by Spring framework. This scope is valid only in the context of Web application.It also works for Portlet envionments . When using in Portlet environment, there are two notions of session, application scope and portlet scope (default).
Related
I have created a Web-Application that shows documents to the user.
The application uses RESTFUL Webservices to get this documents from the backend.
The EJB responsible for creating / loading the documents needs some information stored in the http session.
(There was a requirement to determine how long a document has been openend, how long loading took etc., there is data stored in the session to determine which document in which browser window was closed or updated)
My solutions to get this informations looks like this (in the SSB and an Interceptor for another SSB):
#Context
private HttpServletRequest request;
...
this.request.getSession().getAttribute(WINDOW_SET);
This solution is working.
I am not sure this is the "right way" to do it, since #Context is not really meant for use in an EJB as far as I researched until now.
I can not just pass the needed information to the EJB as an argument, since this would not work with the Interceptor used.
The question is:
Is this a valid way to build this functionality?
If not, what are the drawbacks of this solution and how could it be done better?
No. The bean is annotated as stateless: it must be stateless. You can't expect injection of the request or the session to even work.
What a 'stateless session bean' actually means is another question, and one which I've been pondering since about 1998.
I have some bussines classes that get injected some dependencies that are provided using servlet request scope.
The problem is that I want to use that bussines classes in some threads that outlive the servlet request.
Whats the most transparent way to do that?
If you are using Spring (which, by the terms you use to describe your problem, you seem to be using), you can use an AOP scoped-proxy for your request-scoped object, and inject this proxy into the objects that outlive the servlet request. The scoped-proxy will take care of using the right instance everytime you access it.
Well,
I'm not sure if I get your problem. I think there is problem with architecture itself, but however this could help you:
Guice module
bind(Bussines.class).annotatedWith(Names.named("request")).to(Bussines.class).in(RequestScoped.class);
bind(Bussines.class).annotatedWith(Names.named("session")).to(Bussines.class).in(SessionScoped.class);
bind(Bussines.class).annotatedWith(Names.named("application")).to(Bussines.class).asEagerSingleton();
Usage
#Inject #Named("request")
private Bussines bussines; //inject a new bussines class every request
#Inject #Named("session")
private Bussines bussines; //inject a new bussines class each session
//This is little bit tricky, cuz Bussines is stored in session. In Stage.PRODUCTION are all injection created eagerly and there is no session at injection time. Session binding should be done in lazy way - inject provider and call bussinesProvider.get() when em is needed;
#Inject #Named("application")
private Bussines bussines; //inject singleton
Also you can use Private modules to bind different scoped objects to a class. Don't forget to expose it.
I see 3 options:
You could add the information you need to an object that has a larger scope like application or session scope
You could persist the information in a file or the database and look it up later
You could save the information on the thread or use a thread scope: http://code.google.com/p/google-guice/issues/detail?id=114
I may not suggest you directly use or inject HttpServletRequest at business bean which is not in request scope . because this will break up app layers. if you want the value from the request or request header, then you can pass value to object to pass to the business layer, because otherwise, it is not secure, and generally, app will apply some security interceptor at that request scope , but if you directly inject to other layer , then it jump over and the interceptor may be skipped... this way also break the encapsulation and obvious is anti-pattern.
I would like to delete some temporal files when user session finishes. The information associated with the files is stored in an object annotated with #SessionAttributes.
The only way I've found to deal with this is creating an HttpSessionListener.
Is there a higher level, simplified, Springy way to listen to the session end event where I could easily get my annotated object?
You most likely will need to create a HttpSessionListener.
Another stackoverflow answer:
Detect session timeout in Spring 3/Spring Security 2.0.5
Also and example on how to load spring beans into it:
http://www.mkyong.com/spring/spring-how-to-do-dependency-injection-in-your-session-listener/
Two options to use HttpSessionListener with spring beans:
The first is to use WebApplicationContextUtils.getRequiredApplicationContext(servletContext) to obtain the servlet context. From there you have two sub-options:
use getBean(..)
If you want to use #Autowired / #Inject use getAutowireCapablyBeanFactory().autowireBean(this). You will have to do this only once (check if the fields are null), because the listener is singleton.
The second option is to use AspectJ and #Configurable on the listener.
Not directly related, but might be an interesting project to look at.
https://github.com/shawnmclean/Idle.js
Session deletion typically happens on the server side, when the session expires (usually 30mn). The project above allows to detect user behaviors in the front end.
Since I don't have in depth knowledge of spring session scope implementation.
Can anyone please tell me if it is wise to use Spring Session scoped beans, where HttpSession object is very crucial. Like a web application where thousands of users access the site simultaneously.
Is spring session scoped bean saved in HttpSession object?
Or even if HttpSession object only refers to the spring session scoped bean, are we not making session object heavy?
How is it different form storing any bean directly in HttpSession object (making HttpSession object heavy point of view)?
The object is not really stored in HTTP session. It is linked with session id and actually stored inside of the Spring context. A session listener is used to clean instances once session is closed. See SessionScope JavaDoc.
Here's what the Spring docs say:
Scopes a single bean definition to the lifecycle of a HTTP Session.
Only valid in the context of a web-aware Spring ApplicationContext.
"Heavy"? No heavier than the object you're putting in it. Sessions should have a finite lifetime. A few kbytes per session won't be the end of your application. A simple calculation for the number of simultaneous sessions and object memory requirements should reassure you about your app server memory settings. You can always increase min and max memory if needed.
Storing things in HTTP session happens the same whether you're a Spring bean or not. The bean factory just does some extra things to help manage the object lifecycle for you.
Is spring session scoped bean saved in HttpSession object?
If the HttpSession object you mentioned here is actually provided by spring-session (spring-session wraps the httpSession object in original httpRequest), the answer would be YES -> indeed, all the spring session scoped beans are saved in the httpSession provided by spring-session as attributes.
Or even if HttpSession object only refers to the spring session scoped bean, are we not making session object heavy?
No. The "heaviness" of the httpSession very much depends on the objects you put in. In addtion, session beans are meant to be ephemeral. Last but not least, the session object in micro-services world is usually offload to a stand-alone store, like Redis or HazelCast. So, it won't be considered as "heavy" in terms of memory consumption.
How is it different form storing any bean directly in HttpSession object (making HttpSession object heavy point of view)?
No difference at all (assuming you are using spring-sesion), as all the all the spring session scoped beans are saved in the httpSession provided by spring-session as attributes.
What's the recommended approach to intercepting session.getAttribute() and session.setAttribute()? This is in a Spring based application so something AOP-based would be great. I'd like to avoid having to override core Tomcat classes if possible.
Update: I want to store the actual serialized attributes in a web service.
I am not familiar with AOP or Spring (or Tomcat). :) But I am familliar with Java
The way I do it is set up a filter, and replace the request variable with my own object
request = new MyRequest(request);
Then override getSession() and getSession(boolean) to return an instance of MySession
the javax.servlet.HttpServletRequest and javax.servlet.HttpSession classes are Java EE standard and not Tomcat specific.
You could implement your own session org.apache.catalina.Manager and swap it into Tomcat's configuration, although the interface looks rather lengthy - so perhaps look at extending ManagerBase or StandardManager first.
As an alternative, register a HttpSessionAttributeListener to be notified whenever a session attribute is added/removed/updated. This won't change the default storage mechanism - the session data will still be kept in-memory as well - but it would let you persist the data with an alternative mechanism as well.