カスタムコード品質ルール

AEM Engineering のベストプラクティスに基づいて、Cloud Manager がコード品質テストの一環として実行するカスタムコード品質ルールについて詳しく説明します。

メモ

ここで提供されるコードサンプルは、例としてのみ使用されています。概念と品質ルールについて詳しくは、SonarQube の概念に関するドキュメントを参照してください。

メモ

完全な SonarQube ルールは、アドビ独自の情報が原因でダウンロードできません。ルールの完全なリストをダウンロードするには、このリンクを使用します。ルールの説明と例については、このドキュメントを引き続き参照してください。

SonarQube ルール

以下の節では、Cloud Manager で実行される SonarQube ルールについて説明します。

問題が発生する可能性がある関数は使用しない

キー：CQRules:CWE-676
タイプ：脆弱性
深刻度：重大
最初の対象バージョン：バージョン 2018.4.0

Thread.stop() と Thread.interrupt() のメソッドは、再現が困難な問題を引き起こし、場合によってはセキュリティの脆弱性を生み出す可能性があります。その使用状況は、厳密に監視および検証する必要があります。一般的に、似た目標を達成するにはメッセージを渡すとより安全です。

準拠していないコード

public class DontDoThis implements Runnable {
  private Thread thread;

  public void start() {
    thread = new Thread(this);
    thread.start();
  }

  public void stop() {
    thread.stop();  // UNSAFE!
  }

  public void run() {
    while (true) {
        somethingWhichTakesAWhileToDo();
    }
  }
}

準拠しているコード

public class DoThis implements Runnable {
  private Thread thread;
  private boolean keepGoing = true;

  public void start() {
    thread = new Thread(this);
    thread.start();
  }

  public void stop() {
    keepGoing = false;
  }

  public void run() {
    while (this.keepGoing) {
        somethingWhichTakesAWhileToDo();
    }
  }
}

外部で制御できる可能性のある書式指定文字列を使用しない

キー：CQRules:CWE-134
タイプ：脆弱性
深刻度：重大
最初の対象バージョン：バージョン 2018.4.0

外部ソース（リクエストパラメーターやユーザー生成コンテンツなど）の書式指定文字列を使用すると、アプリケーションが DoS 攻撃にさらされる可能性があります。書式指定文字列は外部で制御できる場合がありますが、信頼できるソースからのみ許可されます。

準拠していないコード

protected void doPost(SlingHttpServletRequest request, SlingHttpServletResponse response) {
  String messageFormat = request.getParameter("messageFormat");
  request.getResource().getValueMap().put("some property", String.format(messageFormat, "some text"));
  response.sendStatus(HttpServletResponse.SC_OK);
}

HTTP 要求には常にソケットおよび接続タイムアウトが必要

キー：CQRules:ConnectionTimeoutMechanism
タイプ：バグ
深刻度：致命的
最初の対象バージョン：バージョン 2018.6.0

AEM アプリケーション内から HTTP 要求を実行する場合、不要なスレッドの使用を防ぐために、適切なタイムアウトが設定されていることを確認することが重要です。ただし、Java™ のデフォルト HTTP クライアント（java.net.HttpUrlConnection）および一般的に使用される Apache HTTP コンポーネントクライアントのデフォルトの動作はタイムアウトしないので、タイムアウトを明示的に設定する必要があります。また、ベストプラクティスとして、これらのタイムアウトは 60 秒以内に設定する必要があります。

準拠していないコード

@Reference
private HttpClientBuilderFactory httpClientBuilderFactory;

public void dontDoThis() {
  HttpClientBuilder builder = httpClientBuilderFactory.newBuilder();
  HttpClient httpClient = builder.build();

  // do something with the client
}

public void dontDoThisEither() {
  URL url = new URL("http://www.google.com");
  URLConnection urlConnection = url.openConnection();

  BufferedReader in = new BufferedReader(new InputStreamReader(
    urlConnection.getInputStream()));

  String inputLine;
  while ((inputLine = in.readLine()) != null) {
    logger.info(inputLine);
  }

  in.close();
}

