General
Portlets and Deployment
Embedding Pluto
Architecture, Design, and Implementation
Configuration
Common Problems
You're right. Pluto 1.0.x is currently going through the release process. Pluto 1.0.x is based off of the code base which was originally donated to the ASF by IBM. The first release candidate in this series was published on October 8, 2004.
Around the same time that this release occured Pluto 1.1.0-ALPHA was imported into our source repository. The 1.1.x series is a refactoring/rewrite of Pluto. It's entire purpose is to simplify the container and make it easier for both Portlet Developers and Portal Developers looking to embed Pluto into their portal to use Pluto. The 1.1.x series has made great progress and currently passes all of the tests available in the Pluto Testsuite.
The Javaworld examples are based on the Proposed Final Draft of JSR-168. The final specification included several changes, including some changes to the xsd.
Please see the message archivesfor a modified version of this example which will work with Pluto.
No, Pluto is a Portlet Container. If you are looking for a Portal implementation, try checking out Jetspeed.
Need more information about the difference between a Portal and a Portlet Container? Take a look at the next question.
This question was answered on the developer list in the following way:
| Date: | Tue, 11 Nov 2003 15:21:32 -0600 |
|---|---|
| From: | Craig Walls [wallsc.AT.michaels.DOT.com] |
| Subject: | setRenderParameter |
| Content-Type: | text/plain; charset=us-ascii |
|
This question seems to come up every other day. Perhaps this should be a FAQ?
Let me attempt to answer it...
Pluto is a JSR-168 compliant portlet container. That means that it provides a place for portlets to reside, but nothing else. Think of it this way: A portlet container (which is what Pluto is) is to portlets what an aquarium is to fish. Pluto comes with a minimal portal implementation. A portal implementation builds on top of the base container providing additional features which may vary from implementation to implementation. Layout and security are features that may be provided by a portal implementation, but they are in addition to what the container provides. Using the fish analogy again, a portal is to a portlet container what decorations are to an aquarium. That said, a portlet container provides the basic necessities required for portlets to live, just as an aquarium provides water (and a barrier to contain the water) for fish. A portal implementation provides extra stuff in addition to the portlet container just as an aquarium may have plants, rocks, and tiny little treasure chests that open and close. The fish can survive without the extras, just as a portlet can survive without security or some fancy layout engine. But the fish sure do look much nicer when surrounded with the extra stuff, just as portlets are much more useful when used alongside extra portal features. | |
Want a more technical answer? architectural overview for a more complete description
Firstly, please understand that the pluto portal is only intended to be demonstration of how to use pluto-the-container in a portal. The layout of the portal is controlled by two files, WEB-INF\data\pageregistry.xml and WEB-INF\data\portletentityregistry.xml. An explaination for the use of these files follows:
| Date: | Tue, 11 Nov 2003 02:05:43 +0800 |
|---|---|
| From: | Koh Choong Yong [dunpanic.AT.mailhost.DOT.net] |
| Subject: | Re: portletentityregistry.xml and pageregistry.xml |
| Content-Type: | charset=ISO-8859-1; format=flowed |
|
pageregistry.xml describes the layout of the portal in pluto. If you replace the correct sections in the default pageregistry.xml file with the following fragment, you will see that the 2 portlets are displayed one on top of another instead of side-by-side. The attribute for "value" in the <property> tag is a reference to the application id and portlet id in portletentityregistry.xml (see discussion below). <fragment name="row" type="row"> <fragment name="col1" type="column"> <fragment name="p1" type="portlet"> <property name="portlet" value="3.1"/> </fragment> </fragment> </fragment> <fragment name="row2" type="row"> <fragment name="col2" type="column"> <fragment name="p2" type="portlet"> <property name="portlet" value="4.1"/> </fragment> </fragment> </fragment> Each <application> tag defines one application (corresponding to one web-app on the portal container), which can contain multiple <portlet> tags. The "id" attribute in this tag identifies the application, and it does not necessary needs to be numeral. The <definition-id> tag within the <application> refers to the name of the web-app that contains the portlets in this application. Each <portlet> tag defines one portlet. Similarly the "id" attribute in this tag identifies the portlet. Note that the application id concatenated with the portlet id will be mapped to the "value" attribute in the <proprety> tag in pageregistry.xml The <definition-id> within the <portlet> is a concatenated id string identifying the portlet within the application. This is a reference to the <portlet-name> tag in the portlet.xml in the respective web-app. In the default setting,
<definition-id>testsuite.TestPortlet2</definition-id>
Each <preferences> tag within the <portlet> tag defines name/value pairs for the PorletPreferences. These values can be retrieved within the JSPs using the following code fragment:
PortletPreferences preferences = renderRequest.getPreferences();
String testPermanence = preferences.getValue("TEST_PERMANENCE", "Default");
out.println(testPermanence);
| |
Also note that since Pluto 1.0.1-rc2, another configuration file, portletcontexts.txt, has been included in the Pluto portal. The Portlet Contexts file ($PLUTO_HOME/WEB-INF/data/portletcontexts.txt) lists the webapp contexts for each portlet application that runs in Pluto. Each portlet app has a line in this file corresponding to a path and starting with a slash ('/'). In Tomcat, this path is the value of the 'path' attribute of the 'Context' element in a context XML descriptor in $TOMCAT_HOME/conf/Catalina/localhost (or another 'conf' subdirectory).
Application Scoped Session Attibutes only work in Tomcat 5.5.
In order to enable them on in Tomcat 5.5, you will need to modify your connector configuration. Specifically, set the parameter "emptySessionPath" to true in your connector config in the server.xml.
<Connector port="8080" maxThreads="150" minSpareThreads="25"
maxSpareThreads="75" enableLookups="false"
redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"
emptySessionPath="true" />
Note: This setting is now incorporated into the binary distribution of Pluto.
This is usually because pluto cannot load classes for a portlet.
Common causes include: