I have my flex object embedded to JSP page.The JSP page retrieves user information like user name and group from portal profile object and stores in http session parameters. The flex Object makes a remote call to Employee.class to perform persona based operation.
I retrieved the session id in JSP and also in the Employee.class both are same. But I am not able to retrieve the username stored in the http session from FlexSession. I read in the internet that the FelxSession will hold all httpSession information as well. It’s always coming as null. Correct me if I am wrong.
In the JSP I set the
session.setAttribute("sasUserName","sasdemo");
session.setAttribute("sasGroupList",gl);
In Employee.class
import flex.messaging.FlexSession;
import flex.messaging.FlexContext;
mySession = (FlexSession)FlexContext.getFlexSession();
mySession.getAttribute("sasUserName")
Let me know if I need to make any other set up.
FlexContext should be called only inside of a blazeds AMF request - otherwise all the content is null. What happens is:
a)an AMF call is invoked
b)the MesageBroker servlet will setup the FlexContext object
c)the invoked method is executed
d)the MessageBroker servlet will clear the FlexContext object
e)the result of the call is returned.
Let me know if it's clear enough.
Related
We are using vSphere web client SDK 6.0 (HTML bridge) and trying to retrieve session with com.vmware.vise.usersession.UserSessionService.getUserSession().
for code sample you can refer vsphere-wssdk example from vsphere-client-sdk\html-bridge\samples.
After injecting this interface in class VmDataProviderImpl, it will return proxy object of UserSessionService and _userSessionService.getUserSession() always returns null.
How will we get current logged in user session of vSphere web client with vim25.
Please advise.
_userSessionService.getUserSession() can return null in a number of cases:
you are calling the method from outside of an HTTP-handling thread (http-bio--exec-XXX in Tomcat). The behavior is like this since there is no way to understand what is the user that initiated the action.
you are calling the method inside an HTTP-handling thread but the plugin does not have its WAR's session properly set up - for example if you've forgotten to define a SessionManagementFilter inside your WAR's web.xml.
My JSP contains javascript code,which include two function
One function is call a servlet
ie.window.showModalDialog("mams.openAndSave",...........)
for opening a report and setting a value in HttpSession.
And Another function use retrieve session value set previously using expression language
ie.dataToSave='${sessionScope.executionFilePath}';
but here dataToSave variable have not been initialized during form submission.
Above functions are called dynamically using link provided in JSP.
Any one know solution to this query,please reply
First of all, you need to control the flow of your Javascript call. You can read about <body onload="myFunction()"> and document.ready features to control the javascript function calls.You cannot directly access session objects using client side javascript directly. The session objects can be accessed with the help of ajax call to a servlet or any server side programs. Thus, the servlet access the HttpSession, sets the attribute value, gets the attribute value and return it to the client. HttpSession is not threadsafe by default. so, you can make it thread safe by locking the session object in the servlet or server side program as below
HttpSession session=request.getSession();
synchronized(session)
{
//setAttributes in the session object
//getAttributes from the session object
}
Hope this helps
I'm developing a single page jQuery & Backbone.js web app. The backend is a JBoss 6 application server.
Until now we had the following structure:
There is only one servlet (front controller). Every request from the JavaScript client goes through here.
In the servlet - at the first request of a certain JS client - I make a look p to a stateful session bean. For the next requests of this client, I store the result of the look up in an HTTP session container. So every JS client has exactly one stateful session bean. This connection is kept by a session cookie.
Now I have an additional requirement:
When the user has two browser tabs (in one browser), they should have two isolated instances of the web app in every browser tab. Because of that I have a problem with session cookies because this session cookie is for all browser tabs.
I have to change the structure so that:
The servlet has to generate a new session ID for the first request of a certain JS client. This session ID is communicated to the client.
With every POST to the backend the JS client has to send this session ID.
My question is:
Until now I saved the result of the look up in an HTTP Session object and I hadn't to think about generating a session ID. But now I have to store this somewhere else, where?
Has anybody experience with this kind of setting and can help me?
Update:
Thank you BalusC for this very interesting approach.
When I understood you well, this means:
All individual JS clients of the tabs of one browser share one HTTP session object. And in this HTTP session object, every tab has its own entry point. That sounds really good. So I still can use the whole HTTP session infrastructure and don't have to reinvent the wheel.
Autogenerate an unique value on the initial GET request which you store and pass around on every subsequent postback as a hidden input value. Use this unique value as identifier of the session attribute representing the view-scoped data.
During the 1st request on a brand new session, do:
Map<String, ViewData> viewScope = new HashMap<String, ViewData>();
session.setAttribute("viewScope", viewScope);
(the ViewData represents the view-specific data you'd like to track across postbacks on the same view)
During every GET request, do:
String viewDataId = UUID.randomUUID().toString();
viewScope.put(viewDataId, new ViewData());
request.setAttribute("viewDataId", viewDataId);
During generating the HTML, do:
<input type="hidden" name="viewDataId" value="${viewDataId}" />
During every POST request, do:
ViewData viewData = viewScope.get(request.getParameter("viewDataId"));
// Get/set view-specific data in there.
Make sure that jQuery also passes this hidden input around (which shouldn't be a big problem if you already properly use $(form).serialize() or e.g. AjaxForm plugin to ajaxify the forms).
If you're familiar with Java EE's MVC framework JSF, then it may be useful to know that its #ViewScoped annotation works roughly the same as described above. See also a.o. How to choose the right bean scope?
You can use session tracking with URL rewriting. See here:
Session shared in between tabs
I read a few tutorials about forms and submission in Spring 3 MVC. All these examples indicate that storing the backing object in the session the following way:
#SessionAttributes({"command"})
I used old versions of Spring in which there is a formBacking method if a controller inherits SimpleFormController.
protected Object formBackingObject(HttpServletRequest request)
If my understanding is right, the old version approach loads the form backing object on the fly when the form submits and there is no need of storing this object in session.
If my understanding about Spring 3 MVC is right, then I don't like the session approach because it consumes lot of memory in case of large users and the object stored in session might be outdated at the time of form submission.
Can I avoid storing the form backing object in session in Spring 3's MVC? Any pointer?
Thanks for any input and please correct me if I am wrong.
Regards.
Anyone else knows whether my understanding is right?
the GET controller adding the object to the model equates to adding it to session. How can Spring remember the object as the backing object when a form is submitted? Cheers.
How can the form backing object added to the model in the GET controller survive a round trip between the server and client when a form is submitted? Does Spring serialize it on disk? I am guessing...
Thanks for any input!
If you simply do not list your command among the #SessionAttributes, it will be instantiated every time.
In the old Controller API, implementations could decide whether or not they want to keep their command objects on the session: see AbstractFormController.isSessionForm(). SimpleFormController returned false, while AbstractWizardFormController returned true, as it actually required the command to be stored on the session.
You can check how a model attribute is bound in the HandlerMethodInvoker.resolveModelAttribute(...) private method:
if (implicitModel.containsKey(name)) {
// ...
} else if (this.methodResolver.isSessionAttribute(name, paramType)) {
// ...
else {
bindObject = BeanUtils.instantiateClass(paramType);
}
So obviously, the binder will use a fresh instance if you don't explicitely declare it as session attribute; exactly the same as returning false from AbstractFormController.isSessionForm().
How can the form backing object added to the model in the GET controller survive a round trip between the server and client when a form is submitted? Does Spring serialize it on disk? I am guessing...
Spring does not (always) need to store the backing object between form view and form submission. If everything that you need in order to populate your command object comes with the request, Spring can simply instantiate a new command object (either itself or let you do it if you provide a proper method) and then bind the request to that fresh instance.
See above the comparison with the old API regarding the difference between SimpleFormController and AbstractWizardFormController implementations. The first does not need to store anything on the session and it will bind the submit request to a newly created object. With the new annotated handlers, the flow is the same; if you don't want to store it, it will be recreated on submit: BeanUtils.instantiateClass(...) or your own custom factory method.
You need to add the backing object to the model, not to the Session. Here's one tutorial... http://www.roseindia.net/tutorial/spring/spring3/web/spring-3-mvc-form-example.html
Hey guys i'm working on admin module for my project. When a person logs-in, a request is sent to login servlet. When it further ask for some other report by clicking other options a request for the report is sent to other servlet which gives the result on the page which is shown at the time of user which is of normal type. The session is lost between two servlets.
I am trying to navigate the generated report on some other page but for that i need to know user type in second servlet. This can be done by fetching value of user_type from login module bean class.
How to handle this situation? thanks
My login servlet is :
LoginService user = new LoginService();
user.setUserName(request.getParameter("username"));
user.setPassword(request.getParameter("password"));
user = UserDAO.login(user);
if (user.isValid())
{
HttpSession session = request.getSession(true);
session.setAttribute("currentSessionUser",user);
if(user.getUser_type().equalsIgnoreCase("admin")){
response.sendRedirect("administrator/homepage.jsp");
}else{
response.sendRedirect("homepage.jsp"); //logged-in page
}
}
else
response.sendRedirect("invalidlogin.jsp"); //error page
}
i tried using this in second servlet:-
LoginService session = (LoginService)request.getAttribute("currentSessionUser");
String drake = session.getUser_type();
System.out.println("usertype = " +drake);
Here LoginService is the bean class of login module. i'm get a nullpointer exception here.
I think you're trying to do stuff that your web container should handle for you... A session should automatically be maintained over the course of multiple servlet calls from the same client session. Methods from HttpServlet are given a HttpServletRequest. You can obtain the corresponding HttpSession using one of the getSession methods of that class.
You can bind stuff to the HttpSession using setAttribute and getAttribute.
EDIT: I'm taking this from the Servlet spec 2.5:
A servlet can bind an object attribute into an HttpSession implementation by name.
Any object bound into a session is available to any other servlet that belongs to the
same ServletContext and handles a request identified as being a part of the same
session.
I think you're better off getting the HttpSession object from the HttpServletRequest (at least assuming it's a HttpServlet) and setting/getting attributes through that. If you choose a proper name (it follows the same convention as Java package naming) for your attribute, you can be sure the returned object, as long as it's not null, can be cast to whatever type you put in there. Setting and getting attributes on the request itself isn't gonna help, I don't think stuff will get carried over from one servlet call to the next unless you call one servlet from the other with a RequestDispatcher, but that's not what you're after here.
So in your second code sample, do (LoginService)request.getSession().getAttribute("currentSessionUser");, that ought to work. Make sure to check for nulls and maybe choose an attribute name that uses your project's package name convention (like com.mycompany...).
I wouldn't mind a second opinion here since I'm not much of an EE/web developer.