3

は、Liferayの6.0とは異なるパッケージに移動されました:クラスは、このように私たちのコードで使用されてとLiferayの6.1クラス<strong><a href="http://docs.liferay.com/portal/5.1/javadocs/util-java/com/liferay/util/servlet/ServletResponseUtil.java.html" rel="nofollow">ServletResponseUtil</a></strong> 6.1

//Liferay 6.0, 
// this class lives in util-java.jar in the default tomcat web app, /webapps/ROOT/lib. 
import com.liferay.util.servlet.ServletResponseUtil; 

//Liferay 6.1 
// class lives in portal-service.jar in directory tomcat-7.../lib/ext/ 
//import com.liferay.portal.kernel.servlet.ServletResponseUtil; 

String result = personComponentImpl.process(request); 
    response.setContentType("text/xml"); 

    try { 
     ServletResponseUtil.write(response, result); 
    } 
    catch (Exception e) { 
     if (_log.isWarnEnabled()) { 
      _log.warn(e, e); 
     } 
    } 

Liferay 6.0リリース用に作成されたポートレットを維持し、改善する必要があります。 6.1へのアップグレードを検討していますが、ポートレットの内部テスト中に、上記の依存関係が壊れているコードがいくつかあることがわかりました。実行時に6.1にClassNotFoundExceptionsがあります。

私のeclipseプロジェクトは、6.0を念頭に置いて設定されています。

私は今、何をすべき?:

  • ポートレット・コードの二つの異なる枝を維持します。これはなんとかですが、

  • が一つのコードベースではなく、別のビルド・パスを持つ2つの異なるEclipseプロジェクトを維持し、長期的にあまりにも多くの努力かもしれません(これは、実際に動作しない場合があります唯一の一般的な戦略である)

  • Javaコードに巧妙なハックを入れて、6.1用に簡単に作成する(多分工場で...これは漠然とした考えです)

  • 6.1のために+ Eclipseは6.0用にビルドされているが、

  • Re ServletResponseUtilクラスへの依存関係を完全に移動するには、ServletResponseUtilと同じことをする別のクラスを使用します。

  • ServletResponseUtilがはるかに350行よりも長く、非常に冗長でresponse.getOutputStream().write(data);のさえバギー実装ではありませんので、私は「同じことを別のクラスを使用する」を選ぶだろう、何か他のもの

答えて

2

を行います。

おそらく、あなたはちょっと "何か他のことをする"と組み合わせるべきでしょう。決しては、Liferay APIの安定性に依存しています。

+0

ここでは、クラスのソースをhttp://docs.liferay.com/portal/6.0/javadocs/src-html/com/liferay/util/servlet/ServletResponseUtil.htmlで調べています。古いインポートステートメント(上記参照)をカスタマイズしたServletResponseUtilになる自分自身のパッケージをインポートします。 – knb

関連する問題