ページの先頭行へ戻る
 Apcoordinatorユーザーズガイド
FUJITSU Software
付録C 旧バージョンとの互換情報 > C.2 Webアプリケーション
前次

C.2 Webアプリケーション

ujiall.tld以外のタグライブラリディスクリプタを使用したアプリケーションの修正

INTERSTAGE WEBCOORDINATOR が提供していた以下のタグライブラリディスクリプタを使用したアプリケーションの場合、Webアプリケーション環境定義ファイル(web.xml)の修正と、タグライブラリファイルujiall.tldのコピーが必要です。

修正は以下のように行います。

なお、修正のないソースの再コンパイルは必要ありません。

UJIタグの新機能を使用する場合の修正

以前のバージョンのApcoordinatorや、INTERSTAGE WEBCOORDINATORで動作するアプリケーションにおいて、UJIタグの新機能を利用する場合は、タグライブラリファイルujiall.tldを新しいものに置き換える必要があります。 Apcoordinatorのタグライブラリファイルujiall.tldを、WebアプリケーションのWEB-INFフォルダに上書きコピーしてください。このとき、修正のないソースの再コンパイルは必要ありません。

uji:controlSectionタグを使用している場合の修正

uji:controlSectionタグは提供されません。 uji:controlSectionタグを使ったJSPは修正しなくても実行できますが、 uji:controlSectionタグを使用しない場合と同じ動作となります。

二重処理を防止するには、uji:formタグのpostOnceアトリビュート、または、HttpControlStateProfileクラスによる二重処理防止機能を使用してください。二重処理防止機能については、“17.1.5 高度なセション管理”を参照してください。

なお、以下の条件の場合、uji:controlSectionタグを使用した場合と使用しない場合とで、エラーページ表示時の動作に違いがあります。

この場合、エラーページが以下のように表示されます。

なお、JSPは画面表示を行う手段であるため、例外を発生させるような要因は事前にビジネスクラスで検出し、JSP内では例外が発生しないようにJSP、データBean、ビジネスクラスを作成することを推奨します。

uji:switchタグの動作の違い

J2EE仕様への適合向上と性能向上の目的で、UJIタグの評価方法に変更が加えられました。これにより、INTERSTAGE WEBCOORDINATOR と Apcoordinatorとで以下の場合にuji:switchタグの動作に違いがあります。

  1. uji:switchタグにbeanアトリビュートを指定し、かつ、

  2. uji:caseタグのコンテントでUJIタグを使用し、かつ、

  3. 2のUJIタグでbeanアトリビュートを指定している場合。

上記の場合、uji:caseタグのコンテントにあるUJIタグの評価タイミングに違いがあります。 INTERSTAGE WEBCOORDINATORの場合、uji:caseの条件が評価され、条件が成立した場合にuji:caseのコンテントのUJIタグが評価されます。Apcoordinatorの場合、uji:caseのコンテントにUJIタグが出現した時点で評価されます。

この違いにより発生する影響について説明します。以下の例を参照してください。 

<uji:switch bean="body" property="fullMode"> 
  <uji:case cls="true"> 
    <uji:comboBox bean="body" property="teamList" /> 
    ...
  </uji:case>
  <uji:case> 
    ...
  </uji:case>
</uji:case>

プロパティfullModeの値がfalseの場合、cls="true"を指定したuji:caseの条件は成立しません。この場合でも、Apcoordinatorの場合はuji:caseのコンテントにあるuji:comboBoxタグが評価されます。ここで、"body"データBeanのtermListプロパティの値がnullの場合、uji:comboBoxが使用する項目クラスが取得できないため例外が発生します。一方、INTERSTAGE WEBCOORDINATORの場合はuji:comboBoxが評価されないため例外は発生しません。

上記条件に該当する場合、アプリケーションを次のどちらかの方法で修正することにより、Apcoordinatorでも動作します。

uji:includeタグ、uji:useBeanタグで参照するデータBeanのスコープの違い

サブウィンドウ機能およびフレーム機能対応のため、uji:includeタグ、uji:useBeanタグで使用するデータBeanのスコープが、INTERSTAGE WEBCOORDINATOR V3.0L20と比べて変更になっています。

