開発者向けのクイック スタート ガイド

     前  次    目次     
ここから内容

開発者の生産性

この章では、開発者の生産性を向上するための次のヒントを説明します。

 


チーム プラグインの使用

チーム プラグイン

 


JRockit の使用

次のパラグラフに説明した基本的なポータル アプリケーションに対するテストに基づいて、反復的開発に関して JRockit JVM は Hotspot JVM より高速です。

サーバの起動、アプリケーションのデプロイ、10 回のアプリケーションの再デプロイのような一般的な開発者のタスクに基づいたシナリオを使用すると、JRockit は Linux マシンで 待機時間の数分を節約します。より遅いコンピュータを使う時、時間を節約することができます。

JRock の使用の詳細については、以下の URL を参照してください。

 


可能な場合のデバッグなしの実行

デバッグ サーバを実行すると、JRockit と Sun JVM の処理速度が低下されます。前の節で説明した開発者のシナリオにおいて、デバッグを実行すると、待機時間に数分が追加されます。

printlns を使用してコードを比較する場合、デバッグを使用すると、生産性にかかる時間を節約できます。ただし、デバッグを使用しない場合、デバッグせずにサーバを起動します。

詳細情報については、

 


十分なヒープがあることの確認

ポータルが大きくなるので、ヒープ (-Xmx) と初期 ヒープ サイズ (-Xms) を増加する必要があります。ヒープ サイズの初期値と最大値が同じであることが望ましい。

詳細については、以下を参照してください。

 


迅速な再デプロイ方法の選択

ポータル EAR のサイズによって、ポータル アプリケーションの再デプロイメントに時間がかかる。(かかる時間は使用されるマシンに依存します。)ただし、以下の方法を使用して、待機と再デプロイメントの低速化を防ぐためには、タスクを編成することができます。

一部のリソースを再デプロイする必要がない

JSP、.portal ファイルと同じのオブジェクトを再デプロイする必要はありません。たとえば、JSP を変更して Workshop for WebLogic において再パブリッシュした場合は、何も起こりません。ライト調査またはテストを行うには JSP のコードを使用します。

JSP 開発で Workshop for WebLogic を使用する場合の詳細については、「JSP の Oracle Workshop for WebLogic 」(Oracle Workshop for WebLogic ドキュメント) を参照してください。

エンクローズ EAR よりも高速な Web アプリケーションの再デプロイ

ポータル web アプリケーションを含む web アプリケーションの再デプロイメントは、全ての EAR のデプロイに比べてかなり高速です。

web アプリケーションを変更した場合、Workshop for WebLogic は変更した web アプリケーションのみを再パブリッシュします。したがって、web プロジェクトの Java Resources/src フォルダ内のクラスのように、web アプリケーションでコーディングを行うとより高速になります。web アプリケーションの WEB-INF/classes にデプロイされ、Workshop for WebLogic はサーバに WAR のみを再デプロイすることを通知します(アプリケーションを再デプロイをするには変更する必要がある)。

詳細については、「デプロイメントとテストの効率化」 (Oracle Workshop for WebLogic ドキュメント) を参照してください。

サーブ クラスローダでの EJB プロジェクトのデプロイは高速

最大のアプリケーションの再デプロイメントの時間がポータル EJB のようなリソースの処理をするため費やされるので、これらのリソースの再デプロイメントを回避して時間を節約することができます。たとえば、アプリケーション スコープの EJB のようなコードがある場合は、サブモジュールでコードをデプロイすることができます。ただし、クラスローダの配置が必要ですので、このメソッドの使用が限定されます。コンテンツ管理 SPI の実行、P13n EventListeners の登録 と UUP のようなアプリケーションは EJB プロジェクトでのコードを呼び出す場合、この技術を使用できません。

EJB プロジェクトは EAR のサブモジュールをするには、EARの weblogic-application.xml ファイルに classloader-structure スタンザを追加します。これは EAR を再デプロイせずに EJB と WAR プロジェクトの再デプロイすることを可能にします。

classloader-structure スタンザを EAR の weblogic-application.xml ファイルに追加するには、以下の手順を行います。

  1. EJB プロジェクトで説明した EJB プロジェクトを作成し、アプリケーション プロジェクトとその EJB プロジェクトを関連付けます。
  2. [プロジェクト] ビューでは、EAR の Weblogic デプロイメント記述子を開いて、[ソース] ビューを選択します。
  3. スタンザを追加するには module-uri 名を独自のプロジェクトに変更します。
  4. <wls:classloader-structure>
       <wls:classloader-structure>
          <wls:module-ref>
            <wls:module-uri>projectXejb.jar</wls:module-uri>
          </wls:module-ref>
          <wls:classloader-structure>
             <wls:module-ref>
                <wls:module-uri>projectX.war</wls:module-uri>
             </wls:module-ref>
          </wls:classloader-structure>
       </wls:classloader-structure>
    </wls:classloader-structure>

スタンザはEJB project (projectXejb) を EAR のサーブモジュールに変更しますので、WebLogic Server が全ての EAR を再デプロイしないで EJB JAR を再デプロイすることができます。WAR プロジェクト (projectX) が EJB の子プロジェクトですので、WAR が EJB プロジェクト内のコードをアクセスすることができます。

詳細については、以下を参照してください。


ページの先頭       前  次