I've posted here before, and searched high and low, and not found a good
clean solution to accessing data from a PortletSession when inside an AJAX
servlet.  So, I'm positing what I plan to do here, for peer review and/or to
help others.

Basically, I know what I shouldn't know -- the PortletSessions' attributes
are really namespaced into the HttpSession.  It just so happens that in our
application, we don't store things directly in the session, but in a
purpose-built object which in turn is itself stored in the session.  So, the
AJAX servlet will take as input, among its normal data, the namespaced
prefix if the portlet making the request, and will use the super-secret
knowledge to get the purpose-built object from the HttpSession by prepending
the given prefix to its constant name.

Object dataFromPortletSession = httpSession.getAttribute(portletPrefix + "_"
+ PurposeBuilt.ATTR_NAME);

I had originally considered making my own HttpSession dummy class that,
given a portlet idand a real HttpSession, would act just like the portlet
session.  I towuld take any getAttribute(x) call and call get(prefix+X) on
the real HttpSession.  However, to fully implement the HttpSession API would
mean having to stub a LOT of objects that are accessible through the
HttpSession, and I didn't want ot have to build and support that.  So, I
opted to just build a small, well documented and fully disclosed kludge to
get just our purpose-built object instead.

There are still risks involved.  There is no guarantee that WPS will always
implement PortletSessions via namespacing, nor that such namespacing will
always use a prefix.  But by keeping this kludge in a single centrally
maintainable class in our project, I'll know where to go to fix it when it
breaks.

There is also the risk that,with clustering, WebSphere only knows to
propogate sesson data between the servers when the XXXSession.setAttribute
method is called.  However, our application has some very rich objects (not
data heavy, but logic heavy) stored in the session, and you don't know what
data imght or might not change when you start manipulating the top of these
chains, so we're marking the session dirty every time anyays.  Thus, we've
already absorbed this punch before AJAX, so its nothing new.

Any comments, good or bad?

Regards,
Brian.

[ Post a follow-up to this message ]

If you want to pass variables to the HTTP session without portletsession
namespacing, you can do the following ..

public void processAction(ActionRequest request, ActionResponse response)

23;

PortletSession ps = request.getPortletSession();
HttpSession hs =
((org.apache.pluto.core.impl.PortletSessionImpl)ps).getHttpSession();
// save something to the portlet session globally for all portlets,
// namespaced when accessed via servlets on the same war
ps.setAttribute("someKey", someObject, PortletSession.APPLICATION_SCOPE);
// no namespacing going on here, servlets on the same war can access the
//variable simply by using the same key name
hs.setAttribute ("someKey", someObject);
}


Or you can use the DynaCache and use the SESSIONID (both HttpSession and
PortletSession have the same key) as a key to contain a MAP.

G

"Brian J. Sayatovic" <bsayatovic@amig.com> wrote in message
news:dkae0v$2idu$1@news.boulder.ibm.com...
> I've posted here before, and searched high and low, and not found a good
> clean solution to accessing data from a PortletSession when inside an AJAX
> servlet.  So, I'm positing what I plan to do here, for peer review and/or
> to
> help others.
>
> Basically, I know what I shouldn't know -- the PortletSessions' attributes
> are really namespaced into the HttpSession.  It just so happens that in
> our
> application, we don't store things directly in the session, but in a
> purpose-built object which in turn is itself stored in the session.  So,
> the
> AJAX servlet will take as input, among its normal data, the namespaced
> prefix if the portlet making the request, and will use the super-secret
> knowledge to get the purpose-built object from the HttpSession by
> prepending
> the given prefix to its constant name.
>
> Object dataFromPortletSession = httpSession.getAttribute(portletPrefix +
> "_"
> + PurposeBuilt.ATTR_NAME);
>
> I had originally considered making my own HttpSession dummy class that,
> given a portlet idand a real HttpSession, would act just like the portlet
> session.  I towuld take any getAttribute(x) call and call get(prefix+X) on
> the real HttpSession.  However, to fully implement the HttpSession API
> would
> mean having to stub a LOT of objects that are accessible through the
> HttpSession, and I didn't want ot have to build and support that.  So, I
> opted to just build a small, well documented and fully disclosed kludge to
> get just our purpose-built object instead.
>
> There are still risks involved.  There is no guarantee that WPS will
> always
> implement PortletSessions via namespacing, nor that such namespacing will
> always use a prefix.  But by keeping this kludge in a single centrally
> maintainable class in our project, I'll know where to go to fix it when it
> breaks.
>
> There is also the risk that,with clustering, WebSphere only knows to
> propogate sesson data between the servers when the XXXSession.setAttribute
> method is called.  However, our application has some very rich objects
> (not
> data heavy, but logic heavy) stored in the session, and you don't know
> what
> data imght or might not change when you start manipulating the top of
> these
> chains, so we're marking the session dirty every time anyays.  Thus, we've
> already absorbed this punch before AJAX, so its nothing new.
>
> Any comments, good or bad?
>
> Regards,
> Brian.
>
>

[ Post a follow-up to this message ]

Unfortunately, that's not quite what I want.

Our application is built using WPS Struts.  It relies heavily upon the
session which happens to be a PortletSession.  And we're relying on the fact
that PortletSessions are paritioned between portlets.  We *don't* want to
share data.

What I want is a way to add AJAX behavior to the HTML in a portlet.  My
understanding is that AJAX is best delivered by an HttpServlet.  But all of
the data is built up in the portlet session.  I don't want to stick it into
the HttpSession because it owuld collide with other portlets.  What I really
want is a way for my HttpServlet to access a PortletSession for a particular
portlet it is servicing AJAX requests for.

So, rather than trying to make a heayv-handed kludged fake PortletSession
that my HttpServlet can use to read through to the encoded data for a
portlet, I'm leveraging the fact that all of our data is stored in a purpose
built object which itself is in the PortletSession.  So all my kludge has to
do is fetch this one object via its portlet-namespaced attribute in the
HttpSession.

Regards,
Brian.

"George Daswani" <funks@socalsrt4.com> wrote in message
news:dkb1qq$2bvm$1@news.boulder.ibm.com...
> If you want to pass variables to the HTTP session without portletsession
> namespacing, you can do the following ..
>
> public void processAction(ActionRequest request, ActionResponse response)&
#123;
>
>    PortletSession ps = request.getPortletSession();
>    HttpSession hs =
> ((org.apache.pluto.core.impl.PortletSessionImpl)ps).getHttpSession();
>    // save something to the portlet session globally for all portlets,
>    // namespaced when accessed via servlets on the same war
>    ps.setAttribute("someKey", someObject,
PortletSession.APPLICATION_SCOPE);
>    // no namespacing going on here, servlets on the same war can access
the
>    //variable simply by using the same key name
>    hs.setAttribute ("someKey", someObject);
>   }
>
>
> Or you can use the DynaCache and use the SESSIONID (both HttpSession and
> PortletSession have the same key) as a key to contain a MAP.

[ Post a follow-up to this message ]

On 2005-11-02 08:13:03 -0500, "Brian J. Sayatovic" <bsayatovic@amig.com> sai
d:

> There are still risks involved.  There is no guarantee that WPS will alway
s
> implement PortletSessions via namespacing, nor that such namespacing will
> always use a prefix.  But by keeping this kludge in a single centrally
> maintainable class in our project, I'll know where to go to fix it when it
> breaks.

What I've done in the past (due to these exact fears) is to store a
bean in the session and then iterate through the keys, looking for
objects whose getClass() is the same as my bean.  You lose the speed of
direct lookup, but gain certainty. :-)

[ Post a follow-up to this message ]

Here's what I've done as a kludgy workaround for this...

First, to restate the problem, by AJAX calls are being handled by a servlet
rather than a portlet since a portlet aggregates and wraps content in a
manner that is disruptive to AJAX.  However, this means AJAX calls cant'
readily access server-side state stored in a PortletSession.  Parameterizing
the AJAX calls to take relevant state on the AJX query string openes
security risks.  So, I wanted a sol'n to get to a PortletSession from a
servlet.

