現在表示中:

ここでは、AEM インストールの AEM 6.2 へのアップグレードについて説明します。

この手順に出てくる AEM インスタンスをわかりやすく区別するために、以下のように呼ぶことにします。

  • アップグレード元の CQ/AEM インスタンスを「ソース」インスタンスと呼びます。
  • アップグレード先のインスタンスを「ターゲット」インスタンスと呼びます。

注意:

アップグレードを実行したら、ContextHub 設定を復元する必要があります。

アップグレードのプランニング

AEM のアップグレードは広範にわたる作業です。デプロイメントの規模に応じて、アップグレードを確実に成功させるためのプランニングが必要になります。詳しくは、アップグレードの計画を参照してください。

JAR ベースインストールのアップグレード手順

注意:

準備手順を開始する前に、まず java -jar aem-quickstart.jar コマンドを使用して、ソースインスタンスを実行します。これは、quickstart.properties ファイルを正しく生成するために必要な手順です。このファイルがないと、アップグレードはうまくいきません。

あるいは、ソースインスタンスのインストールフォルダーの crx-quickstart/conf の下を探して、このファイルが存在するかどうかを確認します。

ソースインスタンスの準備

アップグレードプロセスはできる限り単純になるように設計されていますが、実稼動環境をアップグレードするのは容易なことではありません。したがって、アップグレードの準備には十分に時間をかけることを推奨します。具体的には、次のチェックリストの項目を実行してください。

  1. アップグレードしようとするインスタンスの完全バックアップを作成します。方法については、バックアップと復元を参照してください。

  2. アーカイブワークフローなどの不要なコンテンツをクリーンアップします。ワークフローの削除に関して詳しくは、ワークフローのパージを参照してください。

  3. ソースコンテンツリポジトリの整合性を確認し、不整合がある場合は修正します。これらの整合性チェックの実行方法については、以下の記事を参照してください。

    また、次の場所でデータストアの整合性チェックを実行することも推奨します。http://<serveraddress:serverport>/system/console/repositorycheck

  4. アップグレード中にアンインストールされる廃止されたバンドルの一覧を確認します。カスタムアプリケーションがこれらのバンドルのいずれかを利用している場合は、Adobe サポートに連絡し、影響を受ける領域の互換性パッケージを要求してください。

  5. インスタンス(カスタムアプリケーションを含む)を検証するテストスイートを実行します。インスタンスとテストスイートの検証後、アップグレードプロセスの後の段階で、アップグレードを検証する目的でこのテストスイートを再利用できます。

  6. /etc/map でのホスト名ベースのマッピング(およびその他の同様の設定)が、アップグレード後のインスタンスをテストする環境と互換性を持っていることを確認します。

  7. カスタム認証メカニズムをすべて無効にします。この方法については、カスタムログインモジュールの無効化を参照してください。

  8. カスタムアプリケーションのためにアップグレードのカスタマイズが必要になる場合は、その準備をします。

    注意:

    アセットコンテンツをカスタマイズした場合は、カスタマイズされているアセットのアップグレード準備を参照してください。

  9. インスタンスを停止します。

  10. アップグレード用にクリーンなログを取得するために、crx-quickstart/logs にあるログファイルをアーカイブした後、削除します。

カスタムログインモジュールの無効化

Apache Oak では、リポジトリレベルで認証をおこなうためのカスタムの LoginModule の設定方法が大きく変わっています。

CRX2 を使用していた旧バージョンの AEM では、repository.xml ファイルで設定をおこないましたが、AEM 6 以降では、Web コンソールを使用して、Apache Felix JAAS Configuration Factory サービスで設定をおこないます。

そのため、既存の設定を無効にして、アップグレード後、Apache Oak 用に再作成する必要があります。

repository.xml の JAAS 設定で定義したカスタムモジュールを無効にするには、次の例のようにデフォルトの LoginModule を利用するように設定を変更する必要があります。

<Security>
            ....
         <!--
                Use LoginModule authenticating against repository itself
                -->
                <LoginModule class="com.day.crx.core.CRXLoginModule">
                    <param name="anonymousId" value="anonymous"/>
                    <param name="adminId" value="admin"/>
                    <param name="disableNTLMAuth" value="true"/>
                    <param name="tokenExpiration" value="43200000"/>
                    <!-- param name="trust_credentials_attribute" value="d5b9167e95dad6e7d3b5d6fa8df48af8"/ -->
                </LoginModule>
        </Security>

注意:

