Modified: portals/site-live/jetspeed-2/j1-migration.html URL: http://svn.apache.org/viewvc/portals/site-live/jetspeed-2/j1-migration.html?rev=1901428&r1=1901427&r2=1901428&view=diff ============================================================================== --- portals/site-live/jetspeed-2/j1-migration.html (original) +++ portals/site-live/jetspeed-2/j1-migration.html Tue May 31 02:15:08 2022 @@ -42,7 +42,7 @@ <div class="xleft"> - Last Published: 9 May 2016 + Last Published: 26 May 2022 </div> <div class="xright"> <a href="http://portals.apache.org/applications/"; class="externalLink">Applications</a> | @@ -253,11 +253,11 @@ </div> <div id="bodyColumn"> <div id="contentBox"> - <subtitle></subtitle><authors><person name="David Sean Taylor" email="[email protected]"></authors><div class="section"><h2><a name="Overview"></a>Overview</h2> + <subtitle></subtitle><authors><person name="David Sean Taylor" email="[email protected]"></authors><div class="section"><h2><a name="Overview"></a>Overview</h2> <p>This migration guide will help you migrate from Jetspeed version 1 to Jetspeed version 2. Note that there are currently no migration tools, nor are the plans to create a migration tool to convert portal resources from version 1 to version 2. This document provides only guidelines for migration. - </p> + </p> <p> With the development of the new portal standard (The Portlet API), the common portlet metaphor has changed quite drastically from the Turbine-based origins in version 1. @@ -266,47 +266,47 @@ user attributes and init parameters that have no direct mapping from version 1. Creating a migration tool would be a large undertaking. The Jetspeed development team is not prepared to make this investment. By following the guidelines provided here, you can easily migrate your Jetspeed 1.x applications to Jetspeed 2. - For an overview of architectural differences, see the document <a href="j1-users.html">For Jetspeed-1 Users</a></p> -</div> -<div class="section"><h2><a name="Migration_Table"></a>Migration Table</h2> -<p>The table below gives you an idea of how to migrate. We will cover each subject in more detail further on in this document.</p> -<table class="bodyTable"><tr class="a"><th>1.x Feature</th> -<th>2.x Feature</th> -<th>Description</th> -</tr> -<tr class="b"><td>J1 Portlet Java Code</td> -<td>Portlet API Standard Code</td> + For an overview of architectural differences, see the document <a href="j1-users.html">For Jetspeed-1 Users</a></p> +</div> +<div class="section"><h2><a name="Migration_Table"></a>Migration Table</h2> +<p>The table below gives you an idea of how to migrate. We will cover each subject in more detail further on in this document.</p> +<table class="bodyTable"><tr class="a"><th>1.x Feature</th> +<th>2.x Feature</th> +<th>Description</th> +</tr> +<tr class="b"><td>J1 Portlet Java Code</td> +<td>Portlet API Standard Code</td> <td>Rewrite the java code to the new specification. - Involves replacing Turbine action with standard processAction, and replacing Rundata with PortletRequest/Response</td> -</tr> -<tr class="a"><td>XREG Portlet Registry</td> -<td>portlet.xml deployment descriptor</td> + Involves replacing Turbine action with standard processAction, and replacing Rundata with PortletRequest/Response</td> +</tr> +<tr class="a"><td>XREG Portlet Registry</td> +<td>portlet.xml deployment descriptor</td> <td>There are pretty big differences here. Migrate <portlet-entry> to <portlet> entries, <parameter> to <preference> or <init-param> - </td> -</tr> -<tr class="b"><td>J1 PSML</td> -<td>J2 PSML</td> -<td>Migrate Tabs to Folders and Pages, migrate to new tag syntax</td> -</tr> -<tr class="a"><td>XREG Security Registry</td> -<td>Security Constraints</td> -<td>Migrate J1 security constraint format to J2 security constraint format</td> -</tr> -<tr class="b"><td>J1 Controllers</td> -<td>J2 Layouts</td> -<td>Controllers are deprecated. Recommend using the new Jetspeed-2 Layout portlets. If porting necessary, HTML portions of VM code may port, but not context model variables</td> -</tr> -<tr class="a"><td>J1 Controls</td> -<td>J2 Portlet Decorators</td> -<td>Controls are deprecated. Recommend using the new Jetspeed-2 Portlet Decorators. If porting necessary, HTML portions of VM code will port, but not context model variables</td> -</tr> -<tr class="b"><td>J1 Layouts, Screens, Navigations</td> -<td>J2 Page (Layout) Decorators</td> -<td>All deprecated. Recommend using the new Jetspeed-2 Page (Layout) Decorators as a starting point to writing your own page decorators. HTML portions of VM code will port, but not context model variables</td> -</tr> -</table> -</div> -<div class="section"><h2><a name="Portlet_Applications"></a>Portlet Applications</h2> + </td> +</tr> +<tr class="b"><td>J1 PSML</td> +<td>J2 PSML</td> +<td>Migrate Tabs to Folders and Pages, migrate to new tag syntax</td> +</tr> +<tr class="a"><td>XREG Security Registry</td> +<td>Security Constraints</td> +<td>Migrate J1 security constraint format to J2 security constraint format</td> +</tr> +<tr class="b"><td>J1 Controllers</td> +<td>J2 Layouts</td> +<td>Controllers are deprecated. Recommend using the new Jetspeed-2 Layout portlets. If porting necessary, HTML portions of VM code may port, but not context model variables</td> +</tr> +<tr class="a"><td>J1 Controls</td> +<td>J2 Portlet Decorators</td> +<td>Controls are deprecated. Recommend using the new Jetspeed-2 Portlet Decorators. If porting necessary, HTML portions of VM code will port, but not context model variables</td> +</tr> +<tr class="b"><td>J1 Layouts, Screens, Navigations</td> +<td>J2 Page (Layout) Decorators</td> +<td>All deprecated. Recommend using the new Jetspeed-2 Page (Layout) Decorators as a starting point to writing your own page decorators. HTML portions of VM code will port, but not context model variables</td> +</tr> +</table> +</div> +<div class="section"><h2><a name="Portlet_Applications"></a>Portlet Applications</h2> <p>One of the most important differences in writing Jetspeed-2/Portlet API portlets is that you must package your portlet code separate from the Jetspeed portal. In Jetspeed-1, all the user code, the portlet business logic, is packaged in one big war file mixed in with the Jetspeed-1 implementation. The Portlet API clearly abolishes this practice of mixing the portal implementation with @@ -315,39 +315,39 @@ as a portlet application. A portlet application contains one or more portlets, along with a deployment descriptor, the portlet.xml. A portlet application is an extension of a web application. The portlet.xml holds the definitions of one or more portlets and is analogous to the xreg files used in Jetspeed-1. - </p> -</div> -<div class="section"><h2><a name="Java_Code"></a>Java Code</h2> + </p> +</div> +<div class="section"><h2><a name="Java_Code"></a>Java Code</h2> <p>In this section we demonstrate how to convert a Jetspeed-1 portlet to a JSR-168 Java Standard Portlet. This involves the following steps: - </p> -<ul><li>Converting the Portlet Init Java Code</li> -<li>Converting the Portlet getContent Java Code</li> -<li>Converting a Turbine Action</li> -</ul> + </p> +<ul><li>Converting the Portlet Init Java Code</li> +<li>Converting the Portlet getContent Java Code</li> +<li>Converting a Turbine Action</li> +</ul> <p> Jetspeed-1 portlet implementations are normally separated between two different Java source files. - </p> -<ul><li>The Portlet Source Code</li> -<li>The Turbine Action Source Code</li> -</ul> + </p> +<ul><li>The Portlet Source Code</li> +<li>The Turbine Action Source Code</li> +</ul> <p> The Portlet Source Code handles the <b>View</b> part of the MVC pattern. The <b>getContent</b> method is the standard method in Jetspeed-1 to call to render the content of a portlet. The corresponding methods in Jetspeed-2 and in the Portlet API, the <b>doView, doEdit, doHelp</b>. In the Portlet API terminology, this phase of portlet processing is known as the <b>render phase</b>. During the render phase, the portlet should not perform any business logic or other manipulation on the <b>Model</b>. All model manipulation - should be left to the <b>action phase</b></p> + should be left to the <b>action phase</b></p> <p>The Turbine Action performs the <b>action phase</b> of the portlet processing. During the action phase of the Portlet API standard, rendering of all other portlets is blocked until the action completes. This is also true in the Jetspeed-1/Turbine model. - </p> -<div class="section"><h3><a name="Creating_a_new_Portlet_Class"></a>Creating a new Portlet Class</h3> + </p> +<div class="section"><h3><a name="Creating_a_new_Portlet_Class"></a>Creating a new Portlet Class</h3> <p>The best place to get started in migrated your portlet is to create a new JSR-168 standard portlet. Simply create a new Java class inheriting from the GenericPortlet interface provided by the Portlet API. You can also use one of the frameworks or bridges available from Apache Portals or Spring MVC. The example below writes directly to the Portlet API. The code below can be used a skeleton for writing a portlet. - </p> + </p> <div class="source"><pre> import java.io.IOException; @@ -383,35 +383,35 @@ public class HelloWorld extends GenericP } } -</pre> -</div> +</pre> +</div> <p>To find out more about Portals Bridges and other Frameworks, explore these links: - </p> -<ul><li><a href="http://portals.apache.org/bridges/"; class="externalLink">Portals Bridges</a></li> -<li><a href="http://portals.apache.org/bridges/multiproject/portals-bridges-jsf/index.html"; class="externalLink">JSF Bridge</a></li> -<li><a href="http://portals.apache.org/bridges/multiproject/portals-bridges-struts/index.html"; class="externalLink">Struts Bridge</a></li> -<li><a href="http://portals.apache.org/bridges/multiproject/portals-bridges-velocity/index.html"; class="externalLink">Velocity Bridge</a></li> -<li><a href="http://www.springframework.org/docs/reference/portlet.html"; class="externalLink">Spring Portlet MVC</a></li> -</ul> -</div> -<div class="section"><h3><a name="Converting_the_Portlet_Init_Java_Code"></a>Converting the Portlet Init Java Code</h3> + </p> +<ul><li><a class="externalLink" href="http://portals.apache.org/bridges/";>Portals Bridges</a></li> +<li><a class="externalLink" href="http://portals.apache.org/bridges/multiproject/portals-bridges-jsf/index.html";>JSF Bridge</a></li> +<li><a class="externalLink" href="http://portals.apache.org/bridges/multiproject/portals-bridges-struts/index.html";>Struts Bridge</a></li> +<li><a class="externalLink" href="http://portals.apache.org/bridges/multiproject/portals-bridges-velocity/index.html";>Velocity Bridge</a></li> +<li><a class="externalLink" href="http://www.springframework.org/docs/reference/portlet.html";>Spring Portlet MVC</a></li> +</ul> +</div> +<div class="section"><h3><a name="Converting_the_Portlet_Init_Java_Code"></a>Converting the Portlet Init Java Code</h3> <p> The Portlet Source code handles the <b>Init</b> phase of a portlet lifecycle. The init phase is very similar in both the Java Portlet API and in Jetspeed 1. Here we have an example of the init method of a Jetspeed-1 portlet: - </p> + </p> <div class="source"><pre> public void init() throws PortletException { } - </pre> -</div> + </pre> +</div> <p> The equivalent method in the Portlet API (Jetspeed-2) would be, note the difference being the PortletConfig parameter (although the exception classes are named the same, they are entirely different classes, one from Jetspeed-1, the other from the Portlet API): - </p> + </p> <div class="source"><pre> public void init(PortletConfig config) @@ -419,16 +419,16 @@ public class HelloWorld extends GenericP { } - </pre> -</div> -<p>In Jetspeed-1, you would normally access Turbine Services with static acccessors, for example:</p> + </pre> +</div> +<p>In Jetspeed-1, you would normally access Turbine Services with static acccessors, for example:</p> <div class="source"><pre> JetspeedSecurity.addUser(user); -</pre> -</div> -<p>In Jetspeed-2, the standard way to access Jetspeed Services is to get a handle in the init phase, for example:</p> +</pre> +</div> +<p>In Jetspeed-2, the standard way to access Jetspeed Services is to get a handle in the init phase, for example:</p> <div class="source"><pre> private UserManager userManager; @@ -443,24 +443,24 @@ public class HelloWorld extends GenericP } } -</pre> -</div> -</div> -<div class="section"><h3><a name="Converting_the_Portlet_getContent_Java_Code"></a>Converting the Portlet getContent Java Code</h3> +</pre> +</div> +</div> +<div class="section"><h3><a name="Converting_the_Portlet_getContent_Java_Code"></a>Converting the Portlet getContent Java Code</h3> <p> In Jetspeed-1, the <b>getContent</b> method renders the content of your portlet. The render phase of Jetspeed-1 is implemented by the getContent method of your Portlet as defined by the Jetspeed-1 Portlet interface. - </p> + </p> <div class="source"><pre> public ConcreteElement getContent(RunData rundata); -</pre> -</div> -<p>The only parameter passed in to the getContent method is a <b>RunData</b> parameter. RunData is a part of the <a href="http://jakarta.apache.org/turbine/"; class="externalLink">Turbine web framework</a>. +</pre> +</div> +<p>The only parameter passed in to the getContent method is a <b>RunData</b> parameter. RunData is a part of the <a class="externalLink" href="http://jakarta.apache.org/turbine/";>Turbine web framework</a>. RunData is basically a wrapper around the Servlet request and response, along with other Turbine-specific information. When writing portlets for Jetspeed-2, you write to the Portlet API. -</p> +</p> <div class="source"><pre> public void doView(RenderRequest request, RenderResponse response) @@ -469,8 +469,8 @@ throws PortletException, IOException response.setContentType("text/html"); ... -</pre> -</div> +</pre> +</div> <p>The <b>doView</b> method is the Portlet API equivalent of the <b>getContent</b> method of the Jetspeed-1 API. The Portlet API has the concept of <b>portlet modes</b>. There are three default portlet modes <b>view, edit, and help</b>. For each of these modes, there are three methods you can override in your portlet: <b>doView, doEdit and doHelp</b>. @@ -478,21 +478,21 @@ Notice that where the Jetspeed-1 API has the <b>RenderRequest</b> and <b>RenderResponse</b>. One of the biggest parts of migrating your app will be to convert RunData references to RenderRequests and RenderResponses. Before starting, we recommend taking a training course on the Portlet API, or learning the API yourself by reading the Portlet specification as well as any articles or books on the subject. A good book to get started on the Portlet API -is <a href="http://www.manning.com/hepper/"; class="externalLink">Portlets and Apache Portals</a>. -</p> +is <a class="externalLink" href="http://www.manning.com/hepper/";>Portlets and Apache Portals</a>. +</p> <p>When rendering content, Jetspeed 1 makes use of a HTML construction kit called <b>ECS</b>. All rendering goes through Turbine and ECS. The return type of the getContent method is a <b>ConcreteElement</b>, which is defined in the ECS API. Here is the typical way to generate output from a portlet in Jetspeed-1: -</p> +</p> <div class="source"><pre> ... String helloString = "Hello World. This is the portlet output in view mode."; return new org.apache.jetspeed.util.JetspeedClearElement(helloString); -</pre> -</div> -<p>When rendering content in Jetspeed-2, the Portlet API uses a streaming interface:</p> +</pre> +</div> +<p>When rendering content in Jetspeed-2, the Portlet API uses a streaming interface:</p> <div class="source"><pre> response.setContentType("text/html"); @@ -506,26 +506,26 @@ response.getWriter().println(helloString // using Java streaming response.getPortletOutputStream().write(helloString.getBytes()); -</pre> -</div> +</pre> +</div> <p>Of course you can use JSPs or Velocity with either Jetspeed-1 or Jetspeed-2. With Jetspeed-1, the common practice is to make use of the Jetspeed-1 <b>GenericMVCPortlet</b> or one of its derivatives, the <b>VelocityPortlet</b> or the <b>JspPortlet</b>. Both the VelocityPortlet and JspPortlet are really just GenericMVCPortlets. Here is the xreg example of a WeatherPortlet which extends the GenericMVCPortlet by setting its parent to Velocity -</p> +</p> <div class="source"><pre> <portlet-entry name="WeatherPortlet" hidden="false" type="ref" parent="Velocity" application="false"> <parameter name="template" value="weather" hidden="true"/> </portlet-entry> -</pre> -</div> +</pre> +</div> <p>The template parameter is named <b>weather</b>. Since this is a Velocity MVC portlet, Jetspeed-1 knows to look under the <b>WEB-INF/templates/vm/portlets/html</b> directory to find <b>weather.vm</b>. The MVC portlet will automatically handle the details of dispatching to this Velocity template to render your portlet. Here is the actual contents of the velocity template. Note that we don't have to write any portlet Java code in this case, but only the actual template. -</p> +</p> <div class="source"><pre> #if (!$weather_city_info) @@ -536,11 +536,11 @@ target="_blank"><img src alt="Click for ${weather_city_info} Forecast" border="0"></a> #end -</pre> -</div> +</pre> +</div> <p>With Jetspeed-2 and the Portlet API, we can make use of the Velocity Bridge or the JSP Bridge to delegate to portlets. The simplest case is just dispatching the call yourself to the JSP or Velocity servlet. Here is an example of dispatching to a JSP from the doView: -</p> +</p> <div class="source"><pre> protected void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException @@ -552,11 +552,11 @@ protected void doView(RenderRequest requ rd.include(request, response); } -</pre> -</div> +</pre> +</div> <p>And here is an example of the WeatherPortlet extending the Velocity Bridge, and making use of the Portlet API User Preferences feature, note that we do not directly create a dispatcher here, but the framework will do that automatically: -</p> +</p> <div class="source"><pre> import org.apache.portals.bridges.velocity.GenericVelocityPortlet; @@ -587,9 +587,9 @@ public void doView(RenderRequest request super.doView(request, response); } -</pre> -</div> -<p>And here is the Velocity template to render the portlet content:</p> +</pre> +</div> +<p>And here is the Velocity template to render the portlet content:</p> <div class="source"><pre> #if (!$weather_city_info) @@ -600,10 +600,10 @@ target="_blank"><img src alt="Click for $weather_city_info Forecast" border="0"></a> #end -</pre> -</div> -</div> -<div class="section"><h3><a name="Converting_a_Turbine_Action"></a>Converting a Turbine Action</h3> +</pre> +</div> +</div> +<div class="section"><h3><a name="Converting_a_Turbine_Action"></a>Converting a Turbine Action</h3> <p>The Portlet API defines several phases of execution during the processing of a portlet page. The action phase is designed to be executed before the render phase of a portlet. There can only be one action phase targeting only one portlet. Once the action phase completes, then the render phase for all portlets on a page can be executed. Thus the action phase is said to be a <i>blocking</i> phase, meaning that it must @@ -612,18 +612,18 @@ the <i>Model</i> of the MVC framework, s of actions ports fairly well from Turbine and Jetspeed-1 to Jetspeed-2 and the Portlet API. Whereas Turbine has the concept of one class per action, the Portlet API has an entry point for all actions to come through as a method on your portlet. Frameworks such as the Spring MVC framework provide better abstractions for modeling one method per action. -</p> -<p>Lets again look at the WeatherPortlet with Jetspeed-1. First the xreg defines the actions:</p> +</p> +<p>Lets again look at the WeatherPortlet with Jetspeed-1. First the xreg defines the actions:</p> <div class="source"><pre> <parameter name="action" value="portlets.WeatherAction" hidden="true"/> -</pre> -</div> +</pre> +</div> <p> We must then implement the action class which are usually placed in the Jetspeed-1 webapp class loader space. Here is the code for the WeatherAction, which extends a Jetspeed-1 framework class VelocityPortletAction: -</p> +</p> <div class="source"><pre> public class WeatherAction extends VelocityPortletAction @@ -649,60 +649,60 @@ public class WeatherAction extends Veloc context.put(WEATHER_STYLE,style); } -</pre> -</div> +</pre> +</div> <p> In Jetspeed-1 there is some really bad architecture interfering with easily writing portlets. Here in our action, we are actually implementing the <b>View</b> portion of our code by populating the Velocity context with <b>context.put</b> statements. Please beware that all code implemented in the <b>buildNormalContext</b> method should be ported to the <b>doView</b> method of the Portlet API. Note how the actual portlet must be passed in as the first parameter to the buildNormalContext method. -</p> +</p> <p>The actual action code implemented as <b>do..</b> methods on your action class will need to be ported to the <b>processAction</b> method on the Portlet API. -</p> +</p> <div class="source"><pre> public void doInsert(RunData rundata, Context context) throws Exception { -</pre> -</div> +</pre> +</div> <p>The <b>doInsert</b> method is linked by Turbine to an action in the Velocity template with the <b>eventSubmit_</b> prefix: -</p> +</p> <div class="source"><pre> <input type="submit" name="eventSubmit_doInsert" value="${l10n.USER_FORM_ADD_USER_VM}"/> -</pre> -</div> -<p>Here is the equivalent in the Portlet API (Jetspeed-2):</p> +</pre> +</div> +<p>Here is the equivalent in the Portlet API (Jetspeed-2):</p> <div class="source"><pre> public void processAction(ActionRequest actionRequest, ActionResponse actionResponse) throws PortletException, IOException -</pre> -</div> -<p>The Portlet API provides two parameters to the processAction method: the ActionRequest and ActionResponse.</p> -</div> -<div class="section"><h3><a name="Request_Parameters_Portlet_Modes_Window_States"></a>Request Parameters, Portlet Modes, Window States</h3> -<p>Request parameters are accessed via RunData in Jetspeed-1:</p> +</pre> +</div> +<p>The Portlet API provides two parameters to the processAction method: the ActionRequest and ActionResponse.</p> +</div> +<div class="section"><h3><a name="Request_Parameters_Portlet_Modes_Window_States"></a>Request Parameters, Portlet Modes, Window States</h3> +<p>Request parameters are accessed via RunData in Jetspeed-1:</p> <div class="source"><pre> String name = rundata.getParameters().getString("username"); -</pre> -</div> -<p>With the Portlet API, portlet request parameters are accessed via the ActionRequest:</p> +</pre> +</div> +<p>With the Portlet API, portlet request parameters are accessed via the ActionRequest:</p> <div class="source"><pre> String name = actionRequest.getParameter("username"); -</pre> -</div> -<p>With the Portlet API, you can check the Portlet Mode or Window State:</p> +</pre> +</div> +<p>With the Portlet API, you can check the Portlet Mode or Window State:</p> <div class="source"><pre> if (actionRequest.getPortletMode() == PortletMode.EDIT) @@ -711,12 +711,12 @@ to the <b>processAction</b> method on th { ... -</pre> -</div> +</pre> +</div> <p>The basic Portlet API does not have a way to map actions to methods as in Jetspeed-1. - If you would like this kind of behavior, we recommend using the <a href="http://www.springframework.org/docs/reference/portlet.html"; class="externalLink">Spring MVC Portlet framework</a> + If you would like this kind of behavior, we recommend using the <a class="externalLink" href="http://www.springframework.org/docs/reference/portlet.html";>Spring MVC Portlet framework</a> Here we demonstrate using portlet request parameters per form to map to specific actions: - </p> + </p> <div class="source"><pre> String action = actionRequest.getParameter(SecurityResources.PORTLET_ACTION); @@ -734,28 +734,28 @@ to the <b>processAction</b> method on th } ... -</pre> -</div> -</div> -<div class="section"><h3><a name="Persisting_State:_The_Portlet_Session"></a>Persisting State: The Portlet Session</h3> +</pre> +</div> +</div> +<div class="section"><h3><a name="Persisting_State:_The_Portlet_Session"></a>Persisting State: The Portlet Session</h3> <p>The Portlet API provides built-in support for persistence of Portlet state in the session. The Portlet Session is similar to the <b>setTemp</b> methods in Turbine/Jetspeed-1, or the session support built into the Servlet API. The Session is for persisting state associated with the current user session. There are two kinds of session state supported by the Portlet API: - </p> -<ul><li>Application Session State: the session variable is shared by all portlets in a portlet application</li> -<li>Portlet Session State: the session variable is specific to the one portlet instance window</li> -</ul> + </p> +<ul><li>Application Session State: the session variable is shared by all portlets in a portlet application</li> +<li>Portlet Session State: the session variable is specific to the one portlet instance window</li> +</ul> <p>Here is how we would get and set session information in Jetspeed-1, using the Turbine RunData API. Note that for both Jetspeed-1 and Jetspeed-2, the - object put in the session must be serializable:</p> + object put in the session must be serializable:</p> <div class="source"><pre> rundata.getUser().setTemp(ACCOUNT_INFO, accountInfo); ... AccountInfo accountInfo = (AccountInfo)rundata.getUser().getTemp(ACCOUNT_INFO); -</pre> -</div> -<p>In here is the equivalent in Jetspeed-2 using the Portlet API:</p> +</pre> +</div> +<p>In here is the equivalent in Jetspeed-2 using the Portlet API:</p> <div class="source"><pre> AccountInfo accountInfo = (AccountInfo) @@ -770,23 +770,23 @@ to the <b>processAction</b> method on th -- or -- session.setAttribute(ACCOUNT_INFO, accountInfo, PortletSession.APPLICATION_SCOPE); -</pre> -</div> -</div> -<div class="section"><h3><a name="Persisting_State:_User_Preferences"></a>Persisting State: User Preferences</h3> +</pre> +</div> +</div> +<div class="section"><h3><a name="Persisting_State:_User_Preferences"></a>Persisting State: User Preferences</h3> <p>The Portlet API provides a second persistence mechanism: User Preferences. User Preferences are fields of information stored on a per user/per portlet window basis. The equivalent in Jetspeed-1 is Portlet Instance data, which is stored in the Jetspeed-1 Portlet Registry as name/value pair <b>parameter</b> XML elements. Looking at the XREG file in Jetspeed-1, we have: - </p> + </p> <div class="source"><pre> <parameter name="weather_city_info" value="US/IN/Bloomington" hidden="true"/> -</pre> -</div> +</pre> +</div> <p>The Portlet API allows you to define default values for preferences in the portlet.xml deployment descriptor. The user-specific values are stored in the Jetspeed Preferences database. Here is an example of the default value for a preference as it would be defined in the deployment descriptor: - </p> + </p> <div class="source"><pre> <preference> @@ -794,14 +794,14 @@ to the <b>processAction</b> method on th <value>Oakland</value> </preference> -</pre> -</div> +</pre> +</div> <p>Jetspeed-1 provides the <b>PortletInstance</b> interface on every portlet for accessing preference-like information. Whereas the preference information is per-user and per-instance in Jetspeed-2, in Jetspeed-1 preference information accessed via the PortletInstance interface is only per-instance(per PortletWindow) specific. These values are stored in the PSML file associated with the PortletWindow. Please note that the values can still be <i>user-specific</i> when you are using the default mechanism for locating pages, which is by user. This means that in Jetspeed-1 preferences (or parameters) are made user-specific by the nature of how pages are retrieved. Since a page is located under a user home directory, then the preference is naturally per user. - </p> -<p>With Jetspeed-1, here we can retrieve PortletInstance data:</p> + </p> +<p>With Jetspeed-1, here we can retrieve PortletInstance data:</p> <div class="source"><pre> // where "this" is a Jetspeed-1 Portlet object @@ -816,10 +816,10 @@ to the <b>processAction</b> method on th -- or -- this.setAttribute("favoriteColor", "red", rundata); -</pre> -</div> +</pre> +</div> <p>With the Portlet API in Jetspeed-2, we can use the Portlet Preferences in a more direct manner. - Remember that the store() method must always be called after all modifications to the prefs during a request:</p> + Remember that the store() method must always be called after all modifications to the prefs during a request:</p> <div class="source"><pre> PortletPreferences prefs = actionRequest.getPreferences(); @@ -834,455 +834,455 @@ to the <b>processAction</b> method on th // or retrieve all preferences as a Map Map allPrefs = actionRequest.getPreferences().getMap(); -</pre> -</div> -</div> -</div> -<div class="section"><h2><a name="Registries"></a>Registries</h2> -<p>The Jetspeed-1 Registries hold the following information:</p> -<ul><li>Portlet Definitions</li> -<li>Security Definitions</li> -<li>Web Clients and Media Type Registries</li> -<li>Skins Definitions</li> -<li>Controller Definitions</li> -<li>Control Definitions</li> -</ul> -<p>This section will guide you through how to migrate each of these registries from Jetspeed-1 to Jetspeed-2</p> -<div class="section"><h3><a name="Portlet_Definitions"></a>Portlet Definitions</h3> +</pre> +</div> +</div> +</div> +<div class="section"><h2><a name="Registries"></a>Registries</h2> +<p>The Jetspeed-1 Registries hold the following information:</p> +<ul><li>Portlet Definitions</li> +<li>Security Definitions</li> +<li>Web Clients and Media Type Registries</li> +<li>Skins Definitions</li> +<li>Controller Definitions</li> +<li>Control Definitions</li> +</ul> +<p>This section will guide you through how to migrate each of these registries from Jetspeed-1 to Jetspeed-2</p> +<div class="section"><h3><a name="Portlet_Definitions"></a>Portlet Definitions</h3> <p>Jetpeed-1 requires that all portlets are defined in an XML file known as an XREG file (XML Registry). Jetspeed-2 stores its portlet registry in the database. In Jetspeed-1, the XML registry is on the file system under the jetspeed webapp under WEB-INF/conf. There can be one or more portlet registry entries. All portlets are defined with the element type <b>portlet-entry</b>. - </p> + </p> <p>Migrating your Jetspeed-1 portlet registries to Jetspeed-2 registries requires writing a new Portlet API standard <b>portlet.xml</b> definition file. We do not provide an XSLT transform to do this for you. Whereas the portlet.xml is defined by the Java Standard Portlet API, Jetspeed allows for additional information to be defined specific to the Jetspeed portal: the <b>jetspeed-portlet.xml</b> can hold Jetspeed-specific deployment configurations. Some of the XREG elements map to the portlet.xml, whereas others will map to the jetspeed-portlet.xml as noted in the tables below. The table below describes how to map each XML attribute of the <b>portlet-entry</b> element to its equivalent in the Portlet API portlet.xml or jetspeed-portlet.xml. Note that we are mapping in this table from XML attributes to XML elements in the portlet.xml or jetspeed-portlet.xml: - </p> -<table class="bodyTable"><tr class="a"><th>J1 Attribute</th> -<th>J2 Element</th> -<th></th> -</tr> -<tr class="b"><td>name</td> -<td>portlet-name</td> -<td>The name of the portlet. This name is unique to each portlet application, but not unique system-wide.</td> -</tr> -<tr class="a"><td>hidden</td> -<td></td> -<td>No equivalent in the Portlet API, not applicable.</td> -</tr> -<tr class="b"><td>type</td> -<td></td> -<td>No equivalent in the Portlet API, not applicable.</td> -</tr> -<tr class="a"><td>parent</td> -<td></td> -<td>No equivalent in the Portlet API, not applicable.</td> -</tr> -<tr class="b"><td>application</td> -<td></td> -<td>No equivalent in the Portlet API, not applicable.</td> -</tr> -</table> + </p> +<table class="bodyTable"><tr class="a"><th>J1 Attribute</th> +<th>J2 Element</th> +<th></th> +</tr> +<tr class="b"><td>name</td> +<td>portlet-name</td> +<td>The name of the portlet. This name is unique to each portlet application, but not unique system-wide.</td> +</tr> +<tr class="a"><td>hidden</td> +<td></td> +<td>No equivalent in the Portlet API, not applicable.</td> +</tr> +<tr class="b"><td>type</td> +<td></td> +<td>No equivalent in the Portlet API, not applicable.</td> +</tr> +<tr class="a"><td>parent</td> +<td></td> +<td>No equivalent in the Portlet API, not applicable.</td> +</tr> +<tr class="b"><td>application</td> +<td></td> +<td>No equivalent in the Portlet API, not applicable.</td> +</tr> +</table> <p> Continuing with the Portlet XREG conversion, lets now look at how to convert the XML elements of the <b>portlet-entry</b> element. The table below describes how to map each XML element to its equivalent in the Portlet API portlet.xml: - </p> -<table class="bodyTable"><tr class="a"><th>J1 Element</th> -<th>J2 Element</th> -<th></th> -</tr> -<tr class="b"><td>classname</td> -<td>portlet-class</td> -<td>The implementing Java class. This class will need to be ported at the source level.</td> -</tr> -<tr class="a"><td>media-type</td> -<td>supports, supports/mime-type, supports/portlet-mode</td> -<td>Media types supported by the portlet must be mapped to one or more <i>supports</i> elements, with subelements of <i>mime-type</i> and <i>portlet-mode</i> pairs.</td> -</tr> -<tr class="b"><td>meta-info/title</td> -<td>title</td> -<td>The title of the Portlet.</td> -</tr> -<tr class="a"><td>meta-info/description</td> -<td>description</td> -<td>The description of the portlet</td> -</tr> -<tr class="b"><td>category</td> -<td>portlet-info/keywords</td> -<td>Where there are multiple categories elements, keywords are comma-separated. In Jetspeed-2, you can configure categories in the Portlet-Selector administrative portlet based on keywords.</td> -</tr> -<tr class="a"><td>security-ref</td> -<td>jetspeed-portlet.xml: js:security-constraint-ref</td> -<td>If you port your Security constraints definitions, you can keep the same security definition names. Just note that security constraint definitions are referenced from the jetspeed-portlet.xml, not portlet.xml</td> -</tr> -<tr class="b"><td>parameter</td> -<td>init-param</td> -<td>Parameters in Jetspeed-1 should normally map to <i>init-param</i>s in the Portlet API. These are read only values that can only be changed by the administrator</td> -</tr> -<tr class="a"><td>parameter@name</td> -<td>init-param/name</td> -<td>The name of the init parameter</td> -</tr> -<tr class="b"><td>parameter@value</td> -<td>init-param/value</td> -<td>The value of the init parameter</td> -</tr> -<tr class="a"><td>parameter/meta-info/description</td> -<td>init-param/description</td> -<td>The description of the init parameter</td> -</tr> -<tr class="b"><td>parameter</td> -<td>portlet-preferences/preference</td> -<td>As well as migrating to init-params, parameters may also be migrated as default preferences. Note that preferences can optionally be read-only.</td> -</tr> -<tr class="a"><td>parameter@name</td> -<td>portlet-preferences/preference/name</td> -<td>The name of the preference</td> -</tr> -<tr class="b"><td>parameter@value</td> -<td>portlet-preferences/preference/value</td> -<td>The value of the preference</td> -</tr> -<tr class="a"><td>parameter@hidden</td> -<td>portlet-preferences/preference/read-only</td> -<td>Optionally you map want to map hidden values to read-only (true/false)</td> -</tr> -</table> -</div> -<div class="section"><h3><a name="Security_Definitions"></a>Security Definitions</h3> + </p> +<table class="bodyTable"><tr class="a"><th>J1 Element</th> +<th>J2 Element</th> +<th></th> +</tr> +<tr class="b"><td>classname</td> +<td>portlet-class</td> +<td>The implementing Java class. This class will need to be ported at the source level.</td> +</tr> +<tr class="a"><td>media-type</td> +<td>supports, supports/mime-type, supports/portlet-mode</td> +<td>Media types supported by the portlet must be mapped to one or more <i>supports</i> elements, with subelements of <i>mime-type</i> and <i>portlet-mode</i> pairs.</td> +</tr> +<tr class="b"><td>meta-info/title</td> +<td>title</td> +<td>The title of the Portlet.</td> +</tr> +<tr class="a"><td>meta-info/description</td> +<td>description</td> +<td>The description of the portlet</td> +</tr> +<tr class="b"><td>category</td> +<td>portlet-info/keywords</td> +<td>Where there are multiple categories elements, keywords are comma-separated. In Jetspeed-2, you can configure categories in the Portlet-Selector administrative portlet based on keywords.</td> +</tr> +<tr class="a"><td>security-ref</td> +<td>jetspeed-portlet.xml: js:security-constraint-ref</td> +<td>If you port your Security constraints definitions, you can keep the same security definition names. Just note that security constraint definitions are referenced from the jetspeed-portlet.xml, not portlet.xml</td> +</tr> +<tr class="b"><td>parameter</td> +<td>init-param</td> +<td>Parameters in Jetspeed-1 should normally map to <i>init-param</i>s in the Portlet API. These are read only values that can only be changed by the administrator</td> +</tr> +<tr class="a"><td>parameter@name</td> +<td>init-param/name</td> +<td>The name of the init parameter</td> +</tr> +<tr class="b"><td>parameter@value</td> +<td>init-param/value</td> +<td>The value of the init parameter</td> +</tr> +<tr class="a"><td>parameter/meta-info/description</td> +<td>init-param/description</td> +<td>The description of the init parameter</td> +</tr> +<tr class="b"><td>parameter</td> +<td>portlet-preferences/preference</td> +<td>As well as migrating to init-params, parameters may also be migrated as default preferences. Note that preferences can optionally be read-only.</td> +</tr> +<tr class="a"><td>parameter@name</td> +<td>portlet-preferences/preference/name</td> +<td>The name of the preference</td> +</tr> +<tr class="b"><td>parameter@value</td> +<td>portlet-preferences/preference/value</td> +<td>The value of the preference</td> +</tr> +<tr class="a"><td>parameter@hidden</td> +<td>portlet-preferences/preference/read-only</td> +<td>Optionally you map want to map hidden values to read-only (true/false)</td> +</tr> +</table> +</div> +<div class="section"><h3><a name="Security_Definitions"></a>Security Definitions</h3> <p>Jetspeed-1 supports a Security Constraint XML definition language that is very similiar to the XML security constraint definitions in Jetspeed-2. Jetpeed-1 requires that all security definitions are defined in an XML file known as an XREG file (XML Registry). Jetspeed-2 stores its security registry either in an XML file or in the database. In Jetspeed-1, the XML registry is on the file system under the jetspeed webapp under WEB-INF/conf. There can be one or more security registry entries. All security constraints are defined with the element type <b>security-entry</b>. - </p> + </p> <p>Migrating your Jetspeed-1 security constraints registries to Jetspeed-2 registries requires writing a new <b>page.security</b> XML definition file. We do not provide an XSLT transform to do this for you. The table below describes how to map each XML attribute of the <b>security-entry</b> element to its equivalent in the Portlet API portlet.xml or jetspeed-portlet.xml. Note that we are mapping in this table from XML attributes to XML elements in the portlet.xml or jetspeed-portlet.xml: - </p> -<table class="bodyTable"><tr class="b"><th>J1 Attribute</th> -<th>J2 Attribute</th> -<th></th> -</tr> -<tr class="a"><td>security-entry@name</td> -<td>security-constraints-def@name</td> -<td>The name of the security constraint definition. This name is unique to the entire page.security file.</td> -</tr> -<tr class="b"><td>meta-info/title</td> -<td></td> -<td>No equivalent in Jetspeed-2, not applicable.</td> -</tr> -<tr class="a"><td>meta-info/description</td> -<td></td> -<td>No equivalent in Jetspeed-2, not applicable.</td> -</tr> -<tr class="b"><td>access</td> -<td>security-constraint</td> -<td>Jetspeed-1 security-entries contain 0..n <i>access</i> elements, Jetspeed-2 security-constraint-defs contain 0..n <i>security-constraint</i> elements.</td> -</tr> -<tr class="a"><td>access@action</td> -<td>security-constraint/permissions</td> + </p> +<table class="bodyTable"><tr class="b"><th>J1 Attribute</th> +<th>J2 Attribute</th> +<th></th> +</tr> +<tr class="a"><td>security-entry@name</td> +<td>security-constraints-def@name</td> +<td>The name of the security constraint definition. This name is unique to the entire page.security file.</td> +</tr> +<tr class="b"><td>meta-info/title</td> +<td></td> +<td>No equivalent in Jetspeed-2, not applicable.</td> +</tr> +<tr class="a"><td>meta-info/description</td> +<td></td> +<td>No equivalent in Jetspeed-2, not applicable.</td> +</tr> +<tr class="b"><td>access</td> +<td>security-constraint</td> +<td>Jetspeed-1 security-entries contain 0..n <i>access</i> elements, Jetspeed-2 security-constraint-defs contain 0..n <i>security-constraint</i> elements.</td> +</tr> +<tr class="a"><td>access@action</td> +<td>security-constraint/permissions</td> <td> Actions in Jetspeed-1 are called Permissions in Jetspeed-2. Both versions support wildcarding with the * character. - <ul><li>Jetspeed-1 default actions are view, customize, maximize, minimize, info, close.</li> -<li>Jetspeed-2 default permissions are view, edit, help, print</li> -</ul> -</td> -</tr> -<tr class="b"><td>access/allow-if@role</td> -<td>security-constraint/roles</td> + <ul><li>Jetspeed-1 default actions are view, customize, maximize, minimize, info, close.</li> +<li>Jetspeed-2 default permissions are view, edit, help, print</li> +</ul> +</td> +</tr> +<tr class="b"><td>access/allow-if@role</td> +<td>security-constraint/roles</td> <td>Jetspeed-1 constrains by role through <i>allow-if</i> elements with a <i>role</i> attribute. - Jetspeed-2 constrains by role with the <i>roles</i> element and a comma-separated list of one or more roles</td> -</tr> -<tr class="a"><td>access/allow-if@group</td> -<td>security-constraint/groups</td> + Jetspeed-2 constrains by role with the <i>roles</i> element and a comma-separated list of one or more roles</td> +</tr> +<tr class="a"><td>access/allow-if@group</td> +<td>security-constraint/groups</td> <td>Jetspeed-1 constrains by group through <i>allow-if</i> elements with a <i>group</i> attribute. - Jetspeed-2 constrains by group with the <i>groups</i> element and a comma-separated list of one or more groups</td> -</tr> -<tr class="b"><td>access/allow-if@user</td> -<td>security-constraint/users</td> + Jetspeed-2 constrains by group with the <i>groups</i> element and a comma-separated list of one or more groups</td> +</tr> +<tr class="b"><td>access/allow-if@user</td> +<td>security-constraint/users</td> <td>Jetspeed-1 constrains by user through <i>allow-if</i> elements with a <i>user</i> attribute. - Jetspeed-2 constrains by user with the <i>users</i> element and a comma-separated list of one or more users, or the wildcard * to specify all users.</td> -</tr> -<tr class="a"><td>access/allow-if-owner</td> -<td>security-constraints/owner</td> + Jetspeed-2 constrains by user with the <i>users</i> element and a comma-separated list of one or more users, or the wildcard * to specify all users.</td> +</tr> +<tr class="a"><td>access/allow-if-owner</td> +<td>security-constraints/owner</td> <td>You can set the constraint to be only accessible by the owner of the page. In Jetspeed-1, this is implied by the location of the page. - With Jetspeed-2 you must explicity name the owner in the element text of the owner element.</td> -</tr> -</table> -</div> -<div class="section"><h3><a name="Web_Clients_and_Media_Type_Registries"></a>Web Clients and Media Type Registries</h3> + With Jetspeed-2 you must explicity name the owner in the element text of the owner element.</td> +</tr> +</table> +</div> +<div class="section"><h3><a name="Web_Clients_and_Media_Type_Registries"></a>Web Clients and Media Type Registries</h3> <p>The Web Clients and Media Type registries are already ported to Jetspeed-2 and a part of the core system. Jetspeed-2 stores these registries in the database. However these tables can be populated using seed data - as described in the section below on seed data.</p> -</div> -<div class="section"><h3><a name="Skins"></a>Skins</h3> + as described in the section below on seed data.</p> +</div> +<div class="section"><h3><a name="Skins"></a>Skins</h3> <p>The Skin registries are not directly portable to Jetspeed-2. Jetspeed-2 has moved towards a more standard CSS based skinning approach. There are two basic skinning techniques which can be combined: - </p> -<ul><li>1. Portlet API Standard Skins - see PLT.C of the portlet specification. A standard set of CSS styles are defined for global skinning of portlet content.</li> -<li>2. Jetspeed Decorators - Decorators can define their own skins which can then be leveraged by portlets by accessing these styles. The default decorators in Jetspeed also define the PLT.C styles as well</li> -</ul> -</div> -<div class="section"><h3><a name="Controllers"></a>Controllers</h3> + </p> +<ul><li>1. Portlet API Standard Skins - see PLT.C of the portlet specification. A standard set of CSS styles are defined for global skinning of portlet content.</li> +<li>2. Jetspeed Decorators - Decorators can define their own skins which can then be leveraged by portlets by accessing these styles. The default decorators in Jetspeed also define the PLT.C styles as well</li> +</ul> +</div> +<div class="section"><h3><a name="Controllers"></a>Controllers</h3> <p>Controllers are deprecated in Jetspeed-2. There is no direct mapping for converting the Java code. Instead you will need to rewrite a new Layout portlet, or more likely simply use one of the existing Layout Portlets that come with Jetspeed, which are quite flexible. The default layout portlets in Jetspeed support multi-column grids, nesting portlets, and complete customization using the Portlet Customizer. - </p> -</div> -<div class="section"><h3><a name="Controls"></a>Controls</h3> + </p> +</div> +<div class="section"><h3><a name="Controls"></a>Controls</h3> <p>Controls are deprecated in Jetspeed-2. There is no direct mapping for converting the Java code. Instead you will need to rewrite a new Portlet decorator, or more likely simply use one of the existing Portlet decorators that come with Jetspeed, which are quite flexible. - </p> -</div> -</div> -<div class="section"><h2><a name="PSML"></a>PSML</h2> -<div class="section"><h3><a name="The_Jetspeed_Sitemap"></a>The Jetspeed Sitemap</h3> + </p> +</div> +</div> +<div class="section"><h2><a name="PSML"></a>PSML</h2> +<div class="section"><h3><a name="The_Jetspeed_Sitemap"></a>The Jetspeed Sitemap</h3> <p>The Jetspeed Sitemap defines the navigational space of all pages in the portal. Both versions 1 and 2 have similiar hiearchical file system-like site maps. Both contain a root folder /, which in turn contains a tree of subfolders, where each subfolder - can contain pages or more subfolders.</p> -</div> -<div class="section"><h3><a name="Site_Resources"></a>Site Resources</h3> + can contain pages or more subfolders.</p> +</div> +<div class="section"><h3><a name="Site_Resources"></a>Site Resources</h3> <p>In Jetspeed-2, there is a well-defined portal resources that do not always have equivalents in Jetspeed-1: - <table class="bodyTable"><tr class="b"><th>2.x</th> -<th>1.x</th> -<th>File</th> -</tr> -<tr class="a"><td>Page</td> -<td>Page</td> -<td>A <b>.psml</b> file.</td> -</tr> -<tr class="b"><td>Folder</td> -<td>--</td> -<td>A <b>folder.metadata</b> file, one per folder, N/A in Jetspeed-1</td> -</tr> -<tr class="a"><td>Link</td> -<td>--</td> -<td>A <b>.link</b> file, N/A in Jetspeed-1</td> -</tr> -<tr class="b"><td>Menu</td> -<td>--</td> -<td>Menus are defined in folder.metadata, N/A in Jetspeed-1</td> -</tr> -</table> -</p> -</div> -<div class="section"><h3><a name="Reserved_Directories"></a>Reserved Directories</h3> + <table class="bodyTable"><tr class="b"><th>2.x</th> +<th>1.x</th> +<th>File</th> +</tr> +<tr class="a"><td>Page</td> +<td>Page</td> +<td>A <b>.psml</b> file.</td> +</tr> +<tr class="b"><td>Folder</td> +<td>--</td> +<td>A <b>folder.metadata</b> file, one per folder, N/A in Jetspeed-1</td> +</tr> +<tr class="a"><td>Link</td> +<td>--</td> +<td>A <b>.link</b> file, N/A in Jetspeed-1</td> +</tr> +<tr class="b"><td>Menu</td> +<td>--</td> +<td>Menus are defined in folder.metadata, N/A in Jetspeed-1</td> +</tr> +</table> +</p> +</div> +<div class="section"><h3><a name="Reserved_Directories"></a>Reserved Directories</h3> <p>There are reserved directories available in both versions. The naming is a little different. Any directory starting with an underscore (_) in Jetspeed-2 is considered a control directory and can be used by the profiler (see below) to locate special directories based on runtime criteria such as the user name or the roles of the user. Jetspeed-1 has a hard-coded set of reserved (control) directories that are hard-coded into the profiling rules. - </p> -<table class="bodyTable"><tr class="a"><th>1.x</th> -<th>2.x</th> -<th></th> -</tr> -<tr class="b"><td>user</td> -<td>_user</td> -<td>Holds all user folders</td> -</tr> -<tr class="a"><td>role</td> -<td>_role</td> -<td>Holds all role folders</td> -</tr> -<tr class="b"><td>group</td> -<td>_group</td> -<td>Holds all group folders</td> -</tr> -<tr class="a"><td>{mediatype}</td> -<td>_mediatype</td> -<td>Content per mime/mediatype</td> -</tr> -<tr class="b"><td>{language}</td> -<td>_lanaguage</td> -<td>Content per language</td> -</tr> -<tr class="a"><td>{country}</td> -<td>_country</td> -<td>Content per country code</td> -</tr> -</table> + </p> +<table class="bodyTable"><tr class="a"><th>1.x</th> +<th>2.x</th> +<th></th> +</tr> +<tr class="b"><td>user</td> +<td>_user</td> +<td>Holds all user folders</td> +</tr> +<tr class="a"><td>role</td> +<td>_role</td> +<td>Holds all role folders</td> +</tr> +<tr class="b"><td>group</td> +<td>_group</td> +<td>Holds all group folders</td> +</tr> +<tr class="a"><td>{mediatype}</td> +<td>_mediatype</td> +<td>Content per mime/mediatype</td> +</tr> +<tr class="b"><td>{language}</td> +<td>_lanaguage</td> +<td>Content per language</td> +</tr> +<tr class="a"><td>{country}</td> +<td>_country</td> +<td>Content per country code</td> +</tr> +</table> <p> Where the J1 directory names are actually the names of the reserved directory, such as {mediatype} would be actually <b>html</b> or {language} would be <b>en</b>. J2 requires - specifing control directories (_) such as <b>_mediatype/html</b>, or <b>_language/en</b></p> -</div> -<div class="section"><h3><a name="Profiling"></a>Profiling</h3> + specifing control directories (_) such as <b>_mediatype/html</b>, or <b>_language/en</b></p> +</div> +<div class="section"><h3><a name="Profiling"></a>Profiling</h3> <p>The Profiling algorithm discovers the correct page to display during a request. - J1 has only two hard-coded algorithm for finding pages:</p> -<ul><li>J1 user/mediatype/language/country fallback</li> -<li>J1 rollback</li> -</ul> + J1 has only two hard-coded algorithm for finding pages:</p> +<ul><li>J1 user/mediatype/language/country fallback</li> +<li>J1 rollback</li> +</ul> <p>Note that these settings are system wide and must be changed on a per portal basis. J1 expects an explicit container order of mediatype / language / country - </p> + </p> <p> J2 has a profiling rules engine that takes dynamic runtime user information, and using profiling rules discovers the rules based on the algorithm defined in the rules. In J2 profiling rules are defined on a per user basis, although there is a system-wide default profiling rule. - </p> -</div> -<div class="section"><h3><a name="Differences_in_PSML_Page"></a>Differences in PSML Page</h3> + </p> +</div> +<div class="section"><h3><a name="Differences_in_PSML_Page"></a>Differences in PSML Page</h3> <p>Jetpeed-1 requires that all portlets are defined in an XML file known as an XREG file (XML Registry). Jetspeed-2 stores its portlet registry in the database. In Jetspeed-1, PSML files can be stored under the jetspeed webapp under WEB-INF/psml. Or, Jetspeed-1 supports storing PSML files in the database. In Jetspeed-2, PSML files can be stored under the jetspeed webapp under WEB-INF/pages or WEB-INF/min-pages. Or, Jetspeed-2 supports storing PSML files in the database. - </p> + </p> <p>Migrating your Jetspeed-1 PSML files to Jetspeed-2 PSML files requires porting the files manually, or writing a database conversion utility or XSLT transform. We do not provide an XSLT transform to do this for you. The table below describes how to map each XML element or attribute from Jetspeed-1 to Jetspeed-2: - </p> -<table class="bodyTable"><tr class="b"><th>J1 Element</th> -<th>J2 Element</th> -<th></th> -</tr> -<tr class="a"><td>portlets</td> -<td>page</td> -<td>The outermost container of all content found on a PSML page.</td> -</tr> -<tr class="b"><td>portlets@id</td> -<td>page@id</td> -<td>System wide unique identifier for this page.</td> -</tr> -<tr class="a"><td>metainfo/title</td> -<td>title</td> -<td>The Page Title.</td> -</tr> -<tr class="b"><td>security-ref</td> -<td>security-constraints/security-constraints-ref</td> -<td>The security constraint reference (0..1 in Jetspeed-1, 0..n in Jetspeed-2)</td> -</tr> -<tr class="a"><td>control</td> -<td>defaults/portlet-decorator</td> -<td>Requires porting your controls to J2 portlet decorators, or at least mapping the names to existing decorators in Jetspeed-2. Or you can use a global portlet decorator and ignore this optional setting.</td> -</tr> -<tr class="b"><td>controller</td> -<td>defaults/layout-decorator</td> + </p> +<table class="bodyTable"><tr class="b"><th>J1 Element</th> +<th>J2 Element</th> +<th></th> +</tr> +<tr class="a"><td>portlets</td> +<td>page</td> +<td>The outermost container of all content found on a PSML page.</td> +</tr> +<tr class="b"><td>portlets@id</td> +<td>page@id</td> +<td>System wide unique identifier for this page.</td> +</tr> +<tr class="a"><td>metainfo/title</td> +<td>title</td> +<td>The Page Title.</td> +</tr> +<tr class="b"><td>security-ref</td> +<td>security-constraints/security-constraints-ref</td> +<td>The security constraint reference (0..1 in Jetspeed-1, 0..n in Jetspeed-2)</td> +</tr> +<tr class="a"><td>control</td> +<td>defaults/portlet-decorator</td> +<td>Requires porting your controls to J2 portlet decorators, or at least mapping the names to existing decorators in Jetspeed-2. Or you can use a global portlet decorator and ignore this optional setting.</td> +</tr> +<tr class="b"><td>controller</td> +<td>defaults/layout-decorator</td> <td>Requires porting your Turbine controllers, screens navigations to J2 layout(page) decorators, or at least mapping the names to existing page decorators in Jetspeed-2. - Or you can use a global portlet decorator and ignore this optional setting.</td> -</tr> -<tr class="a"><td>portlets/portlets/...</td> -<td>page/fragment/..., type="layout"</td> -<td>Sub-containers of fragments or portlets. In Jetspeed-2, fragments can be either containers or portlet definitions. Only fragments with the type of <b>layout</b> can be a container holding more fragments and containers.</td> -</tr> -<tr class="b"><td>portlets/portlets/controller</td> -<td>page/fragment@type=layout@name={layout-name}</td> -<td>Controllers roughly map to fragments of type = layout, named by the name attribute. Note that layouts are implemented as portlets and must be specified as PA::portlet-name.</td> -</tr> -<tr class="a"><td>portlets/entry</td> -<td>page/fragment/fragment@type="portlet"</td> -<td>A portlet window on a page.</td> -</tr> -<tr class="b"><td>entry@id</td> -<td>fragment@id</td> -<td>The system-wide unique ID of the portlet window.</td> -</tr> -<tr class="a"><td>entry@parent</td> -<td>fragment@name</td> -<td>The portlet registry reference. In Jetspeed-2 the name of the portlet must be specified as PA::portlet-name</td> -</tr> -<tr class="b"><td>entry/layout/property@name="column"@value={column}</td> -<td>fragment/property@name="column"@value={column}</td> -<td>The property containing the column position</td> -</tr> -<tr class="a"><td>entry/layout/property@name="row"@value={row}</td> -<td>fragment/property@name="row"@value={row}</td> -<td>The property containing the row position</td> -</tr> -</table> -</div> -<div class="section"><h3><a name="Menus_vs_Tabs"></a>Menus vs Tabs</h3> + Or you can use a global portlet decorator and ignore this optional setting.</td> +</tr> +<tr class="a"><td>portlets/portlets/...</td> +<td>page/fragment/..., type="layout"</td> +<td>Sub-containers of fragments or portlets. In Jetspeed-2, fragments can be either containers or portlet definitions. Only fragments with the type of <b>layout</b> can be a container holding more fragments and containers.</td> +</tr> +<tr class="b"><td>portlets/portlets/controller</td> +<td>page/fragment@type=layout@name={layout-name}</td> +<td>Controllers roughly map to fragments of type = layout, named by the name attribute. Note that layouts are implemented as portlets and must be specified as PA::portlet-name.</td> +</tr> +<tr class="a"><td>portlets/entry</td> +<td>page/fragment/fragment@type="portlet"</td> +<td>A portlet window on a page.</td> +</tr> +<tr class="b"><td>entry@id</td> +<td>fragment@id</td> +<td>The system-wide unique ID of the portlet window.</td> +</tr> +<tr class="a"><td>entry@parent</td> +<td>fragment@name</td> +<td>The portlet registry reference. In Jetspeed-2 the name of the portlet must be specified as PA::portlet-name</td> +</tr> +<tr class="b"><td>entry/layout/property@name="column"@value={column}</td> +<td>fragment/property@name="column"@value={column}</td> +<td>The property containing the column position</td> +</tr> +<tr class="a"><td>entry/layout/property@name="row"@value={row}</td> +<td>fragment/property@name="row"@value={row}</td> +<td>The property containing the row position</td> +</tr> +</table> +</div> +<div class="section"><h3><a name="Menus_vs_Tabs"></a>Menus vs Tabs</h3> <p>There is a big difference with the navigational aspects, or menus, between Jetspeed-1 and Jetspeed-2. Jetspeed-1 restricts menus navigation to navigation amongst <i>tabs</i>. Tabs are defined within a PSML page. Tabs are simply subcontainers in the PSML page, defined by the <b>portlets</b> element. Whereas Jetspeed-1 does support navigation to other pages, the Tabbing Menus do not directly support it without - writing a specific portlet to act as an external link.</p> + writing a specific portlet to act as an external link.</p> <p>Jetspeed-2 menu navigations map directly onto the Portal Site. Thus menu tabs represent portal resources. Menus in Jetspeed-2 can point to folders, pages or links. This more naturally allows the user to navigate over the entire portal site. - </p> + </p> <p>When migrating PSML files from Jetspeed-1 to Jetspeed-2, depending on whether you use advanced Jetspeed-1 controllers such as Card or Tab controllers, you may find that the pages do not port to Jetspeed-2 very well. In consideration of the lack of migration tools, this leaves two immediate options: - </p> -<ul><li>Rewrite your PSML files to better map to the Jetspeed-2 site constructs, folders and multiple pages.</li> -<li>Enhance Jetspeed-2 to support card and tab controller behavior</li> -</ul> -</div> -</div> -<div class="section"><h2><a name="XML_API_-_Seed_Data"></a>XML API - Seed Data</h2> + </p> +<ul><li>Rewrite your PSML files to better map to the Jetspeed-2 site constructs, folders and multiple pages.</li> +<li>Enhance Jetspeed-2 to support card and tab controller behavior</li> +</ul> +</div> +</div> +<div class="section"><h2><a name="XML_API_-_Seed_Data"></a>XML API - Seed Data</h2> <p>Jetspeed-2 defines an XML API for populating the initial "Seed" data for your portal. Populating your seed data via the XML API provides an alternative to populating database data with database-specific and hard to read SQL scripts. Additionally, the XML API can be used for importing and exporting data, or backing up and restoring from your Jetspeed-2 database. - </p> + </p> <p> The XML API also provides a migration path over the maintenance cycle of your Jetspeed portal. The XML API was first implemented in version 2.1. To migrate your data from version 2.1 to 2.2, (if there are any database schema changes), the XML API can be used to migrate (by exporting and importing) across versions. - </p> -<p>As of 2.1, the Jetspeed API supports the following elements:</p> -<table class="bodyTable"><tr class="b"><th>Element</th> -<th>Description</th> -</tr> -<tr class="a"><td>MimeTypes</td> -<td>Mime Types supported by the portal such as text/html, text/xhtml....</td> -</tr> -<tr class="b"><td>MediaTypes</td> -<td>Mediat Types supported by the portal such as html, xml, wml...</td> -</tr> -<tr class="a"><td>Capabilities</td> -<td>General capabilities of web clients that access the portal</td> -</tr> -<tr class="b"><td>Clients</td> -<td>Supported Web Clients by the portal</td> -</tr> -<tr class="a"><td>Roles</td> -<td>Define all roles defined to the initial configuration of the portal</td> -</tr> -<tr class="b"><td>Groups</td> -<td>Define all groups defined to the initial configuration of the portal</td> -</tr> -<tr class="a"><td>Users</td> -<td>Define all initial users defined to the initial configuration of the portal, minimally admin and guest(anon) users</td> -</tr> -<tr class="b"><td>Permissions</td> -<td>Define initial J2EE security policy for this portal. Note that permissions are turned off by default.</td> -</tr> -<tr class="a"><td>ProfilingRules</td> -<td>Define all the profiling rules in the initial portal such as role fallback, user-role-fallback, j1-emulation, default-j2, subsites and more</td> -</tr> -<tr class="b"><td></td> -<td></td> -</tr> -</table> -</div> -<div class="section"><h2><a name="XML_Schemas"></a>XML Schemas</h2> -<p>Reference for Jetspeed-2 XML schemas:</p> -<table class="bodyTable"><tr class="a"><td>Jetspeed-2 PSML</td> -<td><a href="http://portals.apache.org/jetspeed-2/2.1/schemas/psml.xsd"; class="externalLink">http://portals.apache.org/jetspeed-2/2.1/schemas/psml.xsd</a></td> -</tr> -<tr class="b"><td>Jetspeed-2 Folder Metadata</td> -<td><a href="http://portals.apache.org/jetspeed-2/2.1/schemas/folder-metadata.xsd"; class="externalLink">http://portals.apache.org/jetspeed-2/2.1/schemas/folder-metadata.xsd</a></td> -</tr> -<tr class="a"><td>Jetspeed-2 Seed Data</td> -<td><a href="http://portals.apache.org/jetspeed-2/2.1/schemas/j2-seed.xsd"; class="externalLink">http://portals.apache.org/jetspeed-2/2.1/schemas/j2-seed.xsd</a></td> -</tr> -<tr class="b"><td>Jetspeed-2 Security Constraints</td> -<td><a href="http://portals.apache.org/jetspeed-2/2.1/schemas/page-security.xsd"; class="externalLink">http://portals.apache.org/jetspeed-2/2.1/schemas/page-security.xsd</a></td> -</tr> -<tr class="a"><td>Jetspeed-2 Links</td> -<td><a href="http://portals.apache.org/jetspeed-2/2.1/schemas/link.xsd"; class="externalLink">http://portals.apache.org/jetspeed-2/2.1/schemas/link.xsd</a></td> -</tr> -<tr class="b"><td>Jetspeed-2 Extended Portlet Descriptor</td> -<td><a href="http://portals.apache.org/jetspeed-2/2.1/schemas/jetspeed-portlet.xsd"; class="externalLink">http://portals.apache.org/jetspeed-2/2.1/schemas/jetspeed-portlet.xsd</a></td> -</tr> -</table> -</div> -<div class="section"><h2><a name="Where_to_Get_Started"></a>Where to Get Started?</h2> -<p>The best place to get started is to create your own custom portal. This process is defined online at Apache. The <a href="http://portals.apache.org/tutorials/jetspeed-2/"; class="externalLink">Jetspeed Tutorial</a> will take you through - the initial steps of setting up your own (custom) Jetspeed portal, including setting up XML seed data, PSML, custom decorations and portlet applications.</p> -</div> + </p> +<p>As of 2.1, the Jetspeed API supports the following elements:</p> +<table class="bodyTable"><tr class="b"><th>Element</th> +<th>Description</th> +</tr> +<tr class="a"><td>MimeTypes</td> +<td>Mime Types supported by the portal such as text/html, text/xhtml....</td> +</tr> +<tr class="b"><td>MediaTypes</td> +<td>Mediat Types supported by the portal such as html, xml, wml...</td> +</tr> +<tr class="a"><td>Capabilities</td> +<td>General capabilities of web clients that access the portal</td> +</tr> +<tr class="b"><td>Clients</td> +<td>Supported Web Clients by the portal</td> +</tr> +<tr class="a"><td>Roles</td> +<td>Define all roles defined to the initial configuration of the portal</td> +</tr> +<tr class="b"><td>Groups</td> +<td>Define all groups defined to the initial configuration of the portal</td> +</tr> +<tr class="a"><td>Users</td> +<td>Define all initial users defined to the initial configuration of the portal, minimally admin and guest(anon) users</td> +</tr> +<tr class="b"><td>Permissions</td> +<td>Define initial J2EE security policy for this portal. Note that permissions are turned off by default.</td> +</tr> +<tr class="a"><td>ProfilingRules</td> +<td>Define all the profiling rules in the initial portal such as role fallback, user-role-fallback, j1-emulation, default-j2, subsites and more</td> +</tr> +<tr class="b"><td></td> +<td></td> +</tr> +</table> +</div> +<div class="section"><h2><a name="XML_Schemas"></a>XML Schemas</h2> +<p>Reference for Jetspeed-2 XML schemas:</p> +<table class="bodyTable"><tr class="a"><td>Jetspeed-2 PSML</td> +<td><a class="externalLink" href="http://portals.apache.org/jetspeed-2/2.1/schemas/psml.xsd";>http://portals.apache.org/jetspeed-2/2.1/schemas/psml.xsd</a></td> +</tr> +<tr class="b"><td>Jetspeed-2 Folder Metadata</td> +<td><a class="externalLink" href="http://portals.apache.org/jetspeed-2/2.1/schemas/folder-metadata.xsd";>http://portals.apache.org/jetspeed-2/2.1/schemas/folder-metadata.xsd</a></td> +</tr> +<tr class="a"><td>Jetspeed-2 Seed Data</td> +<td><a class="externalLink" href="http://portals.apache.org/jetspeed-2/2.1/schemas/j2-seed.xsd";>http://portals.apache.org/jetspeed-2/2.1/schemas/j2-seed.xsd</a></td> +</tr> +<tr class="b"><td>Jetspeed-2 Security Constraints</td> +<td><a class="externalLink" href="http://portals.apache.org/jetspeed-2/2.1/schemas/page-security.xsd";>http://portals.apache.org/jetspeed-2/2.1/schemas/page-security.xsd</a></td> +</tr> +<tr class="a"><td>Jetspeed-2 Links</td> +<td><a class="externalLink" href="http://portals.apache.org/jetspeed-2/2.1/schemas/link.xsd";>http://portals.apache.org/jetspeed-2/2.1/schemas/link.xsd</a></td> +</tr> +<tr class="b"><td>Jetspeed-2 Extended Portlet Descriptor</td> +<td><a class="externalLink" href="http://portals.apache.org/jetspeed-2/2.1/schemas/jetspeed-portlet.xsd";>http://portals.apache.org/jetspeed-2/2.1/schemas/jetspeed-portlet.xsd</a></td> +</tr> +</table> +</div> +<div class="section"><h2><a name="Where_to_Get_Started"></a>Where to Get Started?</h2> +<p>The best place to get started is to create your own custom portal. This process is defined online at Apache. The <a class="externalLink" href="http://portals.apache.org/tutorials/jetspeed-2/";>Jetspeed Tutorial</a> will take you through + the initial steps of setting up your own (custom) Jetspeed portal, including setting up XML seed data, PSML, custom decorations and portlet applications.</p> +</div> </div> </div> @@ -1291,7 +1291,7 @@ to the <b>processAction</b> method on th </div> <div id="footer"> <div class="xright">© - 2004-2016 + 2004-2022 Apache Software Foundation
Modified: portals/site-live/jetspeed-2/j1-users.html URL: http://svn.apache.org/viewvc/portals/site-live/jetspeed-2/j1-users.html?rev=1901428&r1=1901427&r2=1901428&view=diff ============================================================================== --- portals/site-live/jetspeed-2/j1-users.html (original) +++ portals/site-live/jetspeed-2/j1-users.html Tue May 31 02:15:08 2022 @@ -42,7 +42,7 @@ <div class="xleft"> - Last Published: 9 May 2016 + Last Published: 26 May 2022 </div> <div class="xright"> <a href="http://portals.apache.org/applications/"; class="externalLink">Applications</a> | @@ -253,7 +253,7 @@ </div> <div id="bodyColumn"> <div id="contentBox"> - <subtitle></subtitle><authors><person name="David Le Strat" email="[email protected]"></authors><div class="section"><h2><a name="For_Jetspeed-1_Users"></a>For Jetspeed-1 Users</h2> + <subtitle></subtitle><authors><person name="David Le Strat" email="[email protected]"></authors><div class="section"><h2><a name="For_Jetspeed-1_Users"></a>For Jetspeed-1 Users</h2> <p>Jetspeed-2 is a new project, written from groundup and does not have any dependencies on Jetspeed-1. Jetspeed-2 is based on industry standards, designed for high-volume enterprise portals applications. The foremost difference is Jetspeeds Component Oriented Architecture, all assembled together with Spring. @@ -262,69 +262,69 @@ is implemented to the Portlet API specification. Turbines file-based configuration for properties are replaced managed components. Jetspeed-2 is fully decoupled from the legacy projects that were intertwined in the Jetspeed-1 architecture. - </p> -</div> -<div class="section"><h2><a name="Whats_New_in_Jetspeed-2"></a>Whats New in Jetspeed-2</h2> -<ul><li>1. Fully Compliant with Java Portlet API Standard</li> -<li>2. Separation of Portlet Applications From Portal</li> -<li>3. Live Deployment Model for Portlet Applications and Portal Layouts</li> -<li>4. Spring Component Based Architecture</li> -<li>5. Multi-threaded Portlet Aggregation Engine</li> -<li>6. Scalable Architecture</li> -<li>7. Pipeline-based Request Processing</li> -<li>8. JAAS Security</li> -<li>9. Bridges Integration with Struts, JSF, PHP, Perl, Velocity</li> -<li>19. CMS-based Site Navigations</li> -</ul> -</div> -<div class="section"><h2><a name="Whats_the_same_in_Jetspeed-2"></a>Whats the same in Jetspeed-2</h2> -<p>Not much.</p> + </p> +</div> +<div class="section"><h2><a name="Whats_New_in_Jetspeed-2"></a>Whats New in Jetspeed-2</h2> +<ul><li>1. Fully Compliant with Java Portlet API Standard</li> +<li>2. Separation of Portlet Applications From Portal</li> +<li>3. Live Deployment Model for Portlet Applications and Portal Layouts</li> +<li>4. Spring Component Based Architecture</li> +<li>5. Multi-threaded Portlet Aggregation Engine</li> +<li>6. Scalable Architecture</li> +<li>7. Pipeline-based Request Processing</li> +<li>8. JAAS Security</li> +<li>9. Bridges Integration with Struts, JSF, PHP, Perl, Velocity</li> +<li>19. CMS-based Site Navigations</li> +</ul> +</div> +<div class="section"><h2><a name="Whats_the_same_in_Jetspeed-2"></a>Whats the same in Jetspeed-2</h2> +<p>Not much.</p> <p> In fact Jetspeed-2 does not re-use any of the code in Jetspeed-1. Some concepts are continued in Jetspeed-2, but with new design and implementations. The table below shows some of the concepts continued in Jetspeed-2 from Jetspeed-1. Note that even though the concepts are continued, they are have changed, in some cases significantly: - </p> + </p> <ul><li>1. PSML - Portlet Structured Markup Language. Defines the layout of portlets on a page. While the purpose is still the same, the XML format has changed. Porting is possible, requires a migration tool. PSML now fits into an overall Jetspeed Navigation Site as a page-type resource. No PSML porting tool is currently available. However, an XSLT transform could be a good choice. - </li> + </li> <li>2. Portal Wide Security Policy and Constraints - Jetspeed-2 has two kinds of security mechanisms: JAAS-based security policies, and declarative security constraints much like Jetspeed-1 constraints. Where as Jetspeed-1 constraints were limited to PSML, Jetspeed-2 declarative security constraints are also applied to folders - and links.</li> + and links.</li> <li>3. Portlets - Portlets now must adhere to the new Portlet API. No porting tool is currently available. The Jetspeed-1 Portlet API will not be continued in Jetspeed-2. - </li> -<li>4. Turbine Services are out (Fulcrum). Jetspeed-2 is based on Spring components.</li> + </li> +<li>4. Turbine Services are out (Fulcrum). Jetspeed-2 is based on Spring components.</li> <li>5. Registries - The Jetspeed-1 Registries are discontinued in Jetspeed-2. All portlets are now stored in a Registry database in Jetspeed-2. No porting tool is available. Recommend converting your portlets to JSR-168 portlets, packaging all portlets in a portlet application, and deploying as standard WAR file. - Other registries are all deprecated.</li> + Other registries are all deprecated.</li> <li>6. JSP and Velocity Templates - Templates can be re-used to some extend. Any references to Rundata or any other Turbine or Jetspeed-1 tools or - tags must be converted.</li> + tags must be converted.</li> <li>7. Controls and Controllers - These concepts have changed, and are now called decorators and layouts. The Turbine module concept, which backed controls and controllers, is no longer supported. Layouts and decorators are now only implemented as portlets, or as just plain markup. Layouts and templates - can be deployed to the portal as a deployable unit.</li> + can be deployed to the portal as a deployable unit.</li> <li>8. Jetspeed Configurations and Jetspeed Component Assemblies replace Property Files. Component (services) should be assembled, not defined in property files. Many of the features in Jetspeed-1 were represented as read-only properties in - the Jetspeed-1 static property files. Jetspeed-2 components can be configured with JMX.</li> -</ul> -</div> -<div class="section"><h2><a name="Turbine_Gone"></a>Turbine Gone</h2> + the Jetspeed-1 static property files. Jetspeed-2 components can be configured with JMX.</li> +</ul> +</div> +<div class="section"><h2><a name="Turbine_Gone"></a>Turbine Gone</h2> <p> Jetspeed-1 is tightly coupled to the Turbine MVC-2 framework, and this coupling permeates many areas of the Jetspeed API. Jetspeed-2 does not rely on Turbine as the MVC-2 controller. @@ -335,101 +335,101 @@ of the servlet architecture, and delegating the actual rendering of portlets to portlet application frameworks. These portlet applications can in turn have their own MVC frameworks, such as Struts portlet applications, JSF portlet applications, or Turbine portlet application frameworks. - </p> -</div> -<div class="section"><h2><a name="RunData_No_More"></a>RunData No More</h2> + </p> +</div> +<div class="section"><h2><a name="RunData_No_More"></a>RunData No More</h2> <p> Most notably missing from Portlet API portlets is the RunData class. The Jetspeed-1 API uses the RunData class ubiquitously, serving as a wrapper for both the servlet request and response. Other dependencies on Turbine include Portlet Actions, Portlet Aggregation Engine (ECS), the Service Architecture, Configuration and Turbine Modules. None of these exist in the newer version. - </p> -<table class="bodyTable"><tr class="a"><th>Jetspeed-1</th> -<th>Jetspeed-2</th> -</tr> -<tr class="b"><td>Run Data</td> -<td>Portlet API: Portlet Request and Portlet Response</td> -</tr> -<tr class="a"><td>Portlet Aggregation Engine (ECS)</td> -<td>Jetspeed-2 Multi-threaded Portlet Container Engine</td> -</tr> -<tr class="b"><td>Turbine Service Architecture</td> -<td>Jetspeed-2 Components</td> -</tr> -<tr class="a"><td>Property Configuration Files</td> -<td>Spring Configurations, JMX</td> -</tr> -<tr class="b"><td>Turbine Modules (Actions)</td> -<td>Portlet API Actions </td> -</tr> -</table> -</div> -<div class="section"><h2><a name="Pluto_is_the_Portlet_Container"></a>Pluto is the Portlet Container</h2> + </p> +<table class="bodyTable"><tr class="a"><th>Jetspeed-1</th> +<th>Jetspeed-2</th> +</tr> +<tr class="b"><td>Run Data</td> +<td>Portlet API: Portlet Request and Portlet Response</td> +</tr> +<tr class="a"><td>Portlet Aggregation Engine (ECS)</td> +<td>Jetspeed-2 Multi-threaded Portlet Container Engine</td> +</tr> +<tr class="b"><td>Turbine Service Architecture</td> +<td>Jetspeed-2 Components</td> +</tr> +<tr class="a"><td>Property Configuration Files</td> +<td>Spring Configurations, JMX</td> +</tr> +<tr class="b"><td>Turbine Modules (Actions)</td> +<td>Portlet API Actions </td> +</tr> +</table> +</div> +<div class="section"><h2><a name="Pluto_is_the_Portlet_Container"></a>Pluto is the Portlet Container</h2> <p>The Jetspeed-2 portal does not implement the Portlet container. - <a href="http://portals.apache.org/pluto"; class="externalLink">Pluto</a> implements the JSR 168 interface + <a class="externalLink" href="http://portals.apache.org/pluto";>Pluto</a> implements the JSR 168 interface contract for portlets running inside our portal. The Pluto container handles all communication with portlets for the portal. - </p> -</div> -<div class="section"><h2><a name="Aggregating_Isnt_It"></a>Aggregating, Isnt It?</h2> + </p> +</div> +<div class="section"><h2><a name="Aggregating_Isnt_It"></a>Aggregating, Isnt It?</h2> <p>The aggregation engine and the Jetspeed-1 Portlet API are both coupled to a deprecated Jakarta package ECS (Element Construction Set). ECS generates HTML with Java code, storing the content in temporary Java objects before sending the HTML out to the servlet output stream. This wasteful use of Java objects leads to fragmentation on memory, accelerated garbage collection, and paging in high volume sites. The servlet API clearly provides a content stream for streaming out portlet content. Jetspeed-2 models its aggregation engine upon the Portlet APIs streams and readers, analogous to the stream-based Servlet - API for rendering content.</p> -</div> -<div class="section"><h2><a name="State_and_Life_Cycle"></a>State and Life Cycle</h2> + API for rendering content.</p> +</div> +<div class="section"><h2><a name="State_and_Life_Cycle"></a>State and Life Cycle</h2> <p>The Portlet API clearly defines the lifecycle of a portlet, the event sequences for actions, and how the container can cache content from a portlet. The Portlet Lifecycle was not clearly defined in Jetspeed-1. The portlet API clearly states that only one instance of a portlet will reside in memory inside a container. The state of the portlet is directly related to the servlet state for the current user session. While this may seem obvious, portlet state and lifetime was not clearly defined in Jetspeed-1. - </p> -</div> -<div class="section"><h2><a name="Actions"></a>Actions</h2> + </p> +</div> +<div class="section"><h2><a name="Actions"></a>Actions</h2> <p>In version 1, actions were coupled to Turbine and not properly integrated into the Portlet class. In fact, actions were separate objects from portlets. In the Portlet API, actions are methods on the portlet. - Action event handling and sequencing is clearly defined in the specification.</p> -</div> -<div class="section"><h2><a name="Standard_Deployment"></a>Standard Deployment</h2> + Action event handling and sequencing is clearly defined in the specification.</p> +</div> +<div class="section"><h2><a name="Standard_Deployment"></a>Standard Deployment</h2> <p>Jetspeed-1 does not have a standardized method of deploying portlets and their supporting files, commonly referred to as portlet applications. In order to import an application, one must package - registry files, class and jar files, PSML and templates so that they match the Jetspeed web application format.</p> + registry files, class and jar files, PSML and templates so that they match the Jetspeed web application format.</p> <p>In Jetspeed-2, the Portlet API defines a standard deployment descriptor for deploying Portal Applications into Jetspeed. Portal applications must be deployed to the portal. Analogous to the servlets packaged in a web-application (WAR) deployment model, portals support portlets packaged in a portal-application deployment model. The Portal Application archive follows the same format as the WAR format defined in the Servlet specification with an additional Portlet deployment descriptor file. The clear advantage in Jetspeed-2 is the ability to deploy - live portlet applications to the server in a standardized format.</p> -</div> -<div class="section"><h2><a name="Resources_and_Deployment"></a>Resources and Deployment</h2> + live portlet applications to the server in a standardized format.</p> +</div> +<div class="section"><h2><a name="Resources_and_Deployment"></a>Resources and Deployment</h2> <p>Jetspeed-1 resources such as portal templates, images, skins, controllers, controls, are all merged into the single Jetspeed web application with no deployment model. For example, to override the default skin or top banner, the resource files are copied into the portal directory, property files updated to point to the new resources, and the server must be restarted. This made for the process of tailoring Jetspeed-1 portals to real production portals a process of property and file merging. In fact Jetspeed-1 now has a Maven plug-in to manage production portals separately from the core Jetspeed-1 portal. The need for this kind of tool covers up the fact that Jetspeed-1 - is missing a good deployment model for portal resources, requiring difficult portal maintenance procedures.</p> + is missing a good deployment model for portal resources, requiring difficult portal maintenance procedures.</p> <p>For a Jetspeed-2 production portal, portal resources are packaged in a Jetspeed-specific archive format. Thus portal resources (top banners, skins, images, style sheets) can all be deployed to dynamically tailor - the portal at runtime.</p> -</div> -<div class="section"><h2><a name="the_Standard"></a>the Standard</h2> + the portal at runtime.</p> +</div> +<div class="section"><h2><a name="the_Standard"></a>the Standard</h2> <p>JSR168 is the Portlet specification enables interoperability between Portlets and Portals. The specification defines a set of APIs that addresses standardization of portlet aggregation, - personalization, presentation and security. The goals of JSR168 are to: </p> -<ul><li>Define common Portal metaphor </li> -<li>Define a standard Portlet Java API </li> -<li>Ensure interoperability and portability</li> -<li>Enable multiple markups support </li> -<li>Ensure compatibility with other technologies </li> -</ul> + personalization, presentation and security. The goals of JSR168 are to: </p> +<ul><li>Define common Portal metaphor </li> +<li>Define a standard Portlet Java API </li> +<li>Ensure interoperability and portability</li> +<li>Enable multiple markups support </li> +<li>Ensure compatibility with other technologies </li> +</ul> <p>The Jetspeed-2 Portlet Server supports the JSR 168 standard. - This is an important initiative, introducing true portlet portability.</p> -</div> + This is an important initiative, introducing true portlet portability.</p> +</div> </div> </div> @@ -438,7 +438,7 @@ </div> <div id="footer"> <div class="xright">© - 2004-2016 + 2004-2022 Apache Software Foundation Modified: portals/site-live/jetspeed-2/license.html URL: http://svn.apache.org/viewvc/portals/site-live/jetspeed-2/license.html?rev=1901428&r1=1901427&r2=1901428&view=diff ============================================================================== --- portals/site-live/jetspeed-2/license.html (original) +++ portals/site-live/jetspeed-2/license.html Tue May 31 02:15:08 2022 @@ -42,7 +42,7 @@ <div class="xleft"> - Last Published: 9 May 2016 + Last Published: 26 May 2022 </div> <div class="xright"> <a href="http://portals.apache.org/applications/"; class="externalLink">Applications</a> | @@ -253,7 +253,7 @@ </div> <div id="bodyColumn"> <div id="contentBox"> - <div class="section"><h2><a name="Apache_License_version_2.0"></a>Apache License, version 2.0</h2> + <div class="section"><h2><a name="Apache_License_version_2.0"></a>Apache License, version 2.0</h2> <pre> Apache License Version 2.0, January 2004 @@ -444,7 +444,7 @@ same "printed page" as the cop identification within third-party archives. Copyright 2004 The Apache Software Foundation - </pre></div> + </pre></div> </div> </div> @@ -453,7 +453,7 @@ Copyright 2004 The Apache Software Found </div> <div id="footer"> <div class="xright">© - 2004-2016 + 2004-2022 Apache Software Foundation