準拠しているコード

@Reference
private HttpClientBuilderFactory httpClientBuilderFactory;

public void doThis() {
  HttpClientBuilder builder = httpClientBuilderFactory.newBuilder();
  RequestConfig requestConfig = RequestConfig.custom()
    .setConnectTimeout(5000)
    .setSocketTimeout(5000)
    .build();
  builder.setDefaultRequestConfig(requestConfig);

  HttpClient httpClient = builder.build();

  // do something with the client
}

public void orDoThis() {
  URL url = new URL("http://www.google.com");
  URLConnection urlConnection = url.openConnection();
  urlConnection.setConnectTimeout(5000);
  urlConnection.setReadTimeout(5000);

  BufferedReader in = new BufferedReader(new InputStreamReader(
    urlConnection.getInputStream()));

  String inputLine;
  while ((inputLine = in.readLine()) != null) {
    logger.info(inputLine);
  }

  in.close();
}

ResourceResolver オブジェクトは常に閉じる必要がある

キー：CQRules:CQBP-72
タイプ：コードスメル
深刻度：重大
最初の対象バージョン：バージョン 2018.4.0

ResourceResolverFactory から取得された ResourceResolver オブジェクトは、システムリソースを使用します。ResourceResolver が使用されなくなった場合に、これらのリソースを再利用する指標がありますが、close() メソッドを呼び出し、開いている ResourceResolver オブジェクトを明示的に閉じるほうが効率的です。

一般的な誤解として、既存の JCR セッションを使用して作成された ResourceResolver オブジェクトは明示的に閉じることはできず、そうすると基になる JCR セッションを閉じてしまうというものがあります。これは該当しません。どの方法で ResourceResolver を開いても、使用しなくなったら閉じる必要があります。ResourceResolver は閉じることのできる Closeable インターフェイスを実装するので、close() を明示的に呼び出す代わりに、try-with-resources 構文を使用することもできます。

準拠していないコード

public void dontDoThis(Session session) throws Exception {
  ResourceResolver resolver = factory.getResourceResolver(Collections.singletonMap("user.jcr.session", (Object)session));
  // do some stuff with the resolver
}

準拠しているコード

public void doThis(Session session) throws Exception {
  ResourceResolver resolver = null;
  try {
    resolver = factory.getResourceResolver(Collections.singletonMap("user.jcr.session", (Object)session));
    // do something with the resolver
  } finally {
    if (resolver != null) {
      resolver.close();
    }
  }
}

public void orDoThis(Session session) throws Exception {
  try (ResourceResolver resolver = factory.getResourceResolver(Collections.singletonMap("user.jcr.session", (Object) session))){
    // do something with the resolver
  }
}

サーブレットの登録に Sling サーブレットパスを使用しない

キー：CQRules:CQBP-75
タイプ：コードスメル
深刻度：重大
最初の対象バージョン：バージョン 2018.4.0

Sling ドキュメントで説明されているように、パスによってサーブレットをバインドすることは推奨されません。パスバインドサーブレットでは、標準 JCR アクセス制御を使用できないので、追加のセキュリティをより厳格にする必要があります。パスバインドサーブレットを使用する代わりに、リポジトリにノードを作成し、リソースタイプによってサーブレットを登録することをお勧めします。

準拠していないコード

@Component(property = {
  "sling.servlet.paths=/apps/myco/endpoint"
})
public class DontDoThis extends SlingAllMethodsServlet {
 // implementation
}

キャッチされた例外は、ログまたはスローする必要があるが、両方は行わない

キー：CQRules:CQBP-44—CatchAndEitherLogOrThrow
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2018.4.0

一般に、例外は 1 回だけログに記録する必要があります。複数回ログに記録すると、例外が発生した回数がわからなくなるので、混乱が生じる可能性があります。最も一般的なパターンは、キャッチされた例外をログに記録してスローすることです。

準拠していないコード

