--- schema_version: "1" id: 694ea1c179cc153276db50136ab00d1a979bcf6fd4d4af2e997f0ca87a12d9c1 title: クラスローディング分離について collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/mule-sdk/1.1/isolation.md canonical_url: https://docs.mulesoft.com/jp/mule-sdk/1.1/isolation source_site: docs.mulesoft.com content_type: documentation content_hash: 0177618ff17900def6471a5bfb7fef2762b8119488ceb0ed56f04bebba2eaa47 description: MuleSoft Documentation Site release: "1.1" latest: false --- # クラスローディング分離について Mule 4 のクラスローディングスキーマは、ランタイム、アプリケーション、モジュールを互いに分離します。それぞれは (クラスではなく) パッケージを指定し、API の一部としてエクスポートして、これらのパッケージを可視化します。 Mule 3 のクラスローディングの問題: - モジュールが互いに分離されなかった。 - モジュールが Mule Runtime から分離されなかった。 - モジュールが Mule アプリケーションから分離されなかった。 Mule 3 では、一部のライブラリを使用するモジュールが、同じライブラリの別のバージョンを使用する他のモジュール、アプリケーション、またはランタイムと競合することがありました。この競合によってクラスローディングの問題が発生し、​`ClassNotFoundException`​ や ​`NoSuchMethodException`​ など、トラブルシューティングの困難な混乱を招くエラーメッセージが表示されることがありました。 ## [](#モジュールのクラスローディング分離)モジュールのクラスローディング分離 クラスローディングは、クラスではなくパッケージによって自動的に絞り込まれるため、どのパッケージをエクスポートして Mule アプリケーションに対して可視化するかを、モジュールが指定する必要があります。 エクスポートするパッケージを判断するために、SDK は各設定、接続、コンポーネントの戻り値と入力種別を調べてそれらのパッケージを取得します。そのため、​_エクスポートしない_​クラスがエクスポートされるパッケージから除外されていることを確認する必要があります。エクスポートされるクラスは、エクスポートしないクラスとパッケージを共有していない必要があります。 次のパッケージ階層をお勧めします (MuleSoft モジュールで内部的に使用)。 org.mule.module \\--> .api.\* \\--> .internal.\* - `.api.*`​ には、Mule アプリケーションによってエクスポートされ表示されるすべてのクラス (戻り値のデータ型、サブタイプ、入力種別、接続インターフェース) が含まれる。 - `.internal.*`​ には、モジュールの特定の動作に使用されるすべてのクラス (アノテーション付きのクラス、​`Connection`​ および ​`Operation`​ 実装と内部クラス) が含まれる。 ### [](#エクスポートされたパッケージと戻り値のデータ型の把握)エクスポートされたパッケージと戻り値のデータ型の把握 MuleSoft では、エクスポートされた​​**すべての**​​クラスがモジュールに属することを推奨しています。 ライブラリの衝突により、モジュールと他のモジュール、アプリケーション連動関係、さらにはランタイムとの互換性がなくなるという問題を回避するため、以下が​_強く推奨_​されます。 - モジュールが使用しているライブラリに属するクラスからは​_絶対に_​​オブジェクトを戻したり受け取ったりしないこと。 次のセクションのシナリオを検討してください。 #### [](#1-つ目のシナリオ-同じパッケージをエクスポートする)1 つ目のシナリオ: 同じパッケージをエクスポートする このシナリオでは、操作が非常に異なる 2 つのモジュールを使用します。どちらも同じライブラリ (GSON) を使用して JSON を解析し、​`JsonObject`​ クラスのインスタンスを​_返します_​。片方は GSON バージョン ​`1.1`​、他方は GSON バージョン ​`2.3`​ を使用します。​`JsonObject`​ クラスは、両方のバージョンとして同じパッケージに含まれていますが、各バージョンの実装が異なるため、クラス間の互換性がなくなります。 この例では、​`JsonObject`​ クラスを操作の戻り値のデータ型として公開しています。 最初のモジュール操作 ```java public JsonObject getEmployee(@Connection EmployeesServiceConnection connection, String id) { return new JsonObject(connection.getById(id)); } ``` 2 番目のモジュール操作 ```java public JsonObject getAllProducts(@Connection ProductsServiceConnection connection) { return new JsonObject(connection.getProdsJson()); } ``` Mule アプリケーションをデプロイしてから、同じパッケージをエクスポートする 2 つのモジュールを使用しようとすると、2 つのモジュールが同じパッケージをエクスポートできないため、Mule はエラーとなります。 #### [](#2-つ目のシナリオ-同じクラスの異なるバージョンの-2-つのインスタンスを戻す)2 つ目のシナリオ: 同じクラスの異なるバージョンの 2 つのインスタンスを戻す 前述の例を少し変えて、操作が ​_GSON_​ パッケージをエクスポートしないものとします。その代わりに ​`java.lang.Object`​ を戻します。 最初のモジュール操作 ```java public Object getEmployee() { // Here JsonObject is from GSON 1.1 return new JsonObject(); } ``` 2 番目のモジュール操作 ```java public Object getAllProducts() { // Here JsonObject is from GSON 2.3 return new JsonObject(); } ``` アプリケーションで両方のモジュールを使用すると、両方のクラスの完全修飾名がまったく同じであるため、2 つのバージョンのうち片方だけが読み込まれます。完全修飾名の衝突によって、パッケージの​_読み込まれなかったほうの_​バージョンを必要とするモジュールは、異なる動作を起こして ​`ClassCastException`​ や ​`NoSuchMethodException`​ などのエラーが発生しやすくなります。 ### [](#export-アノテーション)@Export アノテーション SDK によって自動的にエクスポートされないクラスをモジュールがエクスポートする必要があるという、極めて厄介なケースや複雑なケースでは、​`@Export`​ アノテーションを使用できます。 `@Export`​ アノテーションは、エクスポートするクラスの配列を受け取ります。
同じパッケージのすべてのクラスをエクスポートクラスとしてエクスポートしない限り、特定のクラスだけをエクスポートすることはできません。