[Overview] 概要

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.

この移行のガイドは、Jetspeed のバージョン 1 からバージョン 2 への移行に役立つでしょう。現状、移行のためのツールはありません。また、バージョン 1 からバージョン 2 への、ポータルのリソースを変換するような移行ツールを作成する予定もありません。この文書は、移行のためのガイドラインのみを提供します。

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. The programming API is completely changed. There are no longer XREG files, but instead standard deployment descriptors. The are also new concepts introduced by the portlet standard such as portlet applications, portlet preferences, 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 For Jetspeed-1 Users

新しいポータルの標準 (Portlet API) の開発で、共通のポートレットのメタファが、バージョン 1 の Turbine ベースのものから大幅に変わりました。プログラミング API は完全に変わっています。もはや XREG ファイルはありません。代わりに標準の配備記述子があります。バージョン 1 とは直接結びつかない、ポートレットアプリケーション、ポートレット設定、ユーザ属性、初期パラメータのような、ポートレット標準により導入された新しいコンセプトがあります。移行ツールを作成することは、膨大な仕事を引き受ける事になります。Jetspeed の開発チームは、この投資を行う態勢にはありません。以下のガイドラインを読むと、容易に Jetspeed 1.x から Jetspeed 2 への移行が出来るでしょう。構造の違いの概要を掴むために、For Jetspeed 1 Users という文書を参照してください。

[Migration Table] 移行表

The table below gives you an idea of how to migrate. We will cover each subject in more detail further on in this document.

以下の表は、移行方法のアイデアを与えます。この表のそれぞれの項目については後で述べます。

1.x Feature2.x FeatureDescription
J1 Portlet Java CodePortlet API Standard CodeRewrite the java code to the new specification. Involves replacing Turbine action with standard processAction, and replacing Rundata with PortletRequest/Response
XREG Portlet Registryportlet.xml deployment descriptorThere are pretty big differences here. Migrate <portlet-entry> to <portlet> entries, <parameter> to <preference> or <init-param>
J1 PSMLJ2 PSMLMigrate Tabs to Folders and Pages, migrate to new tag syntax
XREG Security RegistrySecurity ConstraintsMigrate J1 security constraint format to J2 security constraint format
J1 ControllersJ2 LayoutsControllers 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
J1 ControlsJ2 Portlet DecoratorsControls 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
J1 Layouts, Screens, NavigationsJ2 Page (Layout) DecoratorsAll 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
1.x の機能2.x の機能説明
J1 ポートレットの Java コードポートレット API 標準のコードJava コードを新しい仕様に従って書き直す。Turbine の動きを標準の processAction に置き換える事、Rundata を PortletRequest/Response に置き換える必要があります。
XREG ポートレットレジストリportlet.xml 配備記述子若干大きな違いがあります。<portlet-entry> を <portlet> エントリに、<parameter> を <preference> もしくは <init-param> に移行してください。
J1 PSMLJ2 PSMLタブからフォルダ、ページに移行してください。新しいタグ文法に移行してください。
XREG セキュリティレジストリSecurity Constraintsセキュリティ制約J1 のセキュリティ制約フォーマットを J2 セキュリティ制約フォーマットに移行してください。
J1 コントローラJ2 レイアウトコントローラは廃止予定で非推奨となりました。新しい Jetspeed 2 のレイアウトポートレットを使うことを推奨します。もし、移植が必要であれば、VM コードの HTML 部分が移植出来るかもしれません。しかし、コンテキストモデルの変数は移植出来ないでしょう。
J1 コントロールJ2 ポートレットデコレータコントロールは廃止予定で非推奨になりました。新しい Jetspeed 2 のポートレットデコレータを使用することを推奨します。もし、移植が必要であれば、VM コードの HTML 部分が移植出来るでしょう。しかし、コンテキストモデルの変数は移植出来ないでしょう。
J1 レイアウト、スクリーン、ナビゲーションJ2 ページ (レイアウト) デコレータ全て廃止予定で非推奨となりました。スタート地点として、あなた自身のページデコレータを書くために、新しい Jetspeed 2 のページ (レイアウト) デコレータを使うことを推奨します。VM コードの HTML 部分は移植出来るでしょう。しかし、コンテキストモデルの変数は移植出来ないでしょう。

[Portlet Applications] ポートレットアプリケーション

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 your portlets. Jetspeed-2 is packaged as a single web application itself. When you write your portlets for Jetspeed-2, you will need to write and package your own portlets. The portlet classes and deployment descriptors must all be packaged into a single war file, known 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.

Jetspeed 2 / ポートレット API を作成する際のもっとも重要な違いには、Jetspped ポータルからポートレットコードを分離しなければいけない、というものがあります。Jetspeed 1 では、全てのユーザーコード、ポートレットのビジネスロジックは Jetspeed 1 の実装と一緒に、一つの大きな war ファイルにパッケージされていました。ポートレット API は、このポータルの実装とポートレットが混ざりあっているのを、はっきりと廃止しました。Jetspeed 2 は、それ自身一つのウェブアプリケーションとしてパッケージされています。Jetspeed 2 のためのポートレットを開発する場合、あなたは自身のポートレットを開発し、それをパッケージングする必要があります。ポートレットのクラスと配備記述子は、ポートレットアプリケーションとして、一つの war ファイルの中に全てパッケージされていなければいけません。ポートレットアプリケーションは、配備記述子、portlet.xml と、一つまたはそれ以上のポートレットを含みます。ポートレットアプリケーションは、ウェブアプリケーションの拡張です。portlet.xml は、一つ以上のポートレットの定義を保持します。portlet.xml は、Jetspeed 1 で使われた xreg ファイルに似ています。

[Java Code] Java コード

In this section we demonstrate how to convert a Jetspeed-1 portlet to a JSR-168 Java Standard Portlet. This involves the following steps:

この節では、どのように Jetspeed 1 ポートレットから JSR-168 Java 標準のポートレットへの変換を行うのかを、実際に示してみます。以下のようなステップが必要となります。

  • Converting the Portlet Init Java Code
  • Converting the Portlet getContent Java Code
  • Converting a Turbine Action
  • ポートレットの初期化の Java コードの変換
  • ポートレットの getContent Java コードの変換
  • Turbine アクションの変換

Jetspeed-1 portlet implementations are normally separated between two different Java source files.

Jetspeed 1 のポートレットの実装は、普通、2 つの異なる Java ソースファイルに分かれています。

  • The Portlet Source Code
  • The Turbine Action Source Code
  • ポートレットのソースコード
  • Turbine のアクションソースコード

The Portlet Source Code handles the View part of the MVC pattern. The getContent 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 doView, doEdit, doHelp. In the Portlet API terminology, this phase of portlet processing is known as the render phase. During the render phase, the portlet should not perform any business logic or other manipulation on the Model. All model manipulation should be left to the action phase

ポートレットのソースコードは、MVC パターンの View 部分を処理します。getContent メソッドは、ポートレットのコンテンツを描画するために呼ばれる、Jetspeed 1 の標準メソッドです。Jetspeed 2 とポートレット API において、これと一致するメソッドは doView, doEdit, doHelp です。ポートレット API の用語で、ポートレットの処理のこのフェーズは、描画フェーズ (render phase) として知られています。描画フェーズの間、ポートレットは、いかなるビジネスロジックやモデルの他の操作を行うべきではありません。全てのモデル操作は、アクションフェーズに委ねるべきです。

The Turbine Action performs the action phase 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.

Turbine アクションは、ポートレット処理のアクションフェーズを実行します。ポートレット API 標準のアクションフェーズの間、他の全てのポートレットの描画は、アクションが終わるまで遮断されます。これは Jetspeed 1/Turbine モデルでも同様です。

[Creating a new Portlet Class] 新しいポートレットクラスの作成

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.

あなたのポートレットの移行を始めるのに最も良い方法は、JSR-168 準拠の新しいポートレットを作成することです。単純に、ポートレット API が規定している GenericPortlet インターフェースを継承する、新しい Java クラスを作成してください。Apache Portals や Spring MVC から提供されるフレームワークやブリッジを利用することも可能です。以下の例は、直接 Portlet API を使って書いています。このコードは、ポートレットを作成する時のスケルトンに使えます。