詳しくは、外部ログインモジュールによる認証を参照してください。

AEM 6 での LoginModule 設定例については、AEM 6 での LDAP の設定を参照してください。

AEM Quickstart jar ファイルの準備

該当する AEM quickstart jar ファイルを入手し、ソースインスタンスの crx-quickstart フォルダーと同じ階層に配置します。

次に、Java 仮想マシン(JVM)とそのパラメーターが、この新しい quickstart jar に適しているかを確認します。要件やデプロイメントのタイプに応じて、旧バージョンの CQ または AEM で使用していたものとは異なるバージョンの JVM を実行したり、異なる JVM パラメーターを使用したりする必要があります。

コンテンツリポジトリの移行

注意:

ソースインスタンスが既に Oak を実行している場合は、以下の節をスキップして、AEM アップグレードの実行から続けてください。

AEM 6 の最新バージョンでは CRX2 がサポートされなくなるので、AEM 5.x または AEM 6.0 と CRX2 バックエンドインストールを使用している場合は、アップグレードの前にまずリポジトリを Apache Oak に移行する必要があります。

アドビは、リポジトリを新しい Oak 実装に移行するためのツールを提供しています。このツールは、quickstart パッケージに含まれています。

実際の移行は、標準の AEM 6.2 quickstart jar ファイルを使用しておこないます。この jar ファイルは、新しい -x crx2oak オプションを指定して実行します。このオプションによって crx2oak ツールが実行され、アップグレードがより容易に、堅牢になります。

移行の前に満たす必要のある前提条件がいくつかあります。

移行の前提条件

  • Java バージョンの最小要件:移行ツールは、Java バージョン 7 以降でのみ動作します。
  • アップグレード対象のインスタンス:アップグレード対象のインスタンスのバージョンが 5.4 よりも古い場合は、前述の手順を実行して、AEM 6.0 へのインプレースアップグレードを事前におこなってください。詳しくは、アップグレードに関するドキュメントの 6.0 バージョンを参照してください。

これらの条件を満たしたら、次の手順をこのとおりに実行します。

  1. 次のコマンドを実行して、quickstart jar を解凍します。

    java -jar aem-quickstart-6.2.0.jar -unpack
  2. 次のパラメーターを指定して quickstart を実行し、移行用の準備をおこないます。

    java -jar aem-quickstart-6.2.0.jar -v -x crx2oak

    この手順では、crx2oak-quickstart-extension.jar というヘルパーユーティリティが呼び出され、crx2oak.properties というファイルが crx-quickstart/crx2oak/ の下に生成されます。

    新しく生成されたファイルを確認し、移行要件のために異なる値を指定する必要がある場合は、ファイルのプロパティを編集します。

  3. ファイルの確認後、同じパラメーターを指定して jar ファイルをもう一度実行し、データ移行に必要な OSGi 設定を生成します。

    java -jar aem-quickstart-6.2.0.jar -v -x crx2oak

    File DataStore を使用する Windows デプロイメントでは、この時点で、path パラメーターがファイル区切り文字としてフォワードスラッシュ("/")を使用するように OSGi 設定を編集する必要があります。

    そのためには、crx-quickstart/install の下に生成されている org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.cfg ファイルを編集する必要があります。正しく書式設定されたパスは次のようになります。

    path=./crx-quickstart/repository/repository/datastore

    注意:

    ソースインスタンスで既に Amazon S3 Data Store を使用している場合や、このサービスを使用する必要がある場合は、移行操作の実行前に追加の手順を実行する必要があります。実行する必要のある手順について詳しくは、以下のページを参照してください。

  4. データを CRX2 から CRX3 に移行する移行操作を実行します。

    java -Xmx4096m -XX:MaxPermSize=2048M -jar aem-quickstart-6.2.0.jar -v -x crx2oak -xargs -- -o migrate

    注意:

    移行元のリポジトリのサイズに応じて JVM メモリオプションをチューニングするようにしてください。

    このコマンドは説明を出力します。移行中はこの説明を監視してください。

    移行が完了すると、crx2oak-quickstart-extension が実際のセットアップに応じて、新しい AEM インスタンスを起動してアップグレードを実行するために使用すべきストレージ関連の実行モードを指示します(例:Tar ベースストレージの場合は -r crx3,crx3tar、Mongo ストレージの場合は -r crx3,crx3mongo)。これはストレージ関連の実行モードだけであることに注意してください。一般に、新しいインスタンスには他の実行モードも指定する必要があります。

    また、crx2oak quickstart 拡張によって、Sling 実行モードを保管する sling.options.file の名前が変更される点に注意してください。この理由で、次回の起動時にカスタムの実行モードを再度指定する必要があります。

    crx2oak によって準備された OSGi 設定は crx-quickstart/install フォルダーに配置され、この設定が quickstart で使用されます。必要な場合には、新しい AEM インスタンスを起動する前にこの場所で OSGi 設定を変更できます。

    注意:

    移行に使用される crx2oak ツールの正確なバージョンを識別するには、quickstart に -x crx2oak オプションを付けて実行し、SHA1 チェックサムを出力してください。このチェックサムをサポートリクエストでお知らせいただくことで、使用している正確なバージョンを識別できます。

  5. AEM 5.6.1 または 6.0 と CRX2 バックエンドから移行する場合は、移行後に残る冗長なデータを削除して、repository フォルダーをクリーンアップする必要があります。

    そのためには、crx-quickstart/repository の下にあるものを、以下の特定のフォルダーを除きすべて削除します。

    • crx-quickstart/repository/index
    • crx-quickstart/repository/segmentstore
    • crx-quickstart/repository/repository/datastore

