按照JSR168规范的说明,在Portlet中,我们可以通过PortletSession访问存储在HttpSession中的属性,我看了Pluto的实现,也确实是这样做的:
    // PortletSession Impl: Attributes —————————————–
   
    public Object getAttribute(String name) {
        return getAttribute(name, DEFAULT_SCOPE);
    }
   
    /**
     * Returns the attribute of the specified name under the given scope.
     *
     * @param name  the attribute name.
     * @param scope  the scope under which the attribute object is stored.
     * @return the attribute object.
     */
    public Object getAttribute(String name, int scope) {
        ArgumentUtility.validateNotNull("attributeName", name);
        String key = (scope == PortletSession.APPLICATION_SCOPE)
                ? name : createPortletScopedId(name);
        return httpSession.getAttribute(key);
    }

但是当我把pluto集成到我们的应用里面的时候,问题就来了,用户登录后,访问其它的页面和访问portlet的页面的时候的session id是不同的,历经磨难,找到一些前人的文章:

 
From testing with Jetspeed/Pluto on Tomcat 5.0 and the default configuration of 5.5, servlets accessed directly do not share the portlet session. In Tomcat 5.5 configured with emptySessionPath="true", behaviour is correct as described in the portlet specification.

So, to summarize what I’ve learned, if you need to pass session objects from a portlet to a servlet using Pluto as your servlet container, the following three conditions must all be true:

  1. You must run Tomcat 5.5.x, or later.
  2. You must set crossContext="true" in your web app’s element.
  3. You must set emptySessionPath="true" in the element in Tomcat’s server.xml file.

If you omit any one of these three steps, it won’t work.

所以问题的核心就是emptySessionPath,在我们的环境中使用的是tomcat5.0,crossContext是设置为true的。

2007年3月21日下午更新:
集成中的问题是我犯了一个错误,我在获取HttpSession中的属性的时候忘了应该使用APPLICATION_SCOPE,而不同的session id是因为我的另外的代码导致的(我写了一个Bridge类去获得Struts的Action的执行结果并输出,在Bridge中的请求相当于另外一个客户端)。
从Portlet中,使用RenderRequest..getPortletSession().getAttribute("xxxx", PortletSession.APPLICATION_SCOPE)就可以拿到其它的普通servlet和jsp中设置的值了。

(Visited 170 times, 1 visits today)