public void dontDoThis() throws Exception {
  try {
    someOperation();
  } catch (Exception e) {
    logger.error("something went wrong", e);
    throw e;
  }
}

準拠しているコード

public void doThis() {
  try {
    someOperation();
  } catch (Exception e) {
    logger.error("something went wrong", e);
  }
}

public void orDoThis() throws MyCustomException {
  try {
    someOperation();
  } catch (Exception e) {
    throw new MyCustomException(e);
  }
}

ログステートメントの直後にスローステートメントを使用しない

キー：CQRules:CQBP-44—ConsecutivelyLogAndThrow
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2018.4.0

もうひとつの避けるべき一般的なパターンは、メッセージをログに記録してからすぐに例外をスローすることです。これは一般に、ログファイルで例外メッセージが重複することを示します。

準拠していないコード

public void dontDoThis() throws Exception {
  logger.error("something went wrong");
  throw new RuntimeException("something went wrong");
}

準拠しているコード

public void doThis() throws Exception {
  throw new RuntimeException("something went wrong");
}

GET または HEAD 要求を処理する際は INFO でログに記録しない

キー：CQRules:CQBP-44—LogInfoInGetOrHeadRequests
タイプ：コードスメル
深刻度：軽度

一般的に、INFO ログレベルは重要なアクションを区切るために使用し、デフォルトでは、AEM は INFO レベル以上をログに記録するように設定されています。GET および HEAD メソッドは読み取り専用操作に過ぎず、重要なアクションを構成しません。GET または HEAD 要求に応答して INFO レベルでログに記録すると、大量のログノイズが作成されるので、ログファイル内の有用な情報を特定するのが難しくなります。GET または HEAD 要求処理時のログへの記録は、WARN または ERROR レベル（問題が発生した場合）、または、DEBUG または TRACE レベル（詳細なトラブルシューティング情報が役立つ可能性がある場合）で行います。

メモ

これは、各リクエストの access.log-type ログには適用されません。

準拠していないコード

public void doGet() throws Exception {
  logger.info("handling a request from the user");
}

準拠しているコード

public void doGet() throws Exception {
  logger.debug("handling a request from the user.");
}

Exception.getMessage() をログステートメントの最初のパラメーターとして使用しない

キー：CQRules:CQBP-44—ExceptionGetMessageIsFirstLogParam
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2018.4.0

ベストプラクティスとして、ログメッセージは、アプリケーション内での問題の発生場所に関するコンテキスト情報を提供する必要があります。また、スタックトレースを使用してコンテキストを判断することもできます。これにより、一般的にログメッセージが読みやすく、わかりやすくなります。その結果、例外をログに記録する際に、例外のメッセージをログメッセージとして使用するのは適切ではありません。例外メッセージには、何が起こったかが含まれますが、ログメッセージは、例外が発生したときにアプリケーションが何を実行していたかをログリーダーに伝えるために使用する必要があります。例外メッセージはログに記録されます。独自のメッセージを指定すると、ログがわかりやすくなります。

準拠していないコード

public void dontDoThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    logger.error(e.getMessage(), e);
  }
}

準拠しているコード

public void doThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    logger.error("Unable to do something", e);
  }
}

catch ブロックのログは、WARN または ERROR レベルにする必要がある

キー：CQRules:CQBP-44—WrongLogLevelInCatchBlock
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2018.4.0

名前が示すように、Java™ の例外は常に例外的な状況で使用する必要があります。結果として、例外が検出されたときには、ログメッセージが適切なレベル（WARN または ERROR）で記録されるようにすることが重要です。これにより、これらのメッセージがログに正しく表示されます。

準拠していないコード

public void dontDoThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    logger.debug(e.getMessage(), e);
  }
}

準拠しているコード

public void doThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    logger.error("Unable to do something", e);
  }
}

コンソールにスタックトレースを出力しない

キー：CQRules:CQBP-44—ExceptionPrintStackTrace
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2018.4.0