注意:

移行設定によって、バイナリデータを MongoDB などの外部データストアに移行するように設定している場合は、crx-quickstart/repository/repository/datastore フォルダーも削除して支障ありません。

AEM アップグレードの実行

この時点で、本番の AEM アップグレードを実行できます。アップグレードを実行するには、次の手順を実行する必要があります。

  1. AEM 6.2 quickstart jar を適切な実行モードで起動します。実行モードは、quickstart コマンドに -r オプションを追加することで指定します。

    使用できる実行モードは次のとおりです。

    • author または publish。インスタンスの目的を指定します。
    • ストレージ関連の実行モード。前述の crx2oak で指示されます。6.0 インスタンスからアップグレードしていて、コンテンツ移行を実行していない場合は、以前のインスタンスに対して使用したものと同じ実行モードを使用できます。使用できる実行モードは次のとおりです。
      • -r crx3,crx3tar(TarMK)
      • -r crx3,crx3mongo(MongoMK)
    • nosamplecontent 実行モード。インスタンスが本番向けのものである場合に、geometrixx デモアプリケーションなしで起動します。
    • 以前のインスタンスで使用していたか、新しいインスタンスで必要なその他のカスタム実行モード。

     

    警告:

    インスタンスの起動時には nosamplecontent に注意してください。この実行モードを省略すると、アップグレード前に geometrixx デモアプリケーションをインストールしていなかった場合でも、このデモアプリケーションがインストールされます。

    したがって、実稼動環境で実行される可能性がある起動スクリプトでは、必ずこの実行モードを使用するようにスクリプトを編集してください。

    一般的な quickstart 起動コマンドは次のようになります。

    java -jar aem-quickstart-6.2.0.jar -r author,crx3,crx3mongo,nosamplecontent -Doak.mongo.uri=mongodb://remoteserver:27017 -Doak.mongo.db=aem-author

    警告:

    crx-quickstart/conf/sling.properties ファイル内で sling.run.modes プロパティを設定して、実行モードを設定することもできます。このプロパティはコマンドラインオプションより優先されるので、両方を使用しないようにする必要があります。

    注意:

    アップグレードを実行するときは、必ず上記のように quickstart.jar を手動で実行してください。crx-quickstart\bin\ の下にあるいずれかの起動スクリプトを実行すると、アップグレードの代わりに新規インストールが呼び出されます。

    注意:

    このコマンドでは、MongoDB 永続性を指定して quickstart を起動しています。AEM では MongoDB 接続文字列を使用して、使用するデータベースの場所、ポートおよび名前を指定します。構文について詳しくは、接続文字列 URI 形式を参照してください。

  2. crx-quickstart/logsupgrade.logerror.log を確認し、アップグレードのプロセスを監視します。

  3. アップグレードが完了したら、AEM ホームページが表示されます。

    注意:

    アップグレード中は、http://<serveraddress:port>/system/console 以下への要求を除くすべての要求に対して HTTP 503 ステータスが返されます。

    OSGi コンソールは、AEM 6.2 起動フェーズの早い段階から /system/console で利用できます。このコンソールを使用して、監視やトラブルシューティングをおこなうことができます。

  4. アップグレードが完了したら、ソースインスタンスで使用したものと同じテストスイートを実行して、アップグレードを検証します。

    注意:

    リポジトリの install フォルダーのパッケージは、アップグレード後に再インストールされます。

    そのため、アップグレードの前に、インスタンスに対してこのフォルダー内のパッケージと重複する可能性のある変更はおこなわないようにしてください。