My sol'n relies upon the fact that PortletSession data is actually stored in
the HttpSession as attributes with encoded names.  Thus, if one knows the
encoded name of an attribute in a PortletSession, it can be retrieved from
the HttpSession.

My sol'n is thus:

1. Store relavent data in a Container that itself is stored in the
PortletSession.
2. Container implements HttpSessionBindingListener
3. Since Container is only bound once (guaranteed through controlled
lifecycle of container object), the one event it receives contains the
HttpSession attribute name it is bound under, which is the encoded name.
4. The encoded name is obfuscated behind a ContainerHandle that can be
serialized/deserialized as a String.
5. Portlet JSPs writing out AJAX calls include as a parameter the
String-serialized ContainerHandle for the Container in their PortletSession.
6. The AJAX servlet deserializes the String version of the Handle and uses
the enocded name from this Handle to find the Container in the HttpSession.
7. The AJAX functionality executes, using the Container

The kludge is thus hidden behind the "handle".  The handle is used instead
of directly using the encoded name to hopefully insulate the code from any
changes IBM might make in the way PortletSessions are stored.

Regards,
Brian.

"Brian J. Sayatovic" <bsayatovic@amig.com> wrote in message
news:dkae0v$2idu$1@news.boulder.ibm.com...
> I've posted here before, and searched high and low, and not found a good
> clean solution to accessing data from a PortletSession when inside an AJAX
> servlet.  So, I'm positing what I plan to do here, for peer review and/or
to
> help others.
>
> Basically, I know what I shouldn't know -- the PortletSessions' attributes
> are really namespaced into the HttpSession.  It just so happens that in
our
> application, we don't store things directly in the session, but in a
> purpose-built object which in turn is itself stored in the session.  So,
the
> AJAX servlet will take as input, among its normal data, the namespaced
> prefix if the portlet making the request, and will use the super-secret
> knowledge to get the purpose-built object from the HttpSession by
prepending
> the given prefix to its constant name.
>
> Object dataFromPortletSession = httpSession.getAttribute(portletPrefix +
"_"
> + PurposeBuilt.ATTR_NAME);
>
> I had originally considered making my own HttpSession dummy class that,
> given a portlet idand a real HttpSession, would act just like the portlet
> session.  I towuld take any getAttribute(x) call and call get(prefix+X) on
> the real HttpSession.  However, to fully implement the HttpSession API
would
> mean having to stub a LOT of objects that are accessible through the
> HttpSession, and I didn't want ot have to build and support that.  So, I
> opted to just build a small, well documented and fully disclosed kludge to
> get just our purpose-built object instead.
>
> There are still risks involved.  There is no guarantee that WPS will
always
> implement PortletSessions via namespacing, nor that such namespacing will
> always use a prefix.  But by keeping this kludge in a single centrally
> maintainable class in our project, I'll know where to go to fix it when it
> breaks.
>
> There is also the risk that,with clustering, WebSphere only knows to
> propogate sesson data between the servers when the XXXSession.setAttribute
> method is called.  However, our application has some very rich objects
(not
> data heavy, but logic heavy) stored in the session, and you don't know
what
> data imght or might not change when you start manipulating the top of
these
> chains, so we're marking the session dirty every time anyays.  Thus, we've
> already absorbed this punch before AJAX, so its nothing new.
>
> Any comments, good or bad?
>
> Regards,
> Brian.
>
>

[ Post a follow-up to this message ]

AAAAarrg.
Do you really think that is better??? What happens if you (or someone) accid
entilly puts "one more" inst of the "magic" class on session...



> What I've done in the past (due to these exact fears)
> is to store a
> bean in the session and then iterate through the
> keys, looking for
> objects whose getClass() is the same as my bean.  You
> lose the speed of
> direct lookup, but gain certainty. :-)
>
>

[ Post a follow-up to this message ]

I'm not sure I understand everything you are trying to do, but here is one t
hing I have done to provide servlet to portlet data sharing.

I have a static class that basicly holds a hashmap.  Since it is static all 
the classes in the system can reference it easily.

In my case this base hash map contains other hash maps where the key for eas
h is a session id.