ログメッセージを理解する際にはコンテキストが重要です。Exception.printStackTrace() を使用すると、スタックトレースのみが標準エラーストリームに出力されるので、すべてのコンテキストが失われます。さらに、AEM などのマルチスレッドアプリケーションで、このメソッドを同時に使用して複数の例外がプリントされる場合、スタックトレースが重なって大きな混乱を招くことがあります。例外は、ログフレームワークによってのみ記録される必要があります。

準拠していないコード

public void dontDoThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    e.printStackTrace();
  }
}

準拠しているコード

public void doThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    logger.error("Unable to do something", e);
  }
}

標準出力または標準エラーに出力しない

キー：CQRules:CQBP-44—LogLevelConsolePrinters
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2018.4.0

AEM にログインする場合は、常にログフレームワーク（SLF4J）を使用してログインする必要があります。標準出力または標準エラーストリームに直接出力すると、ログフレームワークによって提供される構造およびコンテキスト情報が失われ、場合によってはパフォーマンスの問題が発生することがあります。

準拠していないコード

public void dontDoThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    System.err.println("Unable to do something");
  }
}

準拠しているコード

public void doThis() {
  try {
    someMethodThrowingAnException();
  } catch (Exception e) {
    logger.error("Unable to do something", e);
  }
}

/apps および /libs パスをハードコーディングしない

キー：CQRules:CQBP-71
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2018.4.0

一般に、/libs および /apps で始まるパスは、参照元としてハードコーディングせず、Sling 検索パス（デフォルトで /libs,/apps に設定されている）に対する相対パスで格納する必要があります。絶対パスを使用すると、プロジェクトライフサイクルの後になって初めて現れる、わかりにくい不具合が生じる可能性があります。

準拠していないコード

public boolean dontDoThis(Resource resource) {
  return resource.isResourceType("/libs/foundation/components/text");
}

準拠しているコード

public void doThis(Resource resource) {
  return resource.isResourceType("foundation/components/text");
}

Sling スケジューラーは使用しない

キー：CQRules:AMSCORE-554
タイプ：コードスメル／Cloud Service との互換性
深刻度：軽度
最初の対象バージョン：バージョン 2020.5.0

確実な実行を必要とするタスクには、 Sling スケジューラーを使用しないでください。Sling スケジュールジョブは実行を保証し、クラスター化環境と非クラスター化環境の両方に適しています。

Sling ジョブがクラスター環境で処理される方法について詳しくは、Apache Sling のイベントとジョブの取り扱いを参照してください。

AEM の非推奨 API は使用しない

キー：AMSCORE-553
タイプ：コードスメル／Cloud Service との互換性
深刻度：軽度
最初の対象バージョン：バージョン 2020.5.0

AEM API の表面は、使用が推奨されず非推奨と見なされる API を識別するために継続的に見直しされます。

多くの場合、これらの API は、標準の Java™ @Deprecated 注釈を使用して非推奨とされ、その結果、squid:CallToDeprecatedMethod によって識別されます。

ただし、API が AEM のコンテキストで非推奨となるものの、他のコンテキストでは非推奨とならない場合があります。このルールは、この 2 番目のクラスを識別します。

OakPAL コンテンツルール

以下の節では、Cloud Manager が実行する OakPAL チェックについて説明します。

メモ

OakPAL は、スタンドアロンの Oak リポジトリを使用してコンテンツパッケージを検証するフレームワークです。2019 AEM Rockstar North America 賞を受賞したAEM Partner が開発しました。

@ProviderType の注釈が付いた Product API は、お客様による実装または拡張はできない

キー：CQBP-84
タイプ：バグ
深刻度：致命的
最初の対象バージョン：バージョン 2018.7.0

AEM API には、カスタムコードで使用するけれど実装できない Java™ インターフェイスとクラスが含まれています。例えば、インターフェイス com.day.cq.wcm.api.Page は、AEM によってのみ実装されます。

これらのインターフェイスに新しいメソッドが追加される場合、それらの追加メソッドは、これらのインターフェイスを使用する既存のコードには影響しません。その結果、これらのインターフェイスへの新しいメソッドの追加は、後方互換性があると見なされます。ただし、カスタムコードがこれらのインターフェイスのいずれかを実装する場合、そのカスタムコードによってお客様に後方互換性のリスクがもたらされます。

