Background
The application I am working on currently uses Spring + JPA. Everything was working fine before we decided to introduce DWR.
Using DWR I invoke a method on a Service class and it then redirects to the Controller.
try{
return WebContextFactory.get()
.forwardToString("/search.do?searchString=" + searchString);
}catch(...){
}
After this, when the search method is invoked at the DAO, it does not find an pen session.
Session session = (Session) entityManager.getDelegate();
This session here is closed...
I think my changes(of introducing DWR) should not in any way affect the Session creation.
Awaiting inputs.
Shardul.
Issue resolved.
The problem was with the configuration of OpenEntityManagerInViewFilter in the web.xml. It was not intercepting the DWR requests as it was mapped to a
*.do
instead of
/*
Shardul.
Related
I am trying to switch my http session to redis in my spring boot application.
When the first request comes to backend it's being filtered by authentication filter.
One duty of this filter is to populate user session bean with data. The session is succesfully saved to the redis instance at this step, but the delta of changes ( which should include the session bean) is not invoked. I want to point out that with storing session on tomcat the session beans work correctly.
So why session bean populated on OnePerRequest filter is not updated as the delta of session ?
Have you tried the below configuration?
#Configuration
#EnableRedisHttpSession(saveMode = SaveMode.ALWAYS)
public class RedisSessionConfig {
}
Try changing the flush mode to IMMEDIATE, by default it's ON_SAVE which means you explicitly have to save the session or in a managed environment, it happens before the response is serialized (I think).
In src/main/resources/application.properties you could do:
spring.session.redis.flush-mode=immediate
Or using #EnableRedisHttpSession do:
#EnableRedisHttpSession(redisFlushMode = RedisFlushMode.IMMEDIATE)
I wanted to perform some clean-up activity during Spring Session destroy (logout and timeout) and tried following the solution provided at this thread
but what made me curious is that, my application is a Spring Boot application and I didn't have to register the HttpSessionEventPublisher Listener , i just implemented the ApplicationListener interface and used the onApplicationEvent() method to capture the SessionDestroyEvent.
My question is, How did my code work without registering this listener
?
here is the answer from the Spring Session documentation itself
http://docs.spring.io/spring-session/docs/current/reference/html5/#api-redisoperationssessionrepository-sessiondestroyedevent
If you are using #EnableRedisHttpSession the SessionMessageListener and enabling the necessary Redis Keyspace events is done automatically. <<
I use to hibernate before and I require an opensession to use Hibernate.Initialize()
but apparently for Spring, if OpenSessionInViewInterceptor is set up properly, it can use Hibernate.Initialize() anywhere.
My question is, what must I setup to use Hibernate.Initialize() in JUnit?
The whole point of OpenSessionInViewInterceptor is precisely to leave the Hibernate session open until the view has been rendered. This is why you can call Hibernate.initialize() "anywhere": Spring doesn't close the session until the request has been completely handled by the view.
So the answer is always the same: to be able to call this method, the session must be opened.
I am working on a weam web application where the once the user logs in, the main (or landing) page calls 4 stateful session beans. So once the user logs in, there will be atleast 4 threads of stateful session beans created. The page also has a logout button. The logout component in the xhtml calls a POJO which has a logout method.
In the logout method, the following statement is executed:
Session.instance().invalidate();
Now the question is, will the 4 threads/instances of the stateful session beans which are created when the user logs in will be destroyed or not.
I am running this application on JBOSS 4.2.3, Seam 2.2.1 Final
I am using JOSSO for authentication.
Yes, they're all part of the same session. You're actually creating session scoped beans, not separate sessions.
Easy enough to check though. Create a method in each of the session beans and annotate them with #Destroy, when the annotated bean is destroyed, it will call this method.
#Destroy
public void callMeWhenIDie(){
log.debug("I'm melting, I'm melting" + this.someDefiningCharacteristic);
}
I'm using Spring 3.1.1.Release, Security 3.1.0.Release.
I've added login/logout to my web app, however a session scoped bean is not functioning the way it was. The bean is used to connect to a CMS called CMSConnector.
To authenticate users, I implemented an AuthenticationProvider, and in the authenticate() call, I get the session-scoped CMSConnector and call the CMSConnector.login(). If the CMS login fails, it fails the login.
THE PROBLEM -
If the login is success, #predestroy logout() is called immediately after the successful login. I then found it was the SessionFixationProtectionStrategy is invoking the invalidate the previous session and assign it a new session.
session.invalidate();
session = request.getSession(true); // we now have a new session
The invalidate() is calling the #predestroy method on the session-scoped bean.
So I have temporarily removed the the #predestroy annotation leaving the connection not closed. (VERY BAD PRACTICE.)
What is a work around to resolve the issue?
I tried to create a #PostConstruct and put the login process there, but the #PostConstruct doesn't get called when request.getSession(true) is called.
Thanks!
Jason
I think its not the SessionFixationProtectionStrategy but the ConcurrentSessionControlStrategy.
Set max-sessions="-1" for this code snippet
I did not solve my original question, but I implemented a workaround - expire session in the session expire object instead of attached with #predestroy.