uji:includeタグ、uji:useBeanタグの動作をINTERSTAGE WEBCOORDINATOR V3.0L20と同じにするには、初期化パラメタuji.includeSessionScopeBeanにfalseを指定してください。初期化パラメタはWebアプリケーション環境定義ファイルに記述します。以下は記述例です。 

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
                          http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
      version="2.4">
  <context-param>
    <param-name>factory</param-name>
    <param-value>sample2.Sample2Factory</param-value>
  </context-param>
  <context-param>
    <param-name>uji.includeSessionScopeBean</param-name>
    <param-value>false</param-value>
  </context-param>
  <jsp-config>
    <taglib>
      <taglib-uri>uji-taglib</taglib-uri>
      <taglib-location>/WEB-INF/ujiall.tld</taglib-location>
    </taglib>
  </jsp-config>
</web-app>

uji.methodリクエストパラメタのデフォルトでの使用可否状態の変更

Apcoordinator V5.0L10、または、INTERSTAGE WEBCOORDINATORで作成したアプリケーションで、isUjiMethodAvailableメソッドをデフォルトのまま使用し、uji.methodリクエストパラメタを使用している場合は、アプリケーションの修正が必要です。ユーザ定義のアプリケーションクラスを作成し、isUjiMethodAvailableメソッドをオーバライドしてtrueを返却するようにしてください。アプリケーションクラスについては、“3.4 アプリケーションクラス”を参照してください。

HttpServletRequestから取得されるリクエストパラメタの文字エンコーディング変換の有無の違い

送信データの文字エンコーディング変換をApcoordinatorまたはINTERSTAGE WEBCOORDINATORで処理している場合、 Apcoordinator V5.0L10、または、INTERSTAGE WEBCOORDINATORでは、 javax.servlet.http.HttpServletRequestからリクエストパラメタを取得すると、Apcoordinator または INTERSTAGE WEBCOORDINATORによって文字エンコーディングの変換が実施済みの文字列が得られます。

Apcoordinator V5.0L10またはINTERSTAGE WEBCOORDINATORで作成したアプリケーションで以下の処理を行っている場合には、アプリケーションを修正して、com.fujitsu.uji.util.Parametersクラスからリクエストパラメタを取得してください。

Parametersクラスからは、Apcoordinatorによって文字エンコーディングの変換が行われた文字列が取得されます。以下は、ビジネスクラスのメソッドおいて、Parametersクラスからリクエストパラメタ"userName"の値を取得する例です。 

import com.fujitsu.uji.GenericHandler;
import com.fujitsu.uji.DispatchContext;
import com.fujitsu.uji.http.HttpDispatchContext;
import com.fujitsu.uji.util.Parameters;

public class SampleHandler extends GenericHandler {
    public void someMethod(DispatchContext context, BodyBean dataBean) {
        Parameters parameters = ((HttpDispatchContext)context).getParameters();
        String value = parameters.getSingleValue("userName");
        ...
    }
}

アップロード可能なファイルサイズのデフォルトの上限値の変更

セキュリティ強化のため、アップロード可能なファイルサイズのデフォルトの上限値を16Mバイトに設定しています。 Apcoordinator V5.0L10 および INTERSTAGE WEBCOORDINATORでは、デフォルトではサイズの制限はありません。

Apcoordinator V5.0L10またはINTERSTAGE WEBCOORDINATORで作成したアプリケーションで以下に該当する場合は、アプリケーションを修正して、ファイルサイズの上限値を変更する必要があります。

修正は、アプリケーションクラスにgetMimeTransferSizeLimitメソッドをオーバーライドして、アップロード可能なファイルサイズの上限値を返却するようにしてください。上限値の単位はバイトです。以下は、getMimeTransferSizeLimitメソッドの記述例です。 

import com.fujitsu.uji.ApplicationProfile;

public class SampleApplication extends ApplicationProfile {
    public long getMimeTransferSizeLimit() {
        // ファイルサイズの上限値を32Mバイトに指定します。
        return 32*1024*1024;
    }
}

なお、getMimeTransferSizeLimitメソッドで0を返すことによってサイズの制限を無くすことができますが、セキュリティの観点から上限値を設定することを推奨します。

UJIタグが生成するHTMLの変更

Apcoordinatorのバージョンアップに伴う機能追加や最適化のために、“UJIタグリファレンス”に記載の仕様の範囲内で、UJIタグが生成するHTMLパターンが変更されています。変更内容には、HTMLタグの追加・削除、リクエストパラメタの変更が含まれます。 HTML比較による自動テストツールを利用する場合などは、差異となります。

注意