AEM によってのみ実装されることを意図されたインターフェイスおよびクラスは、org.osgi.annotation.versioning.ProviderType（場合によっては、従来の類似の注釈の aQute.bnd.annotation.ProviderType）で注釈が付けられます。このルールは、カスタムコードによってこのようなインターフェイスが実装されている（またはクラスが拡張されている）場合を特定します。

準拠していないコード

import com.day.cq.wcm.api.Page;

public class DontDoThis implements Page {
// implementation here
}

顧客パッケージでは /libs 下のノードを作成／変更しない

キー：BannedPath
タイプ：バグ
重大度：ブロッカー
最初の対象バージョン：バージョン 2019.6.0

AEM コンテンツリポジトリ内の /libs コンテンツツリーを読み取り専用と見なすことは長年のベストプラクティスとなっています。/libs 下のノードやプロパティを変更すると、メジャーアップデートおよびマイナーアップデートの際に重大な問題が発生する可能性があります。/libs への変更は、アドビの公式チャネルを通じてのみ行います。

パッケージには重複する OSGi 設定を含めない

キー：DuplicateOsgiConfigurations
タイプ：バグ
深刻度：重大
最初の対象バージョン：バージョン 2019.6.0

複雑なプロジェクトでよく発生する問題は、同じ OSGi コンポーネントが複数回設定されることです。これにより、どの設定が操作可能かがあいまいになります。このルールは「実行モード対応」です。つまり、同じコンポーネントが同じ実行モード（または実行モードの組み合わせ）で複数回設定されている問題のみを特定します。

準拠していないコード

+ apps
  + projectA
    + config
      + com.day.cq.commons.impl.ExternalizerImpl
  + projectB
    + config
      + com.day.cq.commons.impl.ExternalizerImpl

準拠しているコード

+ apps
  + shared-config
    + config
      + com.day.cq.commons.impl.ExternalizerImpl

/config および /install フォルダーには OSGi ノードのみ含める

キー：ConfigAndInstallShouldOnlyContainOsgiNodes
タイプ：バグ
深刻度：重大
最初の対象バージョン：バージョン 2019.6.0

セキュリティ上の理由から、/config/ と /install/ を含むパスを判読できるのは AEM の管理者ユーザーのみで、これらは OSGi 設定と OSGi バンドルにのみ使用する必要があります。これらのセグメントを含むパスの下に他のタイプのコンテンツを配置すると、アプリケーションの動作が管理者ユーザーと非管理者ユーザーとで意図せず異なることになります。

よくある問題としては、コンポーネントダイアログ内や、インライン編集にリッチテキストエディター設定を指定する際に、config というノードを使用するケースがあります。これを解決するには、問題のノードを準拠した名前に変更する必要があります。リッチテキストエディター設定については、cq:inplaceEditing ノードの configPath プロパティを使用して新しい場所を指定します。

準拠していないコード

+ cq:editConfig [cq:EditConfig]
  + cq:inplaceEditing [cq:InplaceEditConfig]
    + config [nt:unstructured]
      + rtePlugins [nt:unstructured]

準拠しているコード

+ cq:editConfig [cq:EditConfig]
  + cq:inplaceEditing [cq:InplaceEditConfig]
    ./configPath = inplaceEditingConfig (String)
    + inplaceEditingConfig [nt:unstructured]
      + rtePlugins [nt:unstructured]

パッケージは重複しない

キー：PackageOverlaps
タイプ：バグ
深刻度：重大
最初の対象バージョン：バージョン 2019.6.0

パッケージには重複する OSGi 設定を含めないと同様に、これも複雑なプロジェクトでよく発生する問題です。複数の異なるコンテンツパッケージに同じノードパスが書き込まれるケースです。コンテンツパッケージの依存関係を使用すると、一貫性のある結果を得ることができますが、その際には、パッケージがまったく重複しないようにすることをお勧めします。

