コンテンツパッケージがデプロイ時にエラーを発生する

パッケージをデプロイするには、管理者権限が必要です。エラーが発生した場合は、Adobe Experience Manager ログファイルを参照してください。パッケージ展開中にエラーが発生する理由は、Adobe Experience Manager に依存しない項目があるからです。もう 1 つは、すでにインストールされているパッケージよりも古いバージョンをインストールしようとしている可能性があるからです。 

次の Adobe Experience Manager のトピックに必ず目を通してください:パッケージの使用方法

OSGi バンドルを含むパッケージの構築方法においては OSGi バンドルを含む Adobe CQ アプリケーションのパッケージ化を参照してください。

サーバーの再起動によってエラーが発生する理由

Adobe Experience Manager サーバーが起動していない場合は、最初の手順はサーバーログを確認することです。error.log、stderr.log、stdout.log(すべてのログファイルが「CQX.X/crx-quickstart/logs」フォルダーに存在します)を確認します。1 つの問題は、システムがメモリ不足の場合です。

その他の理由は以下の通りです。

  • JVM パラメーターが無効です(error.log には何も表示されません)
  • ブラウザーでシステムにアクセスできない(実行中のインスタンスによってポートがまだ要求されていないか、または正常にシャットダウンされなかったハング中の JVM)
  • 典型的な理由:ブラウザーに認証のサポートが表示されない、これは開始されないリポジトリ(error.log)によって発生します。

トラブルシューティング情報についてはこの記事を参照してください。トラブルシューティング CQ WCM

Adobe Experience Manager をインストールする前に、必ずテクニカル要件を満たしていることを確認してください。技術要件を参照してください。

Felix コンソールがロードされません

felix コンソールにアクセスができず、エラー「org.apache.sling.servlets.resolver.internal.SlingServletResolver Original error null」が発生した場合は、次の手順を実行します。

  1. cd /crx-quickstart/launchpad/felix
  2. grep -H "org.apache.felix.webconsole" .-R
  3. org.apache.felix.webconsole-.jar を検索します。
  4. そのバンドル「cd」に移動します。
  5. bundle.location ファイルをチェックしてください、それには slinginstall:org.apache.felix.webconsole-.jar が含まれているはずです。
  6. bundle.state ファイルを開き、状態を「インストール済み」から「アクティブ」に変更します。
  7. システムを再起動します。

注意:

launchpad を使用する代わりに、gogo を使用できます。詳しくは、以下を参照してください。

https://helpx.adobe.com/jp/experience-manager/kb/cq-5-5--rien-ne-va-plus---i-need-a-text-shell.html

Package Manager がロードしません

Adobe Experience Package Manager などの読み込みに失敗した場合は、(例えば、ファイルを開く際に 404 エラーが発生するなど)最初の手順として、ログを確認することをお勧めします。必要な JCR ノードが正しいことを確認します。これらのノードが存在しない場合は、ログファイルにエラーが表示されます。例:

log: 27.06.2014 13:16:53.845 *ERROR* [127.0.0.1 [1402543013788] GET /crx/packmgr/list.jsp?_dc=1402543013769&_charset_=utf-8&includeVersions=true HTTP/1.1] com.day.crx.packmgr.impl.servlets.ListServlet Error while retrieving infos: javax.jcr.RepositoryException: Invalid path:/etc/packages/my_packages/.snapshot/My Packagename

詳細については、このコミュニティの記事を参照してください:AEM Gotchya:Package Manager にパッケージがありません

ようこそ画面においてパッケージリンクにマウスポインターを合わせたときに表示される URL を確認します。これは、http://localhost:4502/crx/packmgr/または http://localhost:4502/crx/packmgr.html を示していますか?リンクに .html が表示されている場合、このような動作を起こす可能性のある etc/map 下でルールを設定している場合があります。

最後に、「/libs/cq/core/content/welcome/features/packages」の権限を確認してください。Adobe Experience ユーザーが Package Manager にアクセスするために必要な権限レベルがすべてあることを確認します。管理者以外のアカウントでは、パッケージをインストールするために必要なアクセス許可が必要です。

カスタムコンポーネントが期待通りに機能していません

Adobe Experience Manager 開発者が作成したカスタムコンポーネントは、、フロントエンド JavaScript ロジックとバックエンド Java ロジック(通常、OSGi バンドル内にパッケージされています)で構成することが可能です。カスタムコンポーネントを開発する場合は、コンポーネントをデバッグして、期待どおりに機能していることを確認することをお勧めします。コンポーネントをデバッグするには、ブレークポイントを設定し、アプリケーションロジックをステップ実行します。 

デバッグ方法は、構築方法によって異なります。次のリンクを参照してください。

Eclipse を使用して、CQ5/AEM6 アプリケーションのデバッグ

CQ 6 - AEM Adobe Experience JSP IntelliJ のアイデア 12 のデバッグ

AEM のスケーラビリティに関する問題

このセクションでは、AEM スケーラビリティ問題について説明します。 

インスタンスが要求に応答しないのはなぜですか。

パフォーマンスの低下している、または CPU 使用率が高くなっている時間にを少なくとも数分間 http://localhost:4502/system/console/profiler を使用します。出力は、どの JVM スレッドが最も多く CPU サイクル、そしてその関連パッケージおよびクラスを使用しているかの決定に役立ちます。

次のような 2 つの手順があります。

  • CPU 使用率をチェックします。
  • セッション数をチェックします。
  • プロセスを強制終了しません。

詳細については、パーフォマンスが遅くなり、ブロックされた処理の分析を参照してください。

非常に低速なオーサーインスタンスがあるのはなぜですか?

AEM のパフォーマンスの問題に影響する要因は次のとおりです。

  • 不適切なデザイン
  • アプリケーションコード
  • ディスク I / O 設定が正しくありません
  • ネットワーク帯域幅と待ち時間
  • AEM が、メモリ管理に問題がある一部の Windows 2008 あるいは 2012 バージョンにインストールされています

詳細については、パフォーマンスチューニングのヒント | 6.x.

低速パフォーマンスの遅延スレッドダンプの確認方法は?

JVM からのスレッドダンプを取得するには、いくつかの方法があります。1 つ以上のスレッドダンプを取得することを強くお勧めします。規則的な間隔で 10 スレッドダンプを取得することをお勧めします(例えば、10秒ごとに 1 つのスレッドダンプをします)。

詳細については、JVM からスレッドダンプを取得する方法参照してください。

インスタンスのヒープ領域が不足している理由

このような問題は、以下の原因が考えられます。

考えられる原因として、java アプリケーション(この場合、CRX / CQ)が、Java のデフォルトのヒープメモリ設定を使用したコマンドラインから開始されたためと考えられます。JVM パラメーター - が指定されていないことを意味しています。CRX または CQ には、少なくとも256 MB のヒープが割り当てられている必要があります。この問題が発生した場合は、コマンドラインから始めて、ヒープメモリ設定が設定されていることを確認してください。

詳細については、解析メモリの問題を参照してください。

CRX プロファイラーを実行する方法、またパフォーマンスが低下したときにそれをする必要がありますか?

prof.jsp を使用
簡易 CPU プロファイリングツールは CRX 2.x. に付属しています。(CRX 2.0 - 2.2)を開始するには、以下のリンクを開きます。

http://localhost:7402/crx/diagnostic/prof.jsp
CRX 2.3/CQ 5.5 は次の場所にあります。

http://localhost:4502/crx/explorer/diagnostic/prof.jsp

を選択し、

http://localhost:4502/system/console/profiler

詳細については、ビルトインプロファイラーによるパフォーマンスの解析を参照してください。

エラーが発生する理由:zip ファイルのアップロード中に無効なファイルが表示されます。

使用事例で ZIP ファイルをアップロードする必要がある場合、AEM はこれをサポートしています。つまり、AEM アセットユーザーインターフェイスを使用して、ZIP ファイルを AEM DAM にアップロードできます。ZIP ファイルをアップロードすると、次の図に示すように、そのファイルを閲覧できます。 

 

zipic

エラーが発生した場合は、http://localhost:4502/damadmin#/content/dam にある AEM アセットのユーザーインターフェイスを使用して、ZIP をアップロードしていることを確認します。

