Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
GET HTTP Session from serve resource
Hi every one,
i am trying to get Http session from serve resource method i use the following lines
"HttpServletRequest org = PortalUtil.getOriginalServletRequest(PortalUtil.getHttpServletRequest(request));
log.info(" session id ="+org.getSession().getId());"
but the session id printed is totaly different than the real http session id
note : when i use the same lines of code on render method not serve resource methods it works fine and return the same id
i am trying to get Http session from serve resource method i use the following lines
"HttpServletRequest org = PortalUtil.getOriginalServletRequest(PortalUtil.getHttpServletRequest(request));
log.info(" session id ="+org.getSession().getId());"
but the session id printed is totaly different than the real http session id
note : when i use the same lines of code on render method not serve resource methods it works fine and return the same id
They are not guaranteed to be the same session.
A render request is basically issued by the portal when it's main servlet is collecting content to aggregate a page. Therefore the request that you get in your portlet originates from the ROOT web application.
Serve resource requests, though, well they can go directly through your own portlet war, so it's through your own web app and therefore has your own session, not the portal session.
This is another reason to avoid session storage, as I've said before it is a miserable hack to begin with and it doesn't play well in a cluster. Whatever you're trying to store in the session should be persisted in a classic sense, not the hack of the session store.
Come meet me at the 2017 LSNA!
A render request is basically issued by the portal when it's main servlet is collecting content to aggregate a page. Therefore the request that you get in your portlet originates from the ROOT web application.
Serve resource requests, though, well they can go directly through your own portlet war, so it's through your own web app and therefore has your own session, not the portal session.
This is another reason to avoid session storage, as I've said before it is a miserable hack to begin with and it doesn't play well in a cluster. Whatever you're trying to store in the session should be persisted in a classic sense, not the hack of the session store.
Come meet me at the 2017 LSNA!
thanks for your reply
in my case i need to store a value that comes from external service which will be the same across the session and i want to access it while i make ajax calls so how can i achieve that when i have new session with every ajax call is there any alternative rather than keep it in the session
in my case i need to store a value that comes from external service which will be the same across the session and i want to access it while i make ajax calls so how can i achieve that when i have new session with every ajax call is there any alternative rather than keep it in the session
Yes there is a solution - avoid the session altogether.
Now that doesn't mean it has to be retrieved each time. You can, for example, leverage a SingleVMPool or MultiVMPool (for a cluster) which pushes retrieved values into a cache that is backed by ehcache and so it will expire and discard values. So basically you check the cache and, if it doesn't have the value, retrieve from remote service and store back in the cache.
But session storage is always, always a bad idea and a terrible hack.
Come meet me at the 2017 LSNA!
Now that doesn't mean it has to be retrieved each time. You can, for example, leverage a SingleVMPool or MultiVMPool (for a cluster) which pushes retrieved values into a cache that is backed by ehcache and so it will expire and discard values. So basically you check the cache and, if it doesn't have the value, retrieve from remote service and store back in the cache.
But session storage is always, always a bad idea and a terrible hack.
Come meet me at the 2017 LSNA!