デフォルトのオーサリングモードをクラシック UI にしない

キー：ClassicUIAuthoringMode
タイプ：コードスメル／Cloud Service との互換性
深刻度：軽度
最初の対象バージョン：バージョン 2020.5.0

OSGi 設定 com.day.cq.wcm.core.impl.AuthoringUIModeServiceImpl は、AEM 内でデフォルトのオーサリングモードを定義します。AEM 6.4 以降、クラシック UI は非推奨となったので、デフォルトのオーサリングモードがクラシック UI に設定されている場合、問題が発生するようになりました。

タッチ UI ダイアログが必要なダイアログを持つコンポーネント

キー：ComponentWithOnlyClassicUIDialog
タイプ：コードスメル／Cloud Service との互換性
深刻度：軽度
最初の対象バージョン：バージョン 2020.5.0

最適なオーサリングエクスペリエンスを提供し、クラシック UI がサポートされない Cloud Service デプロイメントモデルとの互換性を維持するために、クラシック UI ダイアログを含む AEM コンポーネントには、常にタッチ UI ダイアログが必要です。このルールは、次のシナリオを検証します。

クラシック UI ダイアログ（dialog 子ノード）を持つコンポーネントには、対応するタッチ UI ダイアログ（cq:dialog 子ノード）が必要です。
クラシック UI デザインダイアログ（design_dialog ノード）を使用しているコンポーネントには、対応するタッチ UI デザインダイアログ（cq:design_dialog 子ノード）が必要です。
クラシック UI ダイアログとクラシック UI デザインダイアログの両方を持つコンポーネントには、対応するタッチ UI ダイアログと対応するタッチ UI デザインダイアログの両方が必要です。

AEM 最新化ツールのドキュメントには、コンポーネントをクラシック UI からタッチ UI に変換する方法に関する詳細とツールが記載されています。詳しくは、AEM 最新化ツールのドキュメントを参照してください。

リバースレプリケーションエージェントは使用しない

キー：ReverseReplication
タイプ：コードスメル／Cloud Service との互換性
深刻度：軽度
最初の対象バージョン：バージョン 2020.5.0

リバースレプリケーションのサポートは、リリースノート：レプリケーションエージェントの削除で説明しているように、Cloud Service のデプロイでは利用できません。

リバースレプリケーションを使用するお客様は、アドビに問い合わせて、代替ソリューションをご利用ください。

プロキシ対応のクライアントライブラリに含まれるリソースは resources という名前のフォルダーに格納する

キー：ClientlibProxyResource
タイプ：バグ
深刻度：軽度
最初の対象バージョン：バージョン 2021.2.0

AEM クライアントライブラリには、画像やフォントなどの静的なリソースが含まれる場合があります。クライアント側ライブラリの使用のドキュメントで説明しているように、プロキシ化されたクライアントライブラリを使用する場合、パブリッシュインスタンスで効果的に参照するために、これらの静的リソースを resources という名前の子フォルダーに格納する必要があります。

準拠していないコード

+ apps
  + projectA
    + clientlib
      - allowProxy=true
      + images
        + myimage.jpg

準拠しているコード

+ apps
  + projectA
    + clientlib
      - allowProxy=true
      + resources
        + myimage.jpg

Cloud Service と互換性のないワークフロープロセスの使用

キー：CloudServiceIncompatibleWorkflowProcess
タイプ：コードスメル
重大度：ブロッカー
最初の対象バージョン：バージョン 2021.2.0

AEM Cloud Service 上でアセット処理を行うために Assets マイクロサービスに移行すると、AEM のオンプレミスバージョンと AMS バージョンで使用されていたワークフロープロセスが、サポートされなくなる、または不要になります。

AEM Assets as a Cloud Service GitHub リポジトリの移行ツールを使用すると、AEM as a Cloud Service への移行中にワークフローモデルを更新できます。

静的なテンプレートより編集可能なテンプレートを使用する

キー：StaticTemplateUsage
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2021.2.0

従来、AEM プロジェクトでは静的テンプレートを使用するのが一般的でしたが、最も柔軟性が高く、静的なテンプレートにはない追加機能をサポートしている編集可能なテンプレートを強くお勧めします。詳しくは、ページテンプレート - 編集可能なドキュメントを参照してください。

静的なテンプレートから編集可能なテンプレートへの移行は、AEM 最新化ツールを使用して、ほとんど自動化することができます。

従来の基盤コンポーネントの使用は推奨されない

キー：LegacyFoundationComponentUsage
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2021.2.0

一部の AEM リリースでは、従来の基盤コンポーネント（/libs/foundation 下のコンポーネントなど）は廃止され、コアコンポーネントに置き換わりました。使用する方法がオーバーレイであろうと継承であろうと、従来の基盤コンポーネントに基づいてカスタムコンポーネントを作成することは、お勧めしません。対応するコアコンポーネントに移行してください。

この変換は、AEM 最新化ツールで容易に行うことができます。

カスタム検索インデックス定義ノードは、/oak:index の直接の子にする必要がある

キー：OakIndexLocation
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2021.2.0

AEM Cloud Service では、カスタム検索インデックス定義（ノードのタイプが oak:QueryIndexDefinition など）が /oak:index の直接の子ノードである必要があります。AEM Cloud Service と互換性を持たせるため、他の場所にあるインデックスは移動する必要があります。検索インデックスの詳細については、コンテンツ検索とインデックス作成のドキュメントを参照してください。

カスタム検索インデックス定義ノードの compatVersion は 2 にする

キー：IndexCompatVersion
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2021.2.0

AEM Cloud Service では、カスタム検索インデックス定義（oak:QueryIndexDefinition タイプのノード）の compatVersion プロパティを 2 に設定する必要があります。その他の値は、AEM Cloud Service ではサポートされていません。検索インデックスの詳細については、コンテンツ検索とインデックス作成のドキュメントを参照してください。

カスタム検索インデックス定義ノードの子孫ノードのタイプは、nt:unstructured にする

キー：IndexDescendantNodeType
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2021.2.0

カスタム検索インデックス定義ノードに順序なしの子ノードがある場合、トラブルシューティングしにくい問題が発生するおそれがあります。これを避けるために、oak:QueryIndexDefinition ノードのすべての子孫ノードは、タイプを nt:unstructured にすることをお勧めします。

カスタム検索インデックス定義ノードには、子を持つ indexRules という名前の子ノードを含める

キー：IndexRulesNode
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2021.2.0

適切に定義されたカスタム検索インデックス定義ノードには、indexRules という名前の子ノードが含まれている必要があり、今度は、この子ノードに少なくとも 1 つの子が必要です。詳しくは、Oak ドキュメントを参照してください。

カスタム検索インデックス定義ノードは命名規則に従う

キー：IndexName
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2021.2.0

AEM Cloud Service では、コンテンツの検索とインデックス作成で説明されている特定のパターンに従ってカスタム検索インデックス定義（oak:QueryIndexDefinition タイプのノード）に名前を付ける必要があります。

カスタム検索インデックス定義ノードでは lucene 型のインデックスを使用する

キー：IndexType
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2021.2.0

AEM Cloud Service では、カスタム検索インデックス定義（oak:QueryIndexDefinition タイプのノード）に、値が lucene に設定された type プロパティが必要です。AEM Cloud Service に移行する前に、従来のインデックスタイプを使用したインデックス作成を更新する必要があります。詳しくは、コンテンツの検索とインデックス作成のドキュメントを参照してください。

カスタム検索インデックス定義ノードに seed という名前のプロパティを含めない

キー：IndexSeedProperty
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2021.2.0

AEM Cloud Service では、カスタム検索インデックス定義（ノードのタイプが oak:QueryIndexDefinition）に seed という名前のプロパティを含めることが禁止されています。AEM Cloud Service に移行する前に、このプロパティを使用しているインデックスを更新する必要があります。詳しくは、コンテンツの検索とインデックス作成のドキュメントを参照してください。

カスタム検索インデックス定義ノードに reindex という名前のプロパティを含めない

キー：IndexReindexProperty
タイプ：コードスメル
深刻度：軽度
最初の対象バージョン：バージョン 2021.2.0

AEM Cloud Service では、カスタム検索インデックス定義（ノードのタイプが oak:QueryIndexDefinition）に reindex という名前のプロパティを含めることが禁止されています。AEM Cloud Service に移行する前に、このプロパティを使用しているインデックスを更新する必要があります。詳しくは、コンテンツの検索とインデックス作成のドキュメントを参照してください。

Dispatcher 最適化ツール

以下の節では、Cloud Manager で実行される Dispatcher 最適化ツール（DOT）チェックを示します。各チェックの GitHub 定義と詳細については、リンクを参照してください。

カスタムコード品質ルール

SonarQube ルール

問題が発生する可能性がある関数は使用しない

準拠していないコード

準拠しているコード

外部で制御できる可能性のある書式指定文字列を使用しない

準拠していないコード

HTTP 要求には常にソケットおよび接続タイムアウトが必要

準拠していないコード

準拠しているコード

ResourceResolver オブジェクトは常に閉じる必要がある

準拠していないコード

準拠しているコード

サーブレットの登録に Sling サーブレットパスを使用しない

準拠していないコード

キャッチされた例外は、ログまたはスローする必要があるが、両方は行わない

準拠していないコード

準拠しているコード

ログステートメントの直後にスローステートメントを使用しない

準拠していないコード

準拠しているコード

GET または HEAD 要求を処理する際は INFO でログに記録しない

準拠していないコード

準拠しているコード

Exception.getMessage() をログステートメントの最初のパラメーターとして使用しない

準拠していないコード

準拠しているコード

catch ブロックのログは、WARN または ERROR レベルにする必要がある

準拠していないコード

準拠しているコード

コンソールにスタックトレースを出力しない

準拠していないコード

準拠しているコード

標準出力または標準エラーに出力しない

準拠していないコード

準拠しているコード

/apps および /libs パスをハードコーディングしない

準拠していないコード

準拠しているコード

Sling スケジューラーは使用しない

AEM の非推奨 API は使用しない

OakPAL コンテンツルール

@ProviderType の注釈が付いた Product API は、お客様による実装または拡張はできない

準拠していないコード

顧客パッケージでは /libs 下のノードを作成／変更しない

パッケージには重複する OSGi 設定を含めない

準拠していないコード

準拠しているコード

/config および /install フォルダーには OSGi ノードのみ含める

準拠していないコード

準拠しているコード

パッケージは重複しない

デフォルトのオーサリングモードをクラシック UI にしない

タッチ UI ダイアログが必要なダイアログを持つコンポーネント

リバースレプリケーションエージェントは使用しない

プロキシ対応のクライアントライブラリに含まれるリソースは resources という名前のフォルダーに格納する

準拠していないコード

準拠しているコード

Cloud Service と互換性のないワークフロープロセスの使用

静的なテンプレートより編集可能なテンプレートを使用する

従来の基盤コンポーネントの使用は推奨されない

カスタム検索インデックス定義ノードは、/oak:index の直接の子にする必要がある

カスタム検索インデックス定義ノードの compatVersion は 2 にする

カスタム検索インデックス定義ノードの子孫ノードのタイプは、nt:unstructured にする

カスタム検索インデックス定義ノードには、子を持つ indexRules という名前の子ノードを含める

カスタム検索インデックス定義ノードは命名規則に従う

カスタム検索インデックス定義ノードでは lucene 型のインデックスを使用する

カスタム検索インデックス定義ノードに seed という名前のプロパティを含めない

カスタム検索インデックス定義ノードに reindex という名前のプロパティを含めない

Dispatcher 最適化ツール

Business.Adobe.com リソース

このページ

次を表示：

学習

ドキュメント

コミュニティ

サポート

リソース

アドビアカウント

Adobe