import java.io.IOException;
import javax.portlet.GenericPortlet;
import javax.portlet.PortletConfig;
import javax.portlet.PortletException;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import javax.portlet.ActionRequest;
import javax.portlet.ActionResponse;

public class HelloWorld extends GenericPortlet
{    
    public void init(PortletConfig config) 
    throws PortletException 
    {
    }
    public void doEdit(RenderRequest request, RenderResponse response)
    throws PortletException, IOException
    {
    }    
    public void doHelp(RenderRequest request, RenderResponse response)
    throws PortletException, IOException
    {
    }
    public void doView(RenderRequest request, RenderResponse response)
    throws PortletException, IOException
    {
    }
    public void processAction(ActionRequest request, ActionResponse actionResponse)
    throws PortletException, IOException
	{
	}    
}
		

import java.io.IOException;
import javax.portlet.GenericPortlet;
import javax.portlet.PortletConfig;
import javax.portlet.PortletException;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import javax.portlet.ActionRequest;
import javax.portlet.ActionResponse;

public class HelloWorld extends GenericPortlet
{    
    public void init(PortletConfig config) 
    throws PortletException 
    {
    }
    public void doEdit(RenderRequest request, RenderResponse response)
    throws PortletException, IOException
    {
    }    
    public void doHelp(RenderRequest request, RenderResponse response)
    throws PortletException, IOException
    {
    }
    public void doView(RenderRequest request, RenderResponse response)
    throws PortletException, IOException
    {
    }
    public void processAction(ActionRequest request, ActionResponse actionResponse)
    throws PortletException, IOException
	{
	}    
}
		

To find out more about Portals Bridges and other Frameworks, explore these links:

更にポータルブリッジや他のフレームワークについて調べるには、以下を参照してください。

[Converting the Portlet Init Java Code] ポートレットの Init Java コードの変換

The Portlet Source code handles the Init 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:

ポートレットのソースコードは、ポートレットのライフサイクルの Init フェーズを扱います。Init フェーズは Java Portlet API と Jetspeed 1 で非常に良く似ています。ここに Jetspeed 1 ポートレットの init メソッドの例を挙げてみます。


    public void init() throws PortletException
    {
    }

			

    public void init() throws PortletException
    {
    }

			

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):

Portlet API (Jetspeed 2) にも同等のメソッドがあって、PortletConfig パラメータの存在が違うことに注意してください (例外クラスが同じ名前ですが、まったく違うクラスです。片方は Jetspeed 1 のもの、他方は Portlet API のものです)。


    public void init(PortletConfig config) 
    throws PortletException 
    {
    }

			

    public void init(PortletConfig config) 
    throws PortletException 
    {
    }

			

In Jetspeed-1, you would normally access Turbine Services with static acccessors, for example:

Jetspeed 1 では、通常、静的なアクセサで Turbine サービスにアクセスします。例えば、


            JetspeedSecurity.addUser(user);


            JetspeedSecurity.addUser(user);

In Jetspeed-2, Jetspeed Services the standard way to access Jetspeed Services is to get a handle in the init phase, for example:

Jetspeed 2 では、Jetspeed サービスにアクセスする標準的な方法は、init フェーズでハンドルを取得します。


    private UserManager userManager;
...
    public void init(PortletConfig config) 
    throws PortletException 
    {
        userManager = (UserManager)getPortletContext().getAttribute(CommonPortletServices.CPS_USER_MANAGER_COMPONENT);
        if (null == userManager)
        {
            throw new PortletException("Failed to find the User Manager on portlet initialization");
        }    
    }


    private UserManager userManager;
...
    public void init(PortletConfig config) 
    throws PortletException 
    {
        userManager = (UserManager)getPortletContext().getAttribute(CommonPortletServices.CPS_USER_MANAGER_COMPONENT);
        if (null == userManager)
        {
            throw new PortletException("Failed to find the User Manager on portlet initialization");
        }    
    }

[Converting the Portlet getContent Java Code] ポートレットの getContent Java コードの変換

In Jetspeed-1, the getContent 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.

Jetspeed 1 では、getContent メソッドは、ポートレットのコンテンツを描画します。Jetspeed 1 の描画フェーズは、Jetspeed 1 ポートレットインターフェースで定義されたポートレットの getContent メソッドによって実装されています。


public ConcreteElement getContent(RunData rundata);

The only parameter passed in to the getContent method is a RunData parameter. RunData is a part of the Turbine web framework. 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.

getContent メソッドが処理するたった一つのパラメータは RunData パラメータです。RunData は Turbine ウェブフレームワーク の一部分です。RunData は基本的に、他の Turbine 特有の情報と一緒に、サーブレットのリクエストとレスポンスを包むラッパーです。Jetspeed 2 に対するポートレットを書く時は、Portlet API を使って書きます。