別のオプションとして、AEM DAM にファイルをアップロードできるコンポーネントを書き込むこともできます。https://helpx.adobe.com/jp/experience-manager/using/uploading-files-aem1.html を参照してください。 

ホットフィックスのインストールに失敗する理由/ホットフィックスパッケージのインストールにエラーが発生する理由(ホットフィックスの失敗)

AEM ホットフィックスのインストールの際に問題が生じた場合、次の AEM KB の記事を参照してください。Adobe Experience Manager 6.0 ホットフィックス.まだ問題が解決しない場合は、サポートチケットを開きます:https://helpx.adobe.com/jp/marketing-cloud/experience-manager.html

 

パッケージのインストール後にコンテンツノードがないのはなぜですか?

AEM パッケージをインストールした後、/content にコンテンツが存在しない場合は、パッケージが正常に作成されなかったことを意味します。通常、パッケージを作成すると、/content 内のパッケージの一部である JCR ノードを選択します。パッケージを作成したチームに問い合わせます。AEM パッケージを構築する方法について詳しくは、Adobe Experience Manager 6 アプリケーションのパッケージ化を参照してください。

AEM の管理に関する問題

このセクションでは、以下に AEM の管理に関する問題について説明します。

クラスター環境において、マスター(オーサー)またはスレーブ(オーサー)にログインあるいは認証ができない理由?

次のポイントがログインできない理由の場合があります。

  1. インスタンスが非同期の状態であるかどうかを確認します。
  2. 非同期の状態の場合、同期のトラブルシューティングに従ってください。
  3. ユーザー名とパスワードが正しいことを確認します。
  4. LDAP サーバーが応答して正常に動作していることを確認します。
  5. エントリのログをチェックします。

なぜ、「コンテンツパスを解決するのに失敗しました」と呼ばれるエラーが発生するのでしょうか?

OSGi パッケージ、http://mvnrepository.com/artifact/org.apache.sling/org.apache.sling.jcr.jackrabbit.accessmanager/2.1.0 を CQ インスタンスにインストールし、それが役立つかどうか確認します。

Felix コンソールでバンドル状態が更新/変更されない理由

バンドルを更新しても、新しいクラスがすぐに使用されるとは限りません。次の 2 つの要因に依存します。

  1. クラスがプライベートパッケージまたはエクスポート済みのパッケージに由来する場合
    クラスが書き出し済みのパッケージより由来される場合、それらが別のバンドルによって使用されているかどうかです。
    (1) について、クラスがプライベートパッケージに由来する場合、(つまり、書き出されていないパッケージです)、すぐに使用可能になります。ただし、それらが書き出し済みのパッケージに由来する場合、他のバンドルが書き出し済みのパッケージを使用しているかどうかによって表示内容が異なります。
  2. 他のバンドルが、書き出し済みパッケージを使用していない場合、新しいクラスは、古いバージョンのクラスが不要になるため、すぐ使用可能になります。一方、書き出し済みのパッケージを他のバンドルが使用している場合、古いバージョンが依存バンドルによって必要とされるため、新しいクラスはすぐに使用できません。この場合、新しいクラスは、PackageAdmin.refreshPackages () が呼び出されるまで使用できません(これは、更新コマンドを使用して Felix Shell で呼び出すことができます)。

後者の場合には一部の例外があります、それは書き出しバンドルが独自の書き出し済みのパッケージをインポートしない場合に発生します。(「バンドルは独自の書き出し済みのパッケージをインポートすべきですか?」を参照してください)詳しくは、この commonic を参照してください)。この場合、新しいクラスは、更新された書き出しバンドルにすぐにアクセスできるようになりますが、依存バンドルにはアクセスできません。依存バンドルは、以前のバージョンのクラスを引き続き参照します。このような状況では、PackageAdmin.refreshPackages () を呼び出し、バンドルを有効な状態に戻す必要があります。

OSGi 仕様によって定義された通りの通常の更新プロセスです。バンドルの更新は 2 つのプロセスからなります。書き出されたパッケージの古いバージョンは、明示的に更新されるまで保持されます。これは、いくつかの更新を実行する際の不都合を減らすために行なわれます。

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

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