You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Stefan Siprell <ss...@epo.org> on 2004/07/08 09:20:49 UTC
Portletcontext and Sessioncontext
Hi everybody,
I am working on a portlet based application which we intend to deploy onto
both the WebSphere 5 and Pluto Platform. For development and integration
we prefer the Pluto implementation as it integrates tightly with our
development environment, has great debugging capabilities and is in
general the more streamlined solution. Yet it seems as if Pluto does not
fully comply to the portlet specification, when dealing with
Portletcontexts and Sessioncontexts. Allow me to quote some statements:
Java Portlet Specification 1.0 - PLT 3 Relationship with Servlet
Specification - Page 15 - lines 22+
=====================================================================================================
Portlets, servlets and JSPs are bundled in an extended web application
called porlet application. Portlets, servlets and JSPs within the same
portlet application share classloader, application context (does this
refer to servlet and portlet context?) and session.
Jakarta Pluto Mailing List - Downloading files from a portlet - Alejandro
Abdelnur - 06/29/2004
Main Thread:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=pluto-user@portals.apache.org&msgNo=777
Specific Message:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=pluto-user@portals.apache.org&msgNo=787
=============================================================================================================
(...)If you are deploying a set of portlets, servlets and JSPs as a
portlet application the runtime/execution environment should not break
them up. If that is happening that is wrong.
Java Portlet API Reference - javax.portlet.PortletContext - Introduction (
http://www.bluesunrise.com/portlet-api/javax/portlet/PortletContext.html)
==========================================================================
There is one context per "portlet application" per Java Virtual Machine.
(A "portlet application" is a collection of portlets, servlets, and
content installed under a specific subset of the server URL namespace,
such as /catalog. They are possibly installed via a .war file.) As a web
application, a portlet application also has a servlet context. The portlet
context leverages most of its functionality from the servlet context of
the portlet application.
Attibutes stored in the context are global for _all_ users and _all_
components in the portlet application.
-----
Adding this all up, makes me understand, that anything I put into a
Servletcontext is available in a Portletcontext or vice versa as long as
both (the servlet and the portlet) have been loaded from the same portlet
application (war).
But this is not the case with the current Pluto implementation, but oddly
enough WebSphere 5 behaves as anticipated (it actually works).
Let me describe what I am trying to do:
A servlet inserts an object into its servletcontext during initialization
using code like the following:
servletcontext.setAttribute(IN_CONTEXT_ID, wrapper);
Later inside the portlet I try to retrieve the same object using the
portletcontext like the following:
BinaryDownloadWrapper wrapper = (BinaryDownloadWrapper)
portletcontext.getAttribute(IN_CONTEXT_ID);
Here is the exact problem:
* Websphere 5.x finds the wrapper object in its PortletContext
* Pluto does not find the wrapper object, as if the servlet never
wrote it.
Interestingly the context name of the servlet is based on the war name and
the context name of the portlet is <<Pluto Reference Implementation>>. The
portletcontext contains servletspecific attributes:
javax.servlet.context.tempdir:
C:\pluto\jakarta-tomcat-4.1.30\work\Standalone\localhost\pluto
org.apache.catalina.resources:
org.apache.naming.resources.ProxyDirContext@6bf4ff
org.apache.catalina.WELCOME_FILES: [Ljava.lang.String;@21b42f
org.apache.pluto.portalImpl.StaticInformationProvider:
org.apache.pluto.portalImpl.core.StaticInformationProviderImpl@3c9673
org.apache.catalina.jsp_classpath:
/C:/pluto/jakarta-tomcat-4.1.30/webapps/pluto/WEB-INF/classes[...]
But judging by the name of the portletcontext I assume, that it is based
upton the servletcontext of the pluto.war and not of our own war (where
the portlet has been loaded from).
Is this a correct behaviour according to the specification?
Regards
Stefan
Re: Portletcontext and Sessioncontext
Posted by Stefan Siprell <ss...@epo.org>.
Hi there,
we have been able to resolve the issue by deploying Pluto and the
Portlet-Application to the latest Tomcat 5 version. Tomcat 4 is known to
have problems which context crossing. Maybe this should be stated
somewhere on the Pluto site.
Thanks for your help and for writing such nice software!
Regards
Stefan
Nick Lothian <ni...@mackmo.com>
08.07.2004 11:14
Please respond to
pluto-dev@portals.apache.org
To
pluto-dev@portals.apache.org
cc
Subject
Re: Portletcontext and Sessioncontext
Stefan Siprell wrote:
>Hi everybody,
>I am working on a portlet based application which we intend to deploy
onto
>both the WebSphere 5 and Pluto Platform. For development and integration
>we prefer the Pluto implementation as it integrates tightly with our
>development environment, has great debugging capabilities and is in
>general the more streamlined solution. Yet it seems as if Pluto does not
>fully comply to the portlet specification, when dealing with
>Portletcontexts and Sessioncontexts. Allow me to quote some statements:
>
>[snip]
>
>Is this a correct behaviour according to the specification?
>
>
No it is not correct behaviour. See
http://nagoya.apache.org/jira/browse/PLUTO-53
Nick
Re: Portletcontext and Sessioncontext
Posted by Nick Lothian <ni...@mackmo.com>.
Stefan Siprell wrote:
>Hi everybody,
>I am working on a portlet based application which we intend to deploy onto
>both the WebSphere 5 and Pluto Platform. For development and integration
>we prefer the Pluto implementation as it integrates tightly with our
>development environment, has great debugging capabilities and is in
>general the more streamlined solution. Yet it seems as if Pluto does not
>fully comply to the portlet specification, when dealing with
>Portletcontexts and Sessioncontexts. Allow me to quote some statements:
>
>[snip]
>
>Is this a correct behaviour according to the specification?
>
>
No it is not correct behaviour. See
http://nagoya.apache.org/jira/browse/PLUTO-53
Nick