ヘルパー JAR の手動更新

ヘルパー JAR ファイルは必要に応じて、quickstart の解凍後に新しいバージョンと手動で置き換えることで、手動でアップグレードできます。AEM インストールフォルダー内のヘルパー JAR ファイルの場所は次のとおりです。

  • <aem-install>/crx-quickstart/opt/extensions/crx2oak-quickstart-extension.jar
  • <aem-install>/crx-quickstart/opt/helpers/crx2oak/crx2oak.jar

最新バージョンの CRX2Oak 移行ツールは、次の場所にある Adobe リポジトリからダウンロードして入手できます。

crx2oak-quickstart-extension.jar を実行すると、バージョンと SHA-1 チェックサムが表示されます。これらは、crx2oak.jar と同じ情報です。これらの JAR を手動でアップグレードしており、リポジトリ移行に関するバグを報告する場合は、使用したファイルのバージョンと SHA-1 チェックサムをサポートにお知らせください。

アプリケーションサーバーインストールのアップグレード手順

ここでは、アプリケーションサーバーインストール用の AEM を更新するために必要になる手順を説明します。

この手順では、どの例でも JBoss をアプリケーションサーバーとして使用し、有効な AEM のバージョンが既にデプロイされているものとします。ここでは、AEM バージョン 5.6 から 6.2 へのアップグレードについて説明します。

  1. 最初に、JBoss を起動します。ほとんどの状況で、standalone.sh 起動スクリプトを実行することで起動できます。そのためには、ターミナルから次のコマンドを実行します。

    jboss-install-folder/bin/standalone.sh

    注意:

    JBoss のタスクについて詳しくは、このドキュメントページを参照してください。

  2. AEM 5.6 が既にデプロイされている場合は、次のコマンドを実行してバンドルが正常に動作していることを確認します。

    wget http://<serveraddress:port>/cq/system/console/bundles
  3. 次に、AEM 5.6 のデプロイを解除します。

    rm jboss-install-folder/standalone/deployments/cq.war
  4. JBoss を停止します。

  5. 次に、crx2oak 移行ツールを使用してリポジトリを移行します。

    java -jar crx2oak.jar crx-quickstart/repository/ crx-quickstart/oak-repository

    注意:

    この例の oak-repository は、新しく変換されたリポジトリが配置される一時ディレクトリです。

    この手順を実行する前に、crx2oak.jar が最新バージョンであることを確認してください。

  6. 次の操作をおこなって、sling.properties ファイル内の必要なプロパティを削除します。

    1. crx-quickstart/launchpad/sling.properties ファイルを開きます。
    2. 次のプロパティを削除してファイルを保存します。
    sling.installer.dir
    felix.cm.dir
    granite.product.version
    org.osgi.framework.system.packages
    osgi-core-packages
    osgi-compendium-services
    jre-*
    sling.run.mode.install.options
  7. 不要なファイルとフォルダーを削除します。具体的に削除する必要のある項目は次のとおりです。

    • launchpad/startup フォルダー。ターミナルで次のコマンドを実行して削除できます。
    rm -rf crx-quickstart/launchpad/startup
    • base.jar ファイル:
    find crx-quickstart/launchpad -type f -name "org.apache.sling.launchpad.base.jar*" -exec rm -f {} \;

    BootstrapCommandFile_timestamp.txt ファイル:

    rm -f crx-quickstart/launchpad/felix/bundle0/BootstrapCommandFile_timestamp.txt
  8. 新しく移行された segmentstore を適切な場所にコピーします。

    mv crx-quickstart/oak-repository/segmentstore crx-quickstart/repository/segmentstore
  9. datastore もコピーします。

    mv crx-quickstart/repository/repository/datastore crx-quickstart/repository/datastore
  10. 次に、アップグレード後の新しいインスタンスで使用する OSGi 設定を格納するためのフォルダーを作成する必要があります。

    具体的には、install というフォルダーを crx-quickstart の下に作成する必要があります。

  11. 次に、AEM 6.2 で使用されるノードストアとデータストアを作成します。

    そのために、次の名前を持つ 2 つのファイルを crx-quickstart\install の下に作成します。

    • org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.cfg
    • org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.cfg

    これら 2 つのファイルにより AEM が TarMK ノードストアと File データストアを使用するように設定されます。

  12. 設定ファイルを編集し、使用できる状態にします。具体的には、次のように編集します。

    org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.config に次の行を追加します。

    customBlobStore=true

    org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config に次の行を追加します。

    path=./crx-quickstart/repository/datastore
    minRecordLength=4096
  13. 次のコマンドを実行して crx2 実行モードを削除します。

    find crx-quickstart/launchpad -type f -name "sling.options.file" -exec rm -rf {} \;
  14. 今度は、AEM 6.2 war ファイル内の実行モードを変更する必要があります。変更するには、まず AEM 6.2 war を格納する一時フォルダーを作成します。次の例のフォルダー名は、temp です。

    war ファイルをコピーしたら、temp フォルダー内で次のコマンドを実行して、内容を抽出します。

    jar xvf aem-quickstart-6.2.0.war
  15. 内容を抽出したら、WEB-INF フォルダーに移動して web.xml ファイルを編集し、実行モードを変更します。

    XML での実行モードの設定場所を探すには、sling.run.modes 文字列を検索します。見つかったら、コードの次の行で実行モードを変更します。デフォルトでは、author に設定されています。

    <param-value>author</param-value>

    この author という値を変更して、次の実行モードを設定します。

    author,crx3,crx3tar

    最終的なコードブロックは次のようになります。

    <init-param>
    <param-name>sling.run.modes</param-name>
    <param-value>author,crx3,crx3tar</param-value>
    </init-param>
    <load-on-startup>100</load-on-startup>
    </servlet>
  16. 編集後の内容で jar を再作成します。

    jar cvf aem62.war
  17. 最後に、新しい war ファイルをデプロイします。

    cp temp/aem62.war jboss-install-folder/standalone/deployments/aem61.war