If your goal is simply to let the servlet get at a PortletSession then you c
ould have each portlet store a reference to its PortletSession in the base m
ap with some key that the servlet can determine (e.g. the portlet puts it in
 a hidden variable on the p
age).

The portlet would just do (once)

MyStaticClass.set(myPortletId, myPortletSession);

The servlet would just do;

MyStaticClass.get(request.getAttribute("portletID"));

One problem with this, however, is that this means the servlet needs to unde
rstand the portlet classes which is not really a good idea, so your idea of 
putting all the info that needs to be communicated in your own class in the 
portlet session would be be
tter and then just put the reference to the instance of your class into MySt
aticClass.

I agree very much with your point that depending upon the curent IBM impleme
ntation is a bad idea.

-- Frank

[ Post a follow-up to this message ]

I had considered what you described for plan B if plan A didn't work out.
My current implemention, though, is abstracted enough that I could switch to
plan B without affecting existing code, so I have a little peace of mind.

Ultimately, I want two things:

1. The ability for a servlet in WPS to act in the same space as a portlet on
that portlet's behalf (e.g. downloading PDFs, AJAX calls, etc.) and still
get to the portlet's session
2. The ability for portlets to share data with other things in the portal
(inter-portlet communication and messaging seems complex -- I also think
JSR-168 allows you to set things into a PortletSession as Portlet or
Application scope, but not in IBM's WPS 5.0 portlet codebase).

Regards,
Brian.

<flawlor@athensgroup.com> wrote in message
news:1349075040.1134594723433.JavaMail.wassrvr@ltsgwas007.sby.ibm.com...
> I'm not sure I understand everything you are trying to do, but here is one
thing I have done to provide servlet to portlet data sharing.
>
> I have a static class that basicly holds a hashmap.  Since it is static
all the classes in the system can reference it easily.
>
> In my case this base hash map contains other hash maps where the key for
eash is a session id.
>
> If your goal is simply to let the servlet get at a PortletSession then you
could have each portlet store a reference to its PortletSession in the base
map with some key that the servlet can determine (e.g. the portlet puts it
in a hidden variable on the page).
>
> The portlet would just do (once)
>
>   MyStaticClass.set(myPortletId, myPortletSession);
>
> The servlet would just do;
>
>   MyStaticClass.get(request.getAttribute("portletID"));
>
> One problem with this, however, is that this means the servlet needs to
understand the portlet classes which is not really a good idea, so your idea
of putting all the info that needs to be communicated in your own class in
the portlet session would be better and then just put the reference to the
instance of your class into MyStaticClass.
>
> I agree very much with your point that depending upon the curent IBM
implementation is a bad idea.
>
>   -- Frank

[ Post a follow-up to this message ]

For inter-portal communication within the same session you can just try

org.apache.jetspeed.portlet.User user = portletRequest.getUser();
user.setAttribute("foo", "bar");
..
// other portlet
user.getAttribute*"foo");

-- Frank

[ Post a follow-up to this message ]

Hello All,

I'm just wondering if anyone had success with this.

I just wrote a small test and it doesn't seem to be working:

- 1 portlet that displays all the attributes in the HttpSession through in a
 jsp.
- 1 web app with a jsp page that displays all the attributes in the HttpSess
ion.
<code>
 ########################################
########################
Session id: <%= session.getId() %> - <%= session.getClass() %>
&lt;ul&gt;
<% java.util.Enumeration enum = session.getAttributeNames();
while(enum.hasMoreElements()) {
%>
&lt;li&gt; <%= enum.nextElement() %>&lt;/li&gt;
<% } %>
&lt;/ul&gt;
 ########################################
########################
</code>
Both of them are running on the portal server and the session id's are the s
ame.
The attributes however are still separate.

I'm not sure if the IBM HttpSesssion implementation: com.ibm.ws.webcontainer
.httpsession.MemorySessionData is keeping stuff separate or what exactly is 
happening.

I am going to try 'plan B': The static class implementation with a hashmap.

Cheers,
Raymond

[ Post a follow-up to this message ]