Apcoordinatorを新しいバージョンに置き換えた場合でもアプリケーションが正常に動作するようにするため、“UJIタグリファレンス”に記載されている場合を除き、UJIタグが生成するHTMLを仮定した処理は作成しないでください。

uji:tableViewタグおよびuji:treeViewタグのアトリビュートの修正

uji:tableViewタグおよびuji:treeViewタグの以下の問題を修正しました。

  1. JSPファイル1個の中でuji:tableViewタグまたはuji:treeViewタグを2個以上使用し、2個目以降のタグでアトリビュートの値を省略した場合にデフォルト値が適用されず、以前実行されたタグのアトリビュートで指定した値が適用される場合があります。

    この問題が発生するのは、uji:tableViewタグとuji:treeViewタグの以下のアトリビュートで";"で区切った値を指定し、区切られた値の一部を省略した場合です。

    • columnWidth

    • columnInputWidth

    • columnInputHeight

    • indentIcon

    • indentIconUseImage

    • header

    • headerInsets

    • headerBackground

    • headerForeground

    • headerFontStyle

    • headerFontWeight

    • headerFontSize

    • headerTextDecoration

    • headerAlignmentHorizontal

    • headerAlignmentVertical

    • headerRuleWidth

    • headerRuleColor

    • headerRuleType

    • headerNoWrap

    • headerUseImage

    • dataInsets

    • dataBackground

    • dataForeground

    • dataFontStyle

    • dataFontWeight

    • dataFontSize

    • dataTextDecoration

    • dataAlignmentHorizontal

    • dataAlignmentVertical

    • dataRuleWidth

    • dataRuleColor

    • dataRuleType

    • dataNoWrap

    • dataUseImage

    • dataStripeBackground

    • dataEmpty

    • dataEditable

    • dataCellType

  2. JSPファイル1個の中でuji:tableViewタグまたはuji:treeViewタグを2個以上使用し、そのタグでmultiRowアトリビュートを使用した場合に、2個目以降のタグでは以前実行されたタグのmultiRowアトリビュートの値が使用される場合があります。

これらの問題は以下の製品で発生します。本製品では修正済みであるため、以下の製品で問題が発生していたアプリケーションを本製品に移行するとタグの動作が変わります。

移行前と同じ動作とするには、以下のようにJSPを修正してください。

各アトリビュートの指定方法の詳細は、“UJIタグリファレンス”のuji:tableViewタグ、uji:treeViewタグの解説を参照してください。

web.xmlの記述形式の違い

Servlet仕様バージョン2.4では、web.xmlの記述形式が変更になりました。以前の形式のweb.xmlをServlet仕様バージョン2.4の形式に移行する場合は、以下のとおり書き換えてください。

以下は書き換えの例です。

修正前 

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE web-app
   PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
   "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
  <context-param>
    <param-name>factory</param-name>
    <param-value>sample2.Sample2Factory</param-value>
  </context-param>
  <servlet>
    <servlet-name>download</servlet-name>
    <servlet-class>updown.DownloadServlet</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>download</servlet-name>
    <url-pattern>/download</url-pattern>
  </servlet-mapping>
  <taglib>
    <taglib-uri>uji-taglib</taglib-uri>
    <taglib-location>/WEB-INF/ujiall.tld</taglib-location>
  </taglib>
</web-app>

修正後 

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
                          http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
      version="2.4">
  <context-param>
    <param-name>factory</param-name>
    <param-value>sample2.Sample2Factory</param-value>
  </context-param>
  <servlet>
    <servlet-name>download</servlet-name>
    <servlet-class>updown.DownloadServlet</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>download</servlet-name>
    <url-pattern>/download</url-pattern>
  </servlet-mapping>
  <jsp-config>
    <taglib>
      <taglib-uri>uji-taglib</taglib-uri>
      <taglib-location>/WEB-INF/ujiall.tld</taglib-location>
    </taglib>
  </jsp-config>
</web-app>

なお、Interstage Studioを使用している場合は、プロジェクトエクスプローラからプロジェクトを選択し、コンテキストメニューの[J2EEのdeployment descriptorの更新]を選択することでweb.xmlをServlet仕様バージョン2.4の形式に変換できます。

JDK/JRE5.0以降を使用する場合の例外の違い

JDK/JRE5.0で実施された修正の影響で、JDK/JRE1.4以前を使用していたアプリケーションをJDK/JRE5.0以降に移行した場合、以下のメソッドが発生する例外が変わる場合があります。

影響をおよぼすJDK/JRE5.0の修正内容は以下のとおりです。

ServletConnectionクラスのinvokeメソッドは内部でObjectInputStream.readObjectを呼び出しており、ObjectInputStream.readObjectが例外を発生した場合はその例外をそのまま発生させます。このため、JDK/JRE5.0の修正によりObjectInputStream.readObjectが発生する例外が変化するケースにおいては、invokeメソッドが発生する例外も同様に変化します。invokeの呼び出し元でStreamCorruptedExceptionとInvalidClassExceptionを区別して処理している場合、および、原因となる例外を参照している場合には修正が必要となります。この2つの例外を区別せず、その共通のスーパークラス(java.io.IOExceptionなど)として処理している場合で、かつ、原因となる例外を参照していない場合には影響はありません。

コンテントを持たないuji:caseタグの動作の違い

コンテントを持たないuji:caseタグを使用しているアプリケーションを Interstageで動作させる場合、V8.0以前のInterstageのサーブレット実行環境で動作させた場合と比べて、以下のとおり動作が変わる場合があります。

  1. V8.0以前のInterstageのサーブレット実行環境で動作させた場合

    コンテントを持つuji:caseタグがある場合、その内容がコンテントを持たないuji:caseタグによって出力されることがあります。

  2. V9.0以降のInterstageのサーブレット実行環境で動作させた場合

    コンテントを持たないuji:caseタグは何も出力しません。

上記1の動作を前提としているアプリケーションをInterstageのV9.0以降のサーブレット実行環境に移行する場合は、コンテントを持たないuji:caseタグを修正し、uji:caseタグで出力したい内容を明示的に記述してください。

なお、上記1の動作はApcoordinatorの障害であり、初期化パラメタuji.compatible.clearbodyにtrueを指定することで、サーブレット実行環境に依存せずに上記2の動作となります。“13.2 初期化パラメタ”の詳細は初期化パラメタを参照してください。

レンダラの動作の違い

画面部品タグの性能向上のため、INTERSTAGE WEBCOORDINATORとそれ以外の製品でレンダラの評価タイミングが異なります。

該当するのは、以下のいずれかの組み合わせでUJIタグを使用している場合です。

1-1. uji:tableタグを指定し、かつ、
1-2. uji:tableRendererタグのコンテントでUJIタグを使用し、かつ
1-3. コンテントで使用しているUJIタグでbeanアトリビュートを指定している場合

2-1. uji:treeタグを指定し、かつ、
2-2. uji:treeRendererタグのコンテントでUJIタグを使用し、かつ
2-3. コンテントで使用しているUJIタグでbeanアトリビュートを指定している場合

3-1. uji:listタグを指定し、かつ、
3-2. uji:listRendererタグのコンテントでUJIタグを使用し、かつ
3-3. コンテントで使用しているUJIタグでbeanアトリビュートを指定している場合

この場合、uji:tableRendererタグ、uji:treeRendererタグ、もしくはuji:listRendererタグのコンテントにあるUJIタグの評価タイミングに違いがあります。 INTERSTAGE WEBCOORDINATORの場合はレンダラの条件が評価され、条件が成立した場合にレンダラのコンテントのUJIタグが評価されます。

一方、Apcoordinatorの場合はレンダラのコンテントにUJIタグが出現した時点で評価されます。

上記条件に該当する場合、アプリケーションを次のいずれかの方法で修正してください。

初期化パラメタuji.servlet.defaultErrorPageを使用している場合の修正

初期化パラメタuji.servlet.defaultErrorPageは使用できません。

UjiServletを使用する場合において、例外発生時に表示するJSPを指定するには、初期化パラメタuji.servlet.errorPageを使用してください。uji.servlet.errorPageの詳細は“13.2 初期化パラメタ”を参照してください。

uji.servlet.defaultErrorPageを使用していたアプリケーションを、uji.servlet.errorPageを使用するように変更するには、アプリケーションを以下のとおり書き換えてください。

注意

  • web.xmlのみを書き換え、uji.servlet.defaultErrorPageで指定しているJSPを書き換えなかった場合、JSPの実行時に変数exceptionの値がnullになります。JSPで変数exceptionの値がnullとなることを想定していない場合は、JSPの実行時にNullPointerExceptionが発生します。

  • 上記1の対処を実施し、上記2の対処を実施しなかった場合は、uji.servlet.defaultErrorPageで指定しているJSPのコンパイル時にエラーとなります。

uif:iformタグを使用しているアプリケーションの運用

電子フォームアプリケーションは利用できません。

autoEscape機能によるフォーカス移動の動作の違い

autoEscape機能によるフォーカスの移動が、同一フォーム内に閉じて行われるように正しく修正しています。以下の条件の時、autoEscape機能によるフォーカスの移動順が修正となります。

  1. 同一のページ内に複数の uji:formタグを使用し、かつ、

  2. 各 uji:formタグのコンテントとして、autoEscape機能を有効とした、以下のいずれかのフィールドタグを使用している場合。

    • uji:fieldString

    • uji:fieldLong

    • uji:fieldDouble

    • uji:fieldBigInteger

    • uji:fieldBigDecimal

    • uji:fieldDate

autoEscape機能によるフォーカスの移動順について、以下に示すSample.jspを例に説明します。 uji:formタグ、uji:fieldStringのアトリビュートの記述は省略しています。

V9.0以前のフォーカスの移動順は、以下のとおりです。

フォーカスの移動順

フォーム1

入力フィールド 1_1と入力フィールド 1_2の間で移動します。

フォーム2

入力フィールド 2_1から入力フィールド 2_2へ移動後、入力フィールド 1_1へ移動します。
入力フィールド 1_1へ移動後は、入力フィールド 1_1と入力フィールド 1_2の間で移動します。

V9.1以降のフォーカスの移動順は、以下のとおりです。

フォーカスの移動順

フォーム1

入力フィールド 1_1と入力フィールド 1_2の間で移動します。

フォーム2

入力フィールド 2_1と入力フィールド 2_2の間で移動します。

HttpControlStateProfileクラスのdisposeメソッド実行後の新しいセションクラス作成タイミングの違い

Interstage Apcoordinator V5.0L20以降は、INTERSTAGE WEBCOORDINATOR V4.0L20、Interstage Apcoordinator V5.0L10と比べて、HttpControlStateProfileクラスのdisposeメソッド実行後の新しいセションクラスを作成するタイミングが異なります。

Struts連携機能を使用する場合のStrutsライブラリ

Struts連携機能を使用する場合は、オープンJavaフレームワーク機能で提供されるStruts 1.2を利用するか、StrutsのオープンソースコミュニティからStrutsライブラリを入手してください。

Flash連携機能

以前のバージョンのApcoordinatorで動作するアプリケーションは利用できません。

Windowクラスのopenメソッドを使用する場合の注意点

Windowクラスのopenメソッドで開いたウィンドウの親ウィンドウ(JavaScriptのwindow.openerで参照されるウィンドウ)の扱いが異なります。

次の図に、V11.0.0以降のウィンドウBの親ウィンドウの仕様を示します。

(1)ウィンドウAからのリクエストによりウィンドウBを開きます。ウィンドウBの親ウィンドウはウィンドウAです。

(2)ウィンドウCからのリクエストによりウィンドウBを開きます。このとき、ウィンドウBが開かれていると既存のウィンドウが利用されます。ウィンドウBの親ウィンドウはウィンドウCです。

親ウィンドウの扱いが異なるため、以下の条件をすべて満たすウィンドウは、サーバアプリケーションの修正が必要です。

・ウィンドウに紐づけられたJavaScriptがwindow.openerを参照している

・複数のウィンドウから開かれるウィンドウである

・サーバアプリケーションおよびJavaScriptが閉じることがないウィンドウである

上の条件の２番目および３番目に一致するウィンドウは別ウィンドウにより表示を更新されていることになります。別ウィンドウによる表示の更新は、「16.6 ウィンドウの制御」の「別のウィンドウの表示を更新する」を参照してください。

ポイント

  • 複数のウィンドウから開かれるウィンドウ

    該当するウィンドウ名を指定したWindowクラスのopenメソッドが、複数のクラスのメソッドで利用されている場合です。

  • サーバアプリケーションおよびJavaScriptが閉じることがないウィンドウである

    該当するウィンドウがWindowクラスのcloseメソッドで閉じられていない、および、該当のウィンドウがJavaScriptのcloseメソッドで閉じられていない場合です。

注意

親ウィンドウをWindowクラスのopenメソッドで別ウィンドウとして開いてはいけません。親ウィンドウの更新は、Windowクラスのupdateメソッドを利用してください。

前次
Copyright FUJITSU LIMITED 2019