public void doView(RenderRequest request, RenderResponse response)
throws PortletException, IOException
{
    response.setContentType("text/html");
    ...


public void doView(RenderRequest request, RenderResponse response)
throws PortletException, IOException
{
    response.setContentType("text/html");
    ...

The doView method is the Portlet API equivalent of the getContent method of the Jetspeed-1 API. The Portlet API has the concept of portlet modes. There are three default portlet modes view, edit, and help. For each of these modes, there are three methods you can override in your portlet: doView, doEdit and doHelp. Notice that where the Jetspeed-1 API has one RunData parameter, the Portlet API is more like the Servlet API, with two parameters, the RenderRequest and RenderResponse. 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 Portlets and Apache Portals.

doView メソッドは、Jetspeed 1 API の getContent メソッドと同等の、ポートレット API のメソッドです。ポートレット API は ポートレットのモード の概念を持ちます。view, edit, help の 3 つのデフォルトのポートレットモードがあります。これらのモードそれぞれに対して、あなたのポートレットがオーバーライド出来る 3 つのメソッドがあります。doView, doEdit, doHelp です。Jetspeed 1 では、RunData パラメータ 1 つだったところが、ポートレットAPI では、より Servlet API 的な RenderRequestRenderResponse の 2 つのパラメータを持つことに注意してください。あなたのアプリケーションを移行する最も大きな部分の 1 つが RunData を RenderRequest と RenderReponse に変換する事でしょう。移行を始める前に、Portlet API のトレーニングコースを受講するか、ポートレット仕様を自分で読んだ上に、関連する記事や書籍を読んで、API を学ぶ事をおすすめします。ポートレット API を学び始めるのに良い書籍に、Portlets and Apache Portals があります。

When rendering content, Jetspeed 1 makes use of a HTML construction kit called ECS. All rendering goes through Turbine and ECS. The return type of the getContent method is a ConcreteElement, which is defined in the ECS API. Here is the typical way to generate output from a portlet in Jetspeed-1:

コンテンツを描画するとき、Jetspeed 1 は ECS と呼ばれる HTML 構築キットを使います。全ての描画は、Turbine と ECS を通じて行われます。


...
String helloString = "Hello World. This is the portlet output in view mode.";
return new org.apache.jetspeed.util.JetspeedClearElement(helloString);        


...
String helloString = "Hello World. This is the portlet output in view mode.";
return new org.apache.jetspeed.util.JetspeedClearElement(helloString);        

When rendering content in Jetspeed-2, the Portlet API uses a streaming interface:

Jetspeed 2 では、コンテンツを描画するとき、ポートレット API はストリーミングインターフェースを使います。


response.setContentType("text/html");
String helloString = "Hello World. This is the portlet output in view mode.";

// using Java writers
response.getWriter().println(helloString);

.. OR ...

// using Java streaming
response.getPortletOutputStream().write(helloString.getBytes());


response.setContentType("text/html");
String helloString = "Hello World. This is the portlet output in view mode.";

// using Java writers
response.getWriter().println(helloString);

.. OR ...

// using Java streaming
response.getPortletOutputStream().write(helloString.getBytes());

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 GenericMVCPortlet or one of its derivitives, the VelocityPortlet or the JspPortlet. 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

もちろん、Jetspeed 1 か Jetspeed 2 のどちらでも JSP や Velocity を使うことは出来ます。Jetspeed 1 では、良く行われている事に、Jetspeed 1 GenericMVCPortlet またはその派生物、VelocityPortlet または JspPortlet の利用があります。VelocityPortlet と JspPortlet は両方共、GenericMVCPortlets です。ここに、その親に Velocity を設定した GenericMVCPortlet を継承した WeatherPortlet の xreg の例があります。


    <portlet-entry name="WeatherPortlet" hidden="false" type="ref" parent="Velocity" application="false">
        <parameter name="template" value="weather" hidden="true"/>
    </portlet-entry>


    <portlet-entry name="WeatherPortlet" hidden="false" type="ref" parent="Velocity" application="false">
        <parameter name="template" value="weather" hidden="true"/>
    </portlet-entry>

The template parameter is named weather. Since this is a Velocity MVC portlet, Jetspeed-1 knows to look under the WEB-INF/templates/vm/portlets/html directory to find weather.vm. 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.

テンプレートパラメータは weather と名づけられています。これは Velocity MVC portlet なので、Jetspeed 1 は WEB-INF/templates/vm/portlets/html ディレクトリ以下に weather.vm が見つかることを知っています。MVC ポートレットは自動的に、ポートレットを描画するために、この Velocity テンプレートの割り当てを処理するでしょう。ここに、Velocity テンプレートの実際のコンテンツがあります。この場合、ポートレットの Java コードを書く必要はなく、実際のテンプレートを書くだけで良いことに注意してください。


#if (!$weather_city_info)
<BR>${l10n.WEATHER_PLEASE_CUSTOMIZE_YO_VM}<br><BR>
#else
<a href="http://www.wunderground.com/${weather_city_info}.html"
target="_blank"><img src="http://banners.wunderground.com/banner/${weather_style}/language/www/${weather_city_info}.gif"
alt="Click for ${weather_city_info} Forecast" border="0"></a>
#end


#if (!$weather_city_info)
<BR>${l10n.WEATHER_PLEASE_CUSTOMIZE_YO_VM}<br><BR>
#else
<a href="http://www.wunderground.com/${weather_city_info}.html"
target="_blank"><img src="http://banners.wunderground.com/banner/${weather_style}/language/www/${weather_city_info}.gif"
alt="Click for ${weather_city_info} Forecast" border="0"></a>
#end

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:

Jetspeed 2 とポートレット API では、ポートレットに処理を移譲するために、Velocity ブリッジ、もしくは JSP ブリッジを使うことが出来ます。この最も簡単なケースは、自身の呼び出しに JSP か Velocity サーブレットを割り当てるケースです。ここに、doView から JSP を割り当てる例があります。


protected void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException
{
    PortletContext context = getPortletContext();
    ResourceBundle resource = getPortletConfig().getResourceBundle(request.getLocale());
    request.setAttribute("viewMessage", resource.getString("preference.label.MyModeIsView"));
    PortletRequestDispatcher rd = context.getRequestDispatcher("/WEB-INF/demo/preference/pref-view.jsp");
    rd.include(request, response);
}


protected void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException
{
    PortletContext context = getPortletContext();
    ResourceBundle resource = getPortletConfig().getResourceBundle(request.getLocale());
    request.setAttribute("viewMessage", resource.getString("preference.label.MyModeIsView"));
    PortletRequestDispatcher rd = context.getRequestDispatcher("/WEB-INF/demo/preference/pref-view.jsp");
    rd.include(request, response);
}

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:

そして、ここに Velocity ブリッジを継承した WeatherPortlet の例があります。ここではポートレット API の User Preferences 機能を使っています。ここでは直接ディスパッチャーを作成していないにも関わらず、フレームワークが自動的にそれを実行していることに注意してください。


import org.apache.portals.bridges.velocity.GenericVelocityPortlet;
...

public class WeatherPortlet extends GenericVelocityPortlet
{
...

public void doView(RenderRequest request, RenderResponse response)
        throws PortletException, IOException
{
    Context context = super.getContext(request);

    String cityInfo = (String) request.getPortletSession().getAttribute(
            WEATHER_CITY_INFO);

    PortletPreferences prefs = request.getPreferences();
    String city = prefs.getValue(WEATHER_CITY, "Bakersfield");
    String state = prefs.getValue(WEATHER_STATE, "CA");
    String station = prefs.getValue(WEATHER_STATION, null);
    cityInfo = getCityInfo(city, state, station);
    context.put(WEATHER_CITY_INFO, cityInfo);

    String style = prefs.getValue(WEATHER_STYLE, "infobox");
    context.put(WEATHER_STYLE, style);
    response.setProperty("david", "taylor");
    super.doView(request, response);
}


import org.apache.portals.bridges.velocity.GenericVelocityPortlet;
...

public class WeatherPortlet extends GenericVelocityPortlet
{
...

public void doView(RenderRequest request, RenderResponse response)
        throws PortletException, IOException
{
    Context context = super.getContext(request);

    String cityInfo = (String) request.getPortletSession().getAttribute(
            WEATHER_CITY_INFO);

    PortletPreferences prefs = request.getPreferences();
    String city = prefs.getValue(WEATHER_CITY, "Bakersfield");
    String state = prefs.getValue(WEATHER_STATE, "CA");
    String station = prefs.getValue(WEATHER_STATION, null);
    cityInfo = getCityInfo(city, state, station);
    context.put(WEATHER_CITY_INFO, cityInfo);

    String style = prefs.getValue(WEATHER_STYLE, "infobox");
    context.put(WEATHER_STYLE, style);
    response.setProperty("david", "taylor");
    super.doView(request, response);
}

And here is the Velocity template to render the portlet content:

そして、ここにポートレットのコンテンツを描画するための Velocity テンプレートがあります。


#if (!$weather_city_info)
Please configure your Weather settings.
#else
<a href="http://www.wunderground.com/${weather_city_info}.html"  
target="_blank"><img src="http://banners.wunderground.com/banner/$!weather_style/language/www/${weather_city_info}.gif"
alt="Click for $weather_city_info Forecast" border="0"></a>
#end


#if (!$weather_city_info)
Please configure your Weather settings.
#else
<a href="http://www.wunderground.com/${weather_city_info}.html"  
target="_blank"><img src="http://banners.wunderground.com/banner/$!weather_style/language/www/${weather_city_info}.gif"
alt="Click for $weather_city_info Forecast" border="0"></a>
#end

[Converting a Turbine Action] Turbine アクションの変換

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 blocking phase, meaning that it must complete before the render phase for each portlet on the page can commence. Actions are usually some kind of user interaction that manipulates the Model of the MVC framework, such as a user submitting a form and updating the model, or adding or deleting a record. The concept 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.

ポートレット API は、ポートレットページの処理の間の実行フェーズをいくつか定義しています。アクションフェーズは、ポートレットの描画フェーズの前に実行されるように設計されています。1 つのポートレットだけを対象にした、1 つのアクションフェーズしか存在出来ません。アクションフェーズが完了すると、ページ上の全てのポートレットの描画フェーズが実行出来ます。したがって、アクションフェーズはブロッキングフェーズと言えます。これは、ページ上の各ポートレットの描画フェーズが始まる前に完了していなければいけない事を意味します。アクションは通常、MVC フレームワークの Model を操作する、ある種のユーザとの対話のようなものです。それは、ユーザがフォームに入力を行い、モデルが更新されたり、レコードが追加されたり消去されたりするというようなものです。このアクションの概念は、Turbine と Jetspeed 1 から Jetspeed 2 とポートレット API への移植をかなりうまく行います。Turbine がアクションごとに 1 クラスという概念を持つのに対して、ポートレット API は、全てのアクションを、ポートレットのメソッドを通して行うエントリポイントを持ちます。Spring MVC フレームワークのようなフレームワークは、アクションごとに一つのメソッドを持つモデルに対する、より良い抽象概念を提供します。

Lets again look at the WeatherPortlet with Jetspeed-1. First the xreg defines the actions:

ここで再び Jetspeed 1 の WeatherPortlet を見ましょう。まず、xreg がアクションを定義します。


        <parameter name="action" value="portlets.WeatherAction" hidden="true"/>


        <parameter name="action" value="portlets.WeatherAction" hidden="true"/>

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:

通常、Jetspeed 1 の webapp クラスローダ空間に置かれるアクションクラスを実装する必要があります。ここに WeatherAction のコードを示します。これは、Jetspeed 1 のフレームワーククラスである VelocityPortletAction を継承したものです。


public class WeatherAction extends VelocityPortletAction
{

    protected void buildNormalContext( VelocityPortlet portlet,
                                       Context context,
                                       RunData rundata )
    {

        String cityInfo = PortletConfigState.getParameter(portlet, rundata, WEATHER_CITY_INFO, null);
        //if (cityInfo == null)
        //{
            String city = portlet.getPortletConfig().getInitParameter(WEATHER_CITY);
            String state = portlet.getPortletConfig().getInitParameter(WEATHER_STATE);
            String station = portlet.getPortletConfig().getInitParameter(WEATHER_STATION);
            cityInfo = getCityInfo(city, state, station);            
        //}
        context.put(WEATHER_CITY_INFO, cityInfo);
        //PortletConfigState.setInstanceParameter(portlet, rundata, WEATHER_CITY_INFO, cityInfo);

        String style = PortletConfigState.getParameter(portlet, rundata, WEATHER_STYLE, "infobox");
        context.put(WEATHER_STYLE,style);
    }


public class WeatherAction extends VelocityPortletAction
{

    protected void buildNormalContext( VelocityPortlet portlet,
                                       Context context,
                                       RunData rundata )
    {

        String cityInfo = PortletConfigState.getParameter(portlet, rundata, WEATHER_CITY_INFO, null);
        //if (cityInfo == null)
        //{
            String city = portlet.getPortletConfig().getInitParameter(WEATHER_CITY);
            String state = portlet.getPortletConfig().getInitParameter(WEATHER_STATE);
            String station = portlet.getPortletConfig().getInitParameter(WEATHER_STATION);
            cityInfo = getCityInfo(city, state, station);            
        //}
        context.put(WEATHER_CITY_INFO, cityInfo);
        //PortletConfigState.setInstanceParameter(portlet, rundata, WEATHER_CITY_INFO, cityInfo);

        String style = PortletConfigState.getParameter(portlet, rundata, WEATHER_STYLE, "infobox");
        context.put(WEATHER_STYLE,style);
    }

In Jetspeed-1 there is some really bad architecture interfering with easily writing portlets. Here in our action, we are actually implementing the View portion of our code by populating the Velocity context with context.put statements. Please beware that all code implemented in the buildNormalContext method should be ported to the doView method of the Portlet API. Note how the actual portlet must be passed in as the first parameter to the buildNormalContext method.

Jetspeed 1 には、簡単にポートレットを作成するのを妨げる、良くない構造がいくつかありました。ここで我々は、実際に context.put ステートメントを持つ Velocity コンテキストを実装することにより、コードの View の一部分を実装しています。buildNormalContext で実装したすべてのコードは、ポートレット API の doView メソッドに移植しなくてはならない事に注意してください。実際のポートレットを、どのようにして 1 番目のパラメータとして、buildNormalContext メソッドに渡さなければならないのかに注意してください。

The actual action code implemented as do.. methods on your action class will need to be ported to the processAction method on the Portlet API.

アクションクラス中に、do で始まるメソッドとして実装される実際のコードは、ポートレット API の processAction メソッドへ移植する必要があります。


    public void doInsert(RunData rundata, Context context)
        throws Exception
    {


    public void doInsert(RunData rundata, Context context)
        throws Exception
    {

The doInsert method is linked by Turbine to an action in the Velocity template with the eventSubmit_ prefix:

Turbine は、doInsert メソッドと、eventSubmit_ プレフィックスを持つ Velocity テンプレートのアクションと関連付けます。


<input type="submit" name="eventSubmit_doInsert" value="${l10n.USER_FORM_ADD_USER_VM}"/>


<input type="submit" name="eventSubmit_doInsert" value="${l10n.USER_FORM_ADD_USER_VM}"/>

Here is the equivalent in the Portlet API (Jetspeed-2):

ここにポートレット API (Jetspeed 2) での同等のものがあります。


    public void processAction(ActionRequest actionRequest, ActionResponse actionResponse) 
        throws PortletException, IOException


    public void processAction(ActionRequest actionRequest, ActionResponse actionResponse) 
        throws PortletException, IOException

The Portlet API provides two parameters to the processAction method: the ActionRequest and ActionResponse.

ポートレット API は、processAction メソッドに 2 つのパラメータを用意しています。

[Request Parameters, Portlet Modes, Window States] リクエストパラメータ、ポートレットモード、ウィンドウの状態

Request parameters are accessed via RunData in Jetspeed-1:

Jetspeed 1 では、リクエストパラメータは RunData 経由でアクセスします。


	String name = rundata.getParameters().getString("username");


	String name = rundata.getParameters().getString("username");

With the Portlet API, portlet request parameters are accessed via the ActionRequest:

ポートレット API では、ポートレットのリクエストパラメータは、ActionRequest 経由でアクセスします。


   String name = actionRequest.getParameter("username");


   String name = actionRequest.getParameter("username");

With the Portlet API, you can check the Portlet Mode or Window State:

ポートレット API では、ポートレットモードとウィンドウの状態をチェック出来ます。


        if (actionRequest.getPortletMode() == PortletMode.EDIT)
        {
        	if ( !request.getWindowState().equals(WindowState.MINIMIZED))
        	{
        	...        


        if (actionRequest.getPortletMode() == PortletMode.EDIT)
        {
        	if ( !request.getWindowState().equals(WindowState.MINIMIZED))
        	{
        	...        

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 Spring MVC Portlet framework Here we demonstrate using portlet request parameters per form to map to specific actions:

基本的なポートレット API には、Jetspeed 1 のように、アクションとメソッドをマッピングする方法がありません。もし、このような振る舞いをしたいのであれば、Spring MVC Portlet framework を使うことをおすすめします。ここで、フォームからのポートレットのリクエストパラメータを使って、特定のアクションにマップする実例を挙げます。


		String action = actionRequest.getParameter(SecurityResources.PORTLET_ACTION);
        if (action != null && action.equals("remove.user"))
        {
            removeUser(actionRequest, actionResponse);
        }
        else if (action != null && action.equals("add.new.user"))
        {
            PortletMessaging.cancel(actionRequest, SecurityResources.TOPIC_USERS, SecurityResources.MESSAGE_SELECTED);
        }
        else if (action != null && action.equals("add.user"))
        {
            addUser(actionRequest);
        }
		...


		String action = actionRequest.getParameter(SecurityResources.PORTLET_ACTION);
        if (action != null && action.equals("remove.user"))
        {
            removeUser(actionRequest, actionResponse);
        }
        else if (action != null && action.equals("add.new.user"))
        {
            PortletMessaging.cancel(actionRequest, SecurityResources.TOPIC_USERS, SecurityResources.MESSAGE_SELECTED);
        }
        else if (action != null && action.equals("add.user"))
        {
            addUser(actionRequest);
        }
		...

[Persisting State: The Portlet Session] 状態の保持:ポートレットセッション

The Portlet API provides built-in support for persistence of Portlet state in the session. The Portlet Session is similar to the setTemp 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:

ポートレット API は、セッションへのポートレットの状態の保存を標準でサポートしています。ポートレットセッションは、Turbine/Jetspeed 1 の setTemp メソッド、もしくはサーブレット API に備わっているセッションのサポートと同様のものです。セッションは、現在のユーザのセッションと関係した持続的な状態です。ポートレット API によってサポートされる 2 種類のセッションの状態があります。

  • Application Session State: the session variable is shared by all portlets in a portlet application
  • Portlet Session State: the session variable is specific to the one portlet instance window
  • アプリケーションセッション: ポートレットアプリケーション内の全てのポートレットが共有するセッション変数
  • ポートレットセッション: 一つのポートレットウィンドウ特有のセッション変数

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:

Jetspeed 1 で Turbine RunData API を使って、どのようにセッション変数を取得し、設定するかを以下に示します。Jetspeed 1 でも Jetspeed 2 でも、セッションに格納するオブジェクトはシリアライズしなければいけないことに注意してください。

			
             rundata.getUser().setTemp(ACCOUNT_INFO, accountInfo);
             ...
             AccountInfo accountInfo = (AccountInfo)rundata.getUser().getTemp(ACCOUNT_INFO);

			
             rundata.getUser().setTemp(ACCOUNT_INFO, accountInfo);
             ...
             AccountInfo accountInfo = (AccountInfo)rundata.getUser().getTemp(ACCOUNT_INFO);

In here is the equivalent in Jetspeed-2 using the Portlet API:

Jetspeed 2 で、ポートレット API を使って同等の事をする例を以下に示します。

	
        AccountInfo accountInfo = (AccountInfo)
        	actionRequest.getPortletSession().getAttribute(ACCOUNT_INFO, PortletSession.PORTLET_SCOPE);
        -- or --
        AccountInfo accountInfo = (AccountInfo)        
	        actionRequest.getPortletSession().getAttribute(ACCOUNT_INFO, PortletSession.APPLICATION_SCOPE);        
		
		-- the setters --
		PortletSession session = actionRequest.getPortletSession();
		session.setAttribute(ACCOUNT_INFO, accountInfo, PortletSession.PORTLET_SCOPE);
		-- or --
		session.setAttribute(ACCOUNT_INFO, accountInfo, PortletSession.APPLICATION_SCOPE);		

	
        AccountInfo accountInfo = (AccountInfo)
        	actionRequest.getPortletSession().getAttribute(ACCOUNT_INFO, PortletSession.PORTLET_SCOPE);
        -- or --
        AccountInfo accountInfo = (AccountInfo)        
	        actionRequest.getPortletSession().getAttribute(ACCOUNT_INFO, PortletSession.APPLICATION_SCOPE);        
		
		-- the setters --
		PortletSession session = actionRequest.getPortletSession();
		session.setAttribute(ACCOUNT_INFO, accountInfo, PortletSession.PORTLET_SCOPE);
		-- or --
		session.setAttribute(ACCOUNT_INFO, accountInfo, PortletSession.APPLICATION_SCOPE);		

[Persisting State: User Preferences] 状態の保持: ユーザ設定

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 parameter XML elements. Looking at the XREG file in Jetspeed-1, we have:

ポートレット API には、第 2 の状態保持メカニズムが準備されています。それはユーザ設定 (User Preferences) です。ユーザ設定は、ユーザ毎 / ポートレット毎に保存される情報欄です。Jetspeed 1 で同等のものは、ポートレットインスタンスデータです。これは、Jetspeed 1 ポートレットレジストリに、名前と値のペアでパラメータとして XML 要素として保存されます。Jetspeed 1 の XREG ファイルで、以下のようなものを見つけることが出来ます。

	
        <parameter name="weather_city_info" value="US/IN/Bloomington" hidden="true"/>

	
        <parameter name="weather_city_info" value="US/IN/Bloomington" hidden="true"/>

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:

ポートレット API では、portlet.xml 配備記述子内で、設定のデフォルト値を定義できます。ユーザ固有の値は、Jetspeed 設定データベースに保存されます。以下に、配備記述子に定義される設定のデフォルト値の例を示します。

	
            <preference>
                <name>weather_city</name>
                <value>Oakland</value>
            </preference>

	
            <preference>
                <name>weather_city</name>
                <value>Oakland</value>
            </preference>

Jetspeed-1 provides the PortletInstance 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 user-specific 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.

Jetspeed 1 は、設定値情報にアクセスするために、ポートレットごとに PortletInstance インターフェースが準備されています。Jetspeed 2 では、設定情報はユーザごと、インスタンスごとであるのに対して、インターフェースの PortletInstance 経由でアクセスされる Jetspeed 1 の設定情報は、インスタンス (ポートレットウィンドウ) ごとに特有なだけとなります。これらの値は、ポートレットウィンドウに関連付けられた PSML ファイルに保存されます。ユーザがページを配置して、そのページに対してデフォルトのメカニズムを使ったとき、この値はユーザ特有であることに注意してください。

With Jetspeed-1, here we can retrieve PortletInstance data:

Jetspeed 1 で、PortletInstance データを取得する方法を以下に示します。


        // where "this" is a Jetspeed-1 Portlet object
    	PortletInstance instance = this.getInstance(rundata);
    	String value = instance.getAttribute("favoriteColor", "blue");
    	-- or --
    	this.getAttribute("favoriteColor", "blue", rundata);
    	
    	-- we can set preference data the same way in Jetspeed-1    	
    	PortletInstance instance = this.getInstance(rundata);
    	instance.setAttribute("favoriteColor", "red");
    	-- or --
    	this.setAttribute("favoriteColor", "red", rundata);


        // where "this" is a Jetspeed-1 Portlet object
    	PortletInstance instance = this.getInstance(rundata);
    	String value = instance.getAttribute("favoriteColor", "blue");
    	-- or --
    	this.getAttribute("favoriteColor", "blue", rundata);
    	
    	-- we can set preference data the same way in Jetspeed-1    	
    	PortletInstance instance = this.getInstance(rundata);
    	instance.setAttribute("favoriteColor", "red");
    	-- or --
    	this.setAttribute("favoriteColor", "red", rundata);

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:

Jetspeed 2 のポートレット API では、ポートレット設定をもっと直接的な方法で使用できます。


        PortletPreferences prefs = actionRequest.getPreferences();
        String color = prefs.getAttribute("favoriteColor", "blue");
        ...
        prefs.setAttribute("favoriteColor", "red");        
        prefs.store();        
        
        // note that you can also retrieve multivalues for prefs
        String values[] = actionRequest.getPreferences().getValues("stocks", defaultValues);
        
        // or retrieve all preferences as a Map
        Map allPrefs = actionRequest.getPreferences().getMap();        


        PortletPreferences prefs = actionRequest.getPreferences();
        String color = prefs.getAttribute("favoriteColor", "blue");
        ...
        prefs.setAttribute("favoriteColor", "red");        
        prefs.store();        
        
        // note that you can also retrieve multivalues for prefs
        String values[] = actionRequest.getPreferences().getValues("stocks", defaultValues);
        
        // or retrieve all preferences as a Map
        Map allPrefs = actionRequest.getPreferences().getMap();        

[Registries] レジストリ

The Jetspeed-1 Registries hold the following information:

Jetspeed 1 レジストリは以下のような情報を保持します。

  • Portlet Definitions
  • Security Definitions
  • Web Clients and Media Type Registries
  • Skins Definitions
  • Controller Definitions
  • Control Definitions
  • ポートレットの定義
  • セキュリティの定義
  • ウェブクライアントとメディアタイプの登録
  • スキンの定義
  • コントローラの定義
  • コントロールの定義

This section will guide you through how to migrate each of these registries from Jetspeed-1 to Jetspeed-2

このセクションでは、これらの登録を Jetspeed 1 から Jetspeed 2 へどのように移行するかを案内します。

[Portlet Definitions] ポートレットの定義

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 portlet-entry.

Jetspeed 1 では、すべてのポートレットは XREG ファイル (XMLレジストリ) として知られている XML ファイルに定義する必要があります。Jetspeed 2 では、データベースにポートレットの登録を保管します。Jetspeed 1 では、XML レジストリは、ファイルシステム上の Jetspeed の webapp 以下の WEB-INF/conf 以下にあります。そこに 1 つ以上のポートレット登録のエントリがあります。ポートレットは全て、エレメントタイプ portlet-entry で定義されています。

Migrating your Jetspeed-1 portlet registries to Jetspeed-2 registries requires writing a new Portlet API standard portlet.xml 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 jetspeed-portlet.xml 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 portlet-entry 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:

Jetspeed 1 のポートレットレジストリを Jetspeed 2 レジストリに移行するには、新しいポートレット標準の portlet.xml 定義ファイルを書く必要があります。我々は、この作業を行うための XSLT 変換は準備しません。portlet.xml は Java ポートレット標準で定義されているにも関わらず、Jetspeed では Jetspeed ポータル特有の仕様を定義する追加情報を書く事ができます。jetspeed-portlet.xml に Jetspeed 特有の保持できます。XREG 要素のうち、いくつかは portlet.xml にマッピングできます。その他は、以下の表にあるように jetspeed-portlet.xml にマッピングできます。以下の表は portlet-entry 要素のそれぞれの XML 属性を、ポートレット API の portlet.xml もしくは jetspeed-portlet.xml の同等のものに、どのようにマッピングするかについて述べています。この表で、XML 属性から、portlet.xml もしくは jetspeed-portlet.xml 内のどの XML 要素にマッピングするのかについて説明しています。

J1 AttributeJ2 Element
nameportlet-nameThe name of the portlet. This name is unique to each portlet application, but not unique system-wide.
hiddenNo equivalent in the Portlet API, not applicable.
typeNo equivalent in the Portlet API, not applicable.
parentNo equivalent in the Portlet API, not applicable.
applicationNo equivalent in the Portlet API, not applicable.
J1 属性J2 要素
nameportlet-nameポートレット名。この名前はポートレットアプリケーションごとにユニークである必要がありますが、システム全体ではユニークである必要はありません。
hiddenポートレット API に同等の物はなく、適用できません。
typeポートレット API に同等の物はなく、適用できません。
parentポートレット API に同等の物はなく、適用できません。
applicationポートレット API に同等の物はなく、適用できません。

Continuing with the Portlet XREG conversion, lets now look at how to convert the XML elements of the portlet-entry element. The table below describes how to map each XML element to its equivalent in the Portlet API portlet.xml:

ポートレット XREG の変換を続け、portlet-entry 要素の XML 要素を変換する方法を見ていきましょう。以下の表は、それぞれの XML 要素をポートレット API の同等の物にマップする方法について述べています。

J1 ElementJ2 Element
classnameportlet-classThe implementing Java class. This class will need to be ported at the source level.
media-typesupports, supports/mime-type, supports/portlet-modeMedia types supported by the portlet must be mapped to one or more supports elements, with subelements of mime-type and portlet-mode pairs.
meta-info/titletitleThe title of the Portlet.
meta-info/descriptiondescriptionThe description of the portlet
categoryportlet-info/keywordsWhere 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.
security-refjetspeed-portlet.xml: js:security-constraint-refIf 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
parameterinit-paramParameters in Jetspeed-1 should normally map to init-params in the Portlet API. These are read only values that can only be changed by the administrator
parameter@nameinit-param/nameThe name of the init parameter
parameter@valueinit-param/valueThe value of the init parameter
parameter/meta-info/descriptioninit-param/descriptionThe description of the init parameter
parameterportlet-preferences/preferenceAs well as migrating to init-params, parameters may also be migrated as default preferences. Note that preferences can optionally be read-only.
parameter@nameportlet-preferences/preference/nameThe name of the preference
parameter@valueportlet-preferences/preference/valueThe value of the preference
parameter@hiddenportlet-preferences/preference/read-onlyOptionally you map want to map hidden values to read-only (true/false)
J1 ElementJ2 Element
classnameportlet-classJava クラスの実装。このクラスはソースレベルで移植の必要があります。
media-typesupports, supports/mime-type, supports/portlet-modeポートレットがサポートするメディアタイプは、mime-typeportlet-mode のペアの子要素を含む、1 つ以上の supports 要素にマップしなければいけません。
meta-info/titletitleポートレットのタイトル。
meta-info/descriptiondescriptionポートレットの説明。
categoryportlet-info/keywords複数のカテゴリ要素があるところでは、キーワードはカンマ区切りで書かれます。Jetspeed 2 では、Portlet-Selector 管理ポートレットで、キーワードに基づいてカテゴリを設定できます。
security-refjetspeed-portlet.xml: js:security-constraint-refもし、セキュリティ制約の定義を移植する場合、同じセキュリティ定義名を使用することができます。セキュリティ制約定義は portlet.xml ではなく、jetspeed-portlet.xml から参照されます。
parameterinit-paramJetspeed 1 のパラメータは、通常はポートレット API の init-param にマップすべきです。これらは、管理者によってのみ変更する事が出来る読み取り専用の値です。
parameter@nameinit-param/name初期化パラメータの名前。
parameter@valueinit-param/value初期化パラメータの値。
parameter/meta-info/descriptioninit-param/description初期化パラメータの説明。
parameterportlet-preferences/preferenceinit-param の移行と同様に、パラメータもデフォルトの設定に移行しても良い。設定が読み取り専用かどうかは任意であることに注意してください。
parameter@nameportlet-preferences/preference/name設定の名前。
parameter@valueportlet-preferences/preference/value設定の値。
parameter@hiddenportlet-preferences/preference/read-only読み取り専用の隠し値にマップするかどうか選択できます。(true/false)

[Security Definitions] セキュリティの定義

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 security-entry.

Jetspeed 1 は、セキュリティ制約の XML 定義言語をサポートしています。それは、Jetspeed 2 の XML でのセキュリティ制約の定義に非常に良く似ています。Jetspeed 1 は、全てのセキュリティの定義を、XREG ファイル (XML レジストリ) として知られる XML ファイル内に定義する必要があります。Jetspeed 2 は、セキュリティレジストリは XML ファイル、もしくはデータベースに保持します。Jetspeed 1 では、XML レジストリは Jetspeed webapp の WEB-INF/conf 以下のファイルシステム上にあります。1 つ以上のセキュリティレジストリのエントリが存在します。全てのセキュリティ制約は security-entry タイプの要素で定義します。

Migrating your Jetspeed-1 security constraints registries to Jetspeed-2 registries requires writing a new page.security 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 security-entry 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:

あなたの Jetspeed 1 のセキュリティ制約レジストリを Jetspeed 2 レジストリに移行するには、新しい page.security XML 定義ファイルを書く必要があります。我々は移行のための XSLT ファイルは準備しません。以下の表は、security-entry 要素の XML 属性をポートレット API の portlet.xml、もしくは jetspeed-portlet.xml ファイルの同等のものにマッピングする方法を述べたものです。この表で XML 属性から portlet.xml もしくは jetspeed-portlet.xml の XML 要素へのマッピングをしていることに注意してください。

J1 AttributeJ2 Attribute
security-entry@namesecurity-constraints-def@nameThe name of the security constraint definition. This name is unique to the entire page.security file.
meta-info/titleNo equivalent in Jetspeed-2, not applicable.
meta-info/descriptionNo equivalent in Jetspeed-2, not applicable.
accesssecurity-constraintJetspeed-1 security-entries contain 0..n access elements, Jetspeed-2 security-constraint-defs contain 0..n security-constraint elements.
access@actionsecurity-constraint/permissions Actions in Jetspeed-1 are called Permissions in Jetspeed-2. Both versions support wildcarding with the * character.
  • Jetspeed-1 default actions are view, customize, maximize, minimize, info, close.
  • Jetspeed-2 default permissions are view, edit, help, print
access/allow-if@rolesecurity-constraint/rolesJetspeed-1 constrains by role through allow-if elements with a role attribute. Jetspeed-2 constrains by role with the roles element and a comma-separated list of one or more roles
access/allow-if@groupsecurity-constraint/groupsJetspeed-1 constrains by group through allow-if elements with a group attribute. Jetspeed-2 constrains by group with the groups element and a comma-separated list of one or more groups
access/allow-if@usersecurity-constraint/usersJetspeed-1 constrains by user through allow-if elements with a user attribute. Jetspeed-2 constrains by user with the users element and a comma-separated list of one or more users, or the wildcard * to specify all users.
access/allow-if-ownersecurity-constraints/ownerYou 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.
J1 AttributeJ2 Attribute
security-entry@namesecurity-constraints-def@nameセキュリティ制約の定義の名前。この名前は page.security ファイル内でユニークです。
meta-info/titleJetspeed 2 には同等の物がなく、適用できません。
meta-info/descriptionJetspeed 2 には同等の物がなく、適用できません。
accesssecurity-constraintJetspeed 1 の security-entries は 0 〜 n の access 要素を含みます。Jetspeed 2 の security-constraint-defs は 0 〜 n の security-constraint 要素を含みます。
access@actionsecurity-constraint/permissions Jetspeed 1 のアクション (Action) は Jetspeed 2 ではパーミッション (Permissions) と呼ばれます。両バージョン共、"*" 文字のワイルドカードをサポートしています。
  • Jetspeed 1 のデフォルトのアクションは、view, customize, maximize, minimize, info, close です。
  • Jetspeed 2 のデフォルトのパーミッションは view, edit, help, print です。
access/allow-if@rolesecurity-constraint/rolesJetspeed 1 では、role 属性を持った allow-if 要素を使ってロールによる制限を加えます。Jetspeed 2 では、roles 要素と 1 つ以上のロールのカンマ区切りのリストを使って、ロールによる制限を加えます。
access/allow-if@groupsecurity-constraint/groupsJetspeed 1 では、group 属性を持った allow-if 要素を使ってグループによる制限を加えます。Jetspeed 2 では、groups 要素と 1 つ以上のグループのカンマ区切りのリストを使って、グループによる制限を加えます。
access/allow-if@usersecurity-constraint/users Jetspeed 1 では、user 属性を持った allow-if 要素を使ってユーザによる制限を加えます。Jetspeed 2 では、users 要素と 1 つ以上のロールのカンマ区切りのリストを使うか、ワイルドカード "*" で全てのユーザを指定して、ロールによる制限を加えます。
access/allow-if-ownersecurity-constraints/ownerページの所有者のみアクセス可能であるという制約を設定可能です。Jetspeed 1 では、ページの場所によってこのことを表します。Jetspeed 2 では、owner 要素として、明確に名前を記述しなければなりません。

[Web Clients and Media Type Registries] ウェブクライアントとメディアタイプの登録

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.

ウェブクライアントとメディアタイプの登録は、既に Jetspeed 2 に移植され、コアシステムの一部となっています。Jetspeed 2 は、これらの登録をデータベースに保存します。しかし、これらのテーブルは、以下の種データのセクションで述べるように、種データを使ってデータ登録できます。

[Skins] スキン

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:

登録されたスキンは、直接は Jetspeed 2 には移行は出来ません。Jetspeed 2 は、より標準的な CSS ベースのスキンアプローチに移行しました。スキンで利用出来るテクニックには以下の 2 つがあり、それらを組み合わせることが可能です。

  • 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.
  • 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
  • 1. ポートレット API 標準スキン - ポートレット標準の PLT.C を参照してください。CSS スタイルの標準が、ポートレットのコンテンツのグローバルなスキンとして定義されています。
  • 2. Jetspeed デコレータ - デコレータは、自身のスキンを定義出来ます。そして、ポートレットはこれらのスタイルにアクセス出来ます。Jetspeed のデフォルトのデコレータも、PLT.C と同様のスタイルで定義されています。

[Controllers] コントローラ

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.

コントローラは Jetspeed 2 では廃止予定となりました。Java のコードに変換するための直接のマッピングはありません。代わりに、新しいレイアウトポートレットに書き換えるか、単純に、非常にフレキシブルな Jetspeed 付属の既存のレイアウトポートレットの一つを使うかのどちらかにする必要があります。Jetspeed のデフォルトのレイアウトポートレットは、複数列のグリッド、ポートレットのネスト、ポートレットカスタマイザを使った完全なカスタマイズをサポートします。

[Controls]コントロール

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.

コントロールは Jetspeed 2 で廃止予定となりました。Java のコードに変換するための直接のマッピングはありません。代わりに、新しいポートレットデコレータに書き換えるか、より簡単に、非常にフレキシブルな Jetspeed 付属の既存のポートレットデコレータの一つを使うかのどちらかにする必要があります。

[PSML] PSML

[The Jetspeed Sitemap] Jetspeed のサイトマップ

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.

Jetspeed のサイトマップは、ポータルの全ページのナビゲーションスペースを定義します。バージョン 1 と 2 は、階層構造のファイルシステム風のサイトマップを持ちます。両方のバージョン共に、ルートフォルダの / を持ち、サブフォルダのツリーを持ちます。それぞれのサブフォルダは、ページやサブフォルダを持つことが出来ます。

[Site Resources] サイトのリソース

In Jetspeed-2, there is a well-defined portal resources that do not always have equivalents in Jetspeed-1:

2.x1.xFile
PagePageA .psml file.
Folder--A folder.metadata file, one per folder, N/A in Jetspeed-1
Link--A .link file, N/A in Jetspeed-1
Menu--Menus are defined in folder.metadata, N/A in Jetspeed-1

Jetspeed 2 では、良く定義されるポータルリソースがありますが、Jetspeed 1 に同等のものがあるとは限りません。

2.x1.xファイル
ページページA .psml ファイル。
フォルダ--フォルダ毎に一つ存在する folder.metadata ファイル。Jetspeed 1 は該当なし。
リンク--.link ファイル。Jetspeed 1 は該当なし。
メニュー--メニューは folder.metadata ファイルで定義します。Jetspeed 1 は該当なし。

[Reserved Directories] 予約済みのディレクトリ

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.

1.x2.x
user_userHolds all user folders
role_roleHolds all role folders
group_groupHolds all group folders
{mediatype}_mediatypeContent per mime/mediatype
{language}_lanaguageContent per language
{country}_countryContent per country code

Where the J1 directory names are actually the names of the reserved directory, such as {mediatype} would be actually html or {language} would be en. J2 requires specifing control directories (_) such as _mediatype/html, or _language/en

両方のバージョン共で、利用可能な予約済みのディレクトリがあります。そのネーミングは少し違います。Jetspeed 2 で、アンダースコア (_) で始まるディレクトリは、全てコントロール用のディレクトリとみなされ、プロファイラ (後述) が、ユーザ名やユーザのロール名のような実行時基準を基に、特別なディレクトリを配置するのに使われます。Jetspeed 1 には、プロファイリングルール内にハードコードされた、予約済み (コントロール) ディレクトリの固定名があります。

1.x2.x
user_user全ユーザのフォルダを保持します。
role_role全ロールのフォルダを保持します。
group_group全グループのフォルダを保持します。
{mediatype}_mediatypemime/mediatype ごとのコンテンツ
{language}_lanaguage言語ごとのコンテンツ
{country}_countryカントリーコードごとのコンテンツ
J1 のディレクトリ名は、実際に予約ディレクトリ名の場所になります。{mediatype} は実際は html、{language} は en のようになるでしょう。J2 では、_mediatype/html_language/enのように、コントロールディレクトリ (_) を指定する必要があります。

[Profiling] プロファイリング

The Profiling algorithm discovers the correct page to display during a request. J1 has only two hard-coded algorithm for finding pages:

プロファイリングのアルゴリズムは、リクエストに対して表示するページを正しく見つけます。J1 には、ページを見つけるための 2 つのハードコードされたアルゴリズムだけがあります。

  • J1 user/mediatype/language/country fallback
  • J1 rollback
  • J1 user/mediatype/language/country fallback
  • J1 rollback

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

これらの設定は、システム全体に有効で、ポータル基盤ごとに変更しなければいけません。J1 は、メディアタイプ、言語、国の順の明確なコンテナ順を期待します。

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.

J2 は、実行時のユーザ情報を取得し、プロファイリングルールを使うことで、ルール内に定義されたアルゴリズムに基ずくルールを見つけます。J2 のプロファイリングルールは、ユーザごとに定義されます。しかし、システム全体に共通なプロファイリングルールも持ちます。

[Differences in PSML Page] PSML ページの違い

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.

Jetspeed 1 では、全てのポートレットは XREG ファイル (XML レジストリ) である XML ファイル内で定義する必要がありました。Jetspeed 2 では、ポートレットのレジストリはデータベース内に保管されます。Jetspeed 1 では、PSML ファイルは、WEB-INF/psml 以下の Jetspeed の webapp フォルダ以下に保管出来ます。Jetspeed 2 では、PSML ファイルは、WEB-INF/pages もしくは WEB-INF/min-pages 以下の Jetspeed の webapp フォルダ以下に保管出来ます。Jetspeed 2 は、PSML ファイルをデータベース内に保管する機能もサポートしています。

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:

Jetspeed 1 の PSML ファイルを Jetspeed 2 の PSML ファイルに変換するには、ファイルを手で変換するか、データベースの変換ユーティリティを書くか、XSLT 変換を書く必要があります。我々は、変換を実行出来るような XSLT 変換は準備しません。以下の表は、それぞれの XML 要素や属性が Jetspeed 1 と Jetspeed 2 でどのようにマップされるのかを説明しています。

J1 ElementJ2 Element
portletspageThe outermost container of all content found on a PSML page.
portlets@idpage@idSystem wide unique identifier for this page.
metainfo/titletitleThe Page Title.
security-refsecurity-constraints/security-constraints-refThe security constraint reference (0..1 in Jetspeed-1, 0..n in Jetspeed-2)
controldefaults/portlet-decoratorRequires 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.
controllerdefaults/layout-decoratorRequires 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.
portlets/portlets/...page/fragment/..., type="layout"Sub-containers of fragments or portlets. In Jetspeed-2, fragments can be either containers or portlet definitions. Only fragments with the type of layout can be a container holding more fragments and containers.
portlets/portlets/controllerpage/fragment@type=layout@name={layout-name}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.
portlets/entrypage/fragment/fragment@type="portlet"A portlet window on a page.
entry@idfragment@idThe system-wide unique ID of the portlet window.
entry@parentfragment@nameThe portlet registry reference. In Jetspeed-2 the name of the portlet must be specified as PA::portlet-name
entry/layout/property@name="column"@value={column}fragment/property@name="column"@value={column}The property containing the column position
entry/layout/property@name="row"@value={row}fragment/property@name="row"@value={row}The property containing the row position
J1 要素J2 要素
portletspagePSML ページ内の全てのコンテンツの中でもっとも外側のコンテナ。
portlets@idpage@idこのページに対するシステム全体でユニークな識別子。
metainfo/titletitleページのタイトル。
security-refsecurity-constraints/security-constraints-refセキュリティ制約参照 (Jetspeed 1 では 0..1、Jetspeed 2 では 0..n)
controldefaults/portlet-decoratorあなたのコントロールを J2 ポートレットデコレータに変換する必要があるか、もしくは少なくとも名前から Jetspeed 2 の既存のデコレータのマッピングを行う必要があります。もしくはグローバルなポートレットデコレータを使い、この任意の設定を無視する事も出来ます。
controllerdefaults/layout-decoratorあなたの Turbine コントローラ、画面ナビゲーションを J2 のレイアウト (ページ) デコレータに変換する必要があるか、もしくは少なくとも名前から Jetspeed 2 の既存のページデコレータへのマッピングを行う必要があります。グローバルなポートレットデコレータを使い、この任意の設定を無視することも可能です。
portlets/portlets/...page/fragment/..., type="layout"フラグメントもしくはポートレットのサブコンテナ。Jetspeed 2 では、フラグメントはコンテナかポートレット定義かの両方が可能です。layout タイプのフラグメントだけが、さらにフラグメントとコンテナを保持するコンテナとなることが出来ます。
portlets/portlets/controllerpage/fragment@type=layout@name={layout-name}コントローラは大体、name 属性によって名前の付いた、type = layout のフラグメントにマップされます。レイアウトはポートレットとして実装されており、PA::portlet-name として指定しなければいけません。
portlets/entrypage/fragment/fragment@type="portlet"ページ内のポートレットウィンドウ。
entry@idfragment@idシステム全体でユニークなポートレットウィンドウの ID。
entry@parentfragment@nameポートレットレジストリ参照。Jetspeed 2 では、ポートレットの名前は PA::portlet-name として指定しなければいけません。
entry/layout/property@name="column"@value={column}fragment/property@name="column"@value={column}列の位置を含むプロパティ。
entry/layout/property@name="row"@value={row}fragment/property@name="row"@value={row}行の位置を含むプロパティ。

[Menus vs Tabs] メニュー vs タブ

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 tabs. Tabs are defined within a PSML page. Tabs are simply subcontainers in the PSML page, defined by the portlets 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.

Jetspeed 1 と Jetspeed 2 の間には、ナビゲーションの外観やメニューに大きな違いがあります。Jetspeed 1 は、メニューナビゲーションを タブ 間のナビゲーションに制限しています。タブは PSML ページ内で定義されます。タブは、portlets 要素で定義される、PSML ページの単なる子のコンテナです。Jetspeed 1 が (訳注:ここは Jetspeed 2 の誤りであると思われます。) 他のページへのナビゲーションをサポートするのに対して、タブメニューは外部リンクとして動作する特定のポートレットを書かない限りは、それを直接はサポートしません。

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.

Jetspeed 2 のメニューナビゲーションは、ポータルサイト上に直接マッピングされます。それゆえ、メニュータブはポータルリソースを表します。Jetspeed 2 のメニューは、フォルダやページやリンクを指し示すことができます。このことは、より自然にユーザが全ポータルサイト内を移動することが可能になります。

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:

Jetspeed 1 から Jetspeed 2 へ PSML を移行する場合、カードやタブコントローラと言った Jetspeed 1 の進んだ機能を使っているかどうかで、Jetspeed 2 への移行が出来る、出来ないが分かるでしょう。移行ツールがないことを考慮して、以下の二つのオプションを当面残してあります。

  • Rewrite your PSML files to better map to the Jetspeed-2 site constructs, folders and multiple pages.
  • Enhance Jetspeed-2 to support card and tab controller behavior
  • Jetspeed 2 のサイト構造、フォルダ、複数ページにより良くマッピングする PSML ファイルの書き換え。
  • カードやタブコントローラの動きをサポートする Jetspeed 2 機能の強化。

[XML API - Seed Data] XML API - 種データ

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.

Jetspeed 2 には、あなたのポータルに初期「種」データを注入するための XML API が定義されています。あなたの種データを XML API 経由で注入することは、データベース特有のデータを注入したり、難しい SQL スクリプトを読む代わりとなります。加えて、XML API はデータをインポート、エクスポートしたり、あなたの Jetspeed 2 データベースをバックアップしたりリストアしたりするのにも使えます。

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.

XML API は、あなたの Jetspeed ポータルのメンテナンスサイクル全体での移行パスも提供します。XML API は、最初にバージョン 2.1 で実装されました。バージョン 2.1 から 2.2 へデータを移行するために、XML API を両バージョンで使って (エクスポートとインポートを行うことにより) 移行を行うことが可能です。

As of 2.1, the Jetspeed API supports the following elements:

2.1 時点で、Jetspeed API は、以下の要素をサポートします。

ElementDescription
MimeTypesMime Types supported by the portal such as text/html, text/xhtml....
MediaTypesMediat Types supported by the portal such as html, xml, wml...
CapabilitiesGeneral capabilities of web clients that access the portal
ClientsSupported Web Clients by the portal
RolesDefine all roles defined to the initial configuration of the portal
GroupsDefine all groups defined to the initial configuration of the portal
UsersDefine all initial users defined to the initial configuration of the portal, minimally admin and guest(anon) users
PermissionsDefine initial J2EE security policy for this portal. Note that permissions are turned off by default.
ProfilingRulesDefine all the profiling rules in the initial portal such as role fallback, user-role-fallback, j1-emulation, default-j2, subsites and more
要素説明
MimeTypesポータルがサポートする text/html や text/xhtml などのような Mime Types。
メディアタイプポータルがサポートする html, xml, wml 等のようなメディアタイプ。
機能ポータルにアクセスするウェブクライアントに共通の機能。
クライアントポータルがサポートするウェブクライアント。
ロールポータルの初期設定で定義される全てのロール。
グループポータルの初期設定で定義される全てのグループ。
ユーザポータルの初期設定で定義される全てのユーザ。最少で admin と guest(anon) ユーザ。
パーミッションポータルに対する初期定義される J2EE セキュリティポリシー。パーミッションはデフォルトではオフになっていることに注意。
プロファイリングルールポータルに初期で定義されるすべてのプロファイリングルール。例えば role fallback, user-role-fallback, j1-emulation, default-j2, subsites などのような。

[Where to Get Started?] どこから始めれば良いですか?

The best place to get started is to create your own custom portal. This process is defined online at Apache. The Jetspeed Tutorial 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.

はじめに、あなた自身のカスタムポータルを作成すると良いでしょう。このプロセスは、Apache でオンライン上で定義されます。Jetspeed チュートリアル は、あなた自身の (カスタム) Jetspeed ポータルの第一歩にあなたを導くでしょう。それには、XML 種データ、PSML、カスタムデコレーション、ポートレットアプリケーションの設定も含まれます。