アセットのアップグレード

カスタマイズされているアセットのアップグレード準備

カスタマイズされたアセットデプロイメントを含んでいるインスタンスを、アップグレード用に準備する必要があります。これは、カスタマイズされたすべてのコンテンツに 6.2 の新しいノード構造との互換性を持たせるために必要な作業です。

アセットコンテンツを準備するには、以下の手順を実行します。

  1. アップグレードする必要があるインスタンス上で、http://server:port/crx/de/index.jsp に移動して CRXDE Lite を開きます。

  2. 次のノードに移動します。

    • /apps/dam/content
  3. content ノードの名前を content_backup に変更します。ウィンドウ左側のエクスプローラーパネルを右クリックし、「名前を変更」を選択することによって、変更できます。

  4. ノードの名前を変更したら、content という名前の新しいノードを /apps/dam の下に作成し、ノードタイプを sling:Folder に設定します。

  5. content_backup のすべての子ノードを、新しく作成された content ノードに移動します。そのためには、エクスプローラーパネルで個々の子ノードを右クリックし、「移動」を選択します。

  6. content_backup ノードを削除します。

既存アセットのアセット ID を生成するには、AEM 6.2 を実行するように AEM インスタンスをアップグレードする際にアセットをアップグレードします。これは、アセットインサイト機能を有効にするために必要な手順です。詳しくは、埋め込みコードの追加を参照してください。

アセットをアップグレードするには、JMX コンソールで Associate Asset IDs パッケージを設定します。リポジトリ内のアセットの数によっては、migrateAllAssets に長い時間がかかることがあります(TarMK に 125k のアセットがある場合は、約 1 時間)。

アセット全体のサブセットに対してアセット ID が必要な場合は、migrateAssetsAtPath API を使用します。

その他すべての目的には、migrateAllAssets() API を使用してください。

AEM Communities のアップグレード

アップグレードするサイトがソーシャルコミュニティ機能を利用していた場合は、AEM Communities 6.2 へのアップグレードで追加のアップグレード情報を確認してください。

カスタム検索フォームのアップグレード

カスタム検索フォームを正しく機能させるには、アップグレード後に手動での変更が必要です。詳しくは、カスタム検索フォームのアップグレードを参照してください。

アップグレードによる問題の分析

ここでは、AEM 6.2 へのアップグレード手順で発生する可能性のある問題のシナリオを説明します。

これらのシナリオは、アップグレードに関連する問題の根本原因を追跡するのに役立ちます。また、プロジェクトや製品に固有の問題を識別するためにも役立ちます。

リポジトリ移行の失敗

CRX2 から Oak へのデータ移行は、CQ 5.4 ベースのソースインスタンスから始まるすべてのシナリオで実現可能です。repository.xml の準備を含むこのドキュメントのアップグレード手順に正確に従っていること、JAAS 経由でカスタム認証を起動していないこと、および移行を始める前にインスタンスに不整合がないかをチェックしていることを確認してください。

それでも移行が失敗する場合は、upgrade.log を調査することで、根本原因を解明できます。未知の問題の場合は、カスタマーサポートまで報告してください。

パッケージとバンドルを更新できない

アップグレード中にパッケージがインストールされなかった場合は、パッケージに含まれるバンドルも更新されません。

このような問題は、通常はデータストアの設定の誤りが原因です。また、この問題は、error.logERROR および WARN メッセージとして表示されます。

通常、この問題が起きているときはデフォルトのログインが動作しないので、直接 CRXDE を使用して設定の問題を調査、解明することになります。

一部の AEM バンドルがアクティブな状態に切り替わらない

バンドルが起動しない場合は、未解決の依存関係がないかを確認してください。

パッケージのインストールが失敗したせいでバンドルがアップグレードされず、その結果、新しいバージョンとの互換性がないと見なされ、この問題につながっている可能性もあります。このトラブルシューティングの方法について詳しくは、前述のパッケージとバンドルを更新できないを参照してください。

また、新規 AEM 6.2 インスタンスのバンドル一覧とアップグレード後のバンドル一覧を比較して、アップグレードされていないバンドルを検出することを推奨します。この比較によって、error.log で検索すべき問題を絞り込むことができます。

カスタムバンドルがアクティブな状態に切り替わらない

カスタムバンドルがアクティブな状態に切り替わらない場合は、変更後の API をインポートしていないコードが存在する可能性が疑われます。これは多くの場合、未解決の依存関係につながります。

削除された API は、以前のいずれかのリリースで廃止対象としてマークされているはずです。このような廃止の注記に、コードの直接的な移行に関する指示が含まれている場合があります。アドビはバージョン番号にできる限り意味を持たせるようにしており、バージョンが変わるときは互換性を破る変更がおこなわれている可能性があります。

また、問題の原因となった変更点が本当に必要であるかを確認し、不要なものであればその変更を元に戻すことをお勧めします。パッケージのエクスポートのバージョンが必要以上に増えていないかを確認し、厳密な意味のあるバージョン定義をおこなってください。

プラットフォーム UI の異常

アップグレード後に特定の UI 機能が正しく動作していない場合は、まずインターフェイスのカスタムオーバーレイを確認します。一部の構造が変更され、オーバーレイを更新する必要があるか、オーバーレイが古くなっている可能性があります。

次に、クライアントライブラリにフックされているカスタムの追加拡張にまで追跡可能な JavaScript エラーが発生していないかを確認します。AEM レイアウトの問題を引き起こしている可能性があるカスタム CSS についても、同様の確認をおこないます。

最後に、JavaScript では対処できない設定の誤りがないかを確認します。これは通常、不適切にアクティベート解除された拡張により発生する問題です。

カスタムコンポーネント、テンプレートまたは UI 拡張の異常

ほとんどの場合、これらの問題の根本原因は、起動されていないバンドルやインストールされていないパッケージによる問題と同じですが、異なる点は、問題が最初にコンポーネントを使用した時点で発生することです。

問題のあるカスタムコードへの対処方法としては、まず原因を特定するためのスモークテストを実行します。問題を特定したら、この記事にある推奨事項を参照して、問題の修正方法を確認します。

error.log と upgrade.log の分析

ほとんどの状況では、問題の原因を特定するために、ログにエラーがないかを確認する必要があります。ただし、アップグレードの場合は、古いバンドルが適切にアップグレードされていない場合があるので、依存関係の問題を監視する必要もあります。

そのための最適な方法は、現在発生している問題には関係がないと思われるメッセージをすべて削除して、error.log の情報を削ることです。次のように grep などのツールを使用して実行できます。

grep -v UnrelatedErrorString

即座に内容がわからないエラーメッセージもあります。その場合は、そのエラーメッセージが発生しているコンテキストを確認すると、エラーの発生場所の理解に役立ちます。以下のように使用してエラーを区別することができます。

  • grep -B(エラーの前の行を追加)

      または

  • grep -A(エラーの後の行を追加)

場合によっては、警告メッセージの中にエラーが見つかることもあります。妥当なケースが警告の状態につながることもあり、それが実際にエラーであるかどうかをアプリケーションが常に判断できるとは限りません。これらの警告メッセージについても確認してください。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー