↗️ 🤱🏿 🗣️ 時間がないことよりも良い時間：JIRA APIをその場で拡張する 📴 🧒🏽 👨🏾‍💻

問題を解決するためにアプリケーションで使用可能なAPIが十分ではなく、コードをすぐに変更する可能性がない場合、どうすればよいですか？

この状況での最後の希望は、 java.lang.instrumentパッケージの使用です。既に実行中のVMでコードを使用してJavaで何をどのように行うことができるかに興味がある人は、catにようこそ。

Habrには、すでにバイトコードの処理に関する記事があります。

ただし、これらのテクノロジーの使用は、原則として、ロギングまたはその他の単純な機能に限定されます。しかし、計装を使用してアプリケーションの機能を拡張するために詐欺をしようとしたらどうでしょうか？

この記事では、アプリケーションに新しい機能を追加するために、Javaエージェントアプリケーション（ OSGiとByte Buddyライブラリの両方）を計測する方法を示します。この記事は主にJIRAで作業する人々にとって興味深いものですが、使用されるアプローチは非常に普遍的であり、他のプラットフォームに適用できます。

挑戦する

したがって、JIRA APIを2、3日調査した後、タスクの作成/変更時にフィールド値の相互検証を実装するのが普通であることを理解しています（1つのフィールドの有効な値が別のフィールドの値に依存する場合）。アプローチは機能していますが、難しくて便利ではないので、空き時間に計画Bを得るために研究を続けることにしました。

最近のジョーカーは、バイトバディライブラリに関するラファエルウィンターハルターの講演を特集しました。これは、より便利な高レベルシェルで強力な低レベルバイトコード編集APIをラップします。このライブラリは現在非常に人気があり、特に最近ではMockitoとHibernateで使用されています。とりわけ、Rafaelは既にロードされたクラスのByte Buddyで変更する可能性について話しました。

「これは思考だ！」と思い、仕事を始めます。

設計

まず、Rafaelのレポートから、すでにロードされているクラスの変更は、javaエージェントの起動時に使用できるjava.lang.instrument.Instrumentationインターフェイスを使用することでのみ可能であることを思い出してください。 VMの起動時にコマンドラインを使用するか、JDKに付属するプラットフォーム依存のAttach APIを使用してインストールできます。

ここには重要な詳細があります-エージェントは削除できません-そのクラスはVMが終了するまでロードされたままです。

attach APIのサポートに関してJIRAに関しては、ここではJDK上で実行されることを保証できません。さらに、JIRAが実行されるOSを保証することはできません。
次に、JIRA機能を拡張するためのメインユニットはアドオン -ステロイドのバンドルであることを思い出します。つまり、すべてのロジックは、それが何であれ、アドオンとして設計する必要があります。これは、システムに変更を加える場合、べき等で切断可能でなければならないという要件を意味します。

これらの制限を考えると、グローバルに2つのタスクがあります。

エージェントのインストール：アドオンのインストール中に実行し、二重インストールに対する保護を提供し、LinuxおよびWindows、JDKおよびJREでのエージェントのインストールをサポートする必要があります。
なぜならエージェントを削除することはできません。その更新にはアプリケーションの再起動が必要です-これはOSGiの概念に適合しません。したがって、エージェントの責任を最小限に抑えて、その更新の必要性ができる限り発生しないようにする必要があります。
インストルメンテーションの実装：アドオンのインストール中に発生する必要があり、クラスの変換のべき等性を確認し、検証ロジックの拡張性を確認する必要があります。

コンポーネント間で責任を分散させると、次のスキームが得られました。

実装

エージェント

まず、エージェントを作成します。

public class InstrumentationSupplierAgent { public static volatile Instrumentation instrumentation; public static void agentmain(String args, Instrumentation inst) throws Exception { System.out.println("==**agent started**=="); InstrumentationSupplierAgent.instrumentation = inst; System.out.println("==**agent execution complete**=="); } }

コードは簡単で、説明は必要ないと思います。合意されたように-最も一般的なロジックは、頻繁に更新する必要があることはほとんどありません。

プロバイダー

次に、このエージェントがターゲットVMに接続するアドオンを作成します。エージェントのインストールロジックから始めましょう。スポイラーの下の完全なインストーラーコード：

AgentInstaller.java

 @Component public class AgentInstaller { private static final Logger log = LoggerFactory.getLogger(AgentInstaller.class); private final JiraHome jiraHome; private final JiraProperties jiraProperties; @Autowired public AgentInstaller( @ComponentImport JiraHome jiraHome, @ComponentImport JiraProperties jiraProperties ) { this.jiraHome = jiraHome; this.jiraProperties = jiraProperties; } private static File getInstrumentationDirectory(JiraHome jiraHome) throws IOException { final File dataDirectory = jiraHome.getDataDirectory(); final File instrFolder = new File(dataDirectory, "instrumentation"); if (!instrFolder.exists()) { Files.createDirectory(instrFolder.toPath()); } return instrFolder; } private static File loadFileFromCurrentJar(File destination, String fileName) throws IOException { try (InputStream resourceAsStream = AgentInstaller.class.getResourceAsStream("/lib/" + fileName)) { final File existingFile = new File(destination, fileName); if (!existingFile.exists() || !isCheckSumEqual(new FileInputStream(existingFile), resourceAsStream)) { Files.deleteIfExists(existingFile.toPath()); existingFile.createNewFile(); try (OutputStream os = new FileOutputStream(existingFile)) { IOUtils.copy(resourceAsStream, os); } } return existingFile; } } private static boolean isCheckSumEqual(InputStream existingFileStream, InputStream newFileStream) { try (InputStream oldIs = existingFileStream; InputStream newIs = newFileStream) { return Arrays.equals(getMDFiveDigest(oldIs), getMDFiveDigest(newIs)); } catch (NoSuchAlgorithmException | IOException e) { log.error("Error to compare checksum for streams {},{}", existingFileStream, newFileStream); return false; } } private static byte[] getMDFiveDigest(InputStream is) throws IOException, NoSuchAlgorithmException { final MessageDigest md = MessageDigest.getInstance("MD5"); md.digest(IOUtils.toByteArray(is)); return md.digest(); } public void install() throws PluginException { try { log.trace("Trying to install tools and agent"); if (!isProperAgentLoaded()) { log.info("Instrumentation agent is not installed yet or has wrong version"); final String pid = getPid(); log.debug("Current VM PID={}", pid); final URLClassLoader systemClassLoader = (URLClassLoader) ClassLoader.getSystemClassLoader(); log.debug("System classLoader={}", systemClassLoader); final Class<?> virtualMachine = getVirtualMachineClass( systemClassLoader, "com.sun.tools.attach.VirtualMachine", true ); log.debug("VM class={}", virtualMachine); Method attach = virtualMachine.getMethod("attach", String.class); Method loadAgent = virtualMachine.getMethod("loadAgent", String.class); Method detach = virtualMachine.getMethod("detach"); Object vm = null; try { log.trace("Attaching to VM with PID={}", pid); vm = attach.invoke(null, pid); final File agentFile = getAgentFile(); log.debug("Agent file: {}", agentFile); loadAgent.invoke(vm, agentFile.getAbsolutePath()); } finally { tryToDetach(vm, detach); } } else { log.info("Instrumentation agent is already installed"); } } catch (Exception e) { throw new IllegalPluginStateException("Failed to load: agent and tools are not installed properly", e); } } private boolean isProperAgentLoaded() { try { ClassLoader.getSystemClassLoader().loadClass(InstrumentationProvider.INSTRUMENTATION_CLASS_NAME); return true; } catch (Exception e) { return false; } } private void tryToDetach(Object vm, Method detach) { try { if (vm != null) { log.trace("Detaching from VM: {}", vm); detach.invoke(vm); } else { log.warn("Failed to detach, vm is null"); } } catch (Exception e) { log.warn("Failed to detach", e); } } private String getPid() { String nameOfRunningVM = ManagementFactory.getRuntimeMXBean().getName(); return nameOfRunningVM.split("@", 2)[0]; } private Class<?> getVirtualMachineClass(URLClassLoader systemClassLoader, String className, boolean tryLoadTools) throws Exception { log.trace("Trying to get VM class, loadingTools={}", tryLoadTools); try { return systemClassLoader.loadClass(className); } catch (ClassNotFoundException e) { if (tryLoadTools) { final OS os = getRunningOs(); os.tryToLoadTools(systemClassLoader, jiraHome); return getVirtualMachineClass(systemClassLoader, className, false); } else { throw new ReflectiveOperationException("Failed to load VM class", e); } } } private OS getRunningOs() { final String osName = jiraProperties.getSanitisedProperties().get("os.name"); log.debug("OS name: {}", osName); if (Pattern.compile(".*[Ll]inux.*").matcher(osName).matches()) { return OS.LINUX; } else if (Pattern.compile(".*[Ww]indows.*").matcher(osName).matches()) { return OS.WINDOWS; } else { throw new IllegalStateException("Unknown OS running"); } } private File getAgentFile() throws IOException { final File agent = loadFileFromCurrentJar(getInstrumentationDirectory(jiraHome), "instrumentation-agent.jar"); agent.deleteOnExit(); return agent; } private enum OS { WINDOWS { @Override protected String getToolsFilename() { return "tools-windows.jar"; } @Override protected String getAttachLibFilename() { return "attach.dll"; } }, LINUX { @Override protected String getToolsFilename() { return "tools-linux.jar"; } @Override protected String getAttachLibFilename() { return "libattach.so"; } }; public void tryToLoadTools(URLClassLoader systemClassLoader, JiraHome jiraHome) throws Exception { log.trace("Trying to load tools"); final File instrumentationDirectory = getInstrumentationDirectory(jiraHome); appendLibPath(instrumentationDirectory.getAbsolutePath()); loadFileFromCurrentJar(instrumentationDirectory, getAttachLibFilename()); resetCache(); final File tools = loadFileFromCurrentJar(instrumentationDirectory, getToolsFilename()); final Method method = URLClassLoader.class.getDeclaredMethod("addURL", URL.class); method.setAccessible(true); method.invoke(systemClassLoader, tools.toURI().toURL()); } private void resetCache() throws NoSuchFieldException, IllegalAccessException { Field fieldSysPath = ClassLoader.class.getDeclaredField("sys_paths"); fieldSysPath.setAccessible(true); fieldSysPath.set(null, null); } private void appendLibPath(String instrumentationDirectory) { if (System.getProperty("java.library.path") != null) { System.setProperty("java.library.path", System.getProperty("java.library.path") + System.getProperty("path.separator") + instrumentationDirectory); } else { System.setProperty("java.library.path", instrumentationDirectory); } } protected abstract String getToolsFilename(); protected abstract String getAttachLibFilename(); } }

コードを部分的に分析しましょう。

最も単純なシナリオは、エージェントがすでにロードされている場合です。起動時にコマンドラインオプションを使用してオンにしたか、アドオンが初めてインストールされていない可能性があります。

チェック-簡単、システムクラスローダーでエージェントクラスをロードするだけ

 private boolean isProperAgentLoaded() { try { ClassLoader.getSystemClassLoader().loadClass(InstrumentationProvider.INSTRUMENTATION_CLASS_NAME); return true; } catch (Exception e) { return false; } }

使用可能な場合、これ以上インストールする必要はありません。しかし、最初のインストールがあり、エージェントがまだ読み込まれていないとしましょう-attach APIを使用して自分でそれを行います。前のケースと同様に、まずJDKで作業しているかどうかを確認します。目的のAPIは、追加の操作を行うかどうかに関係なく利用できます。そうでない場合は、APIを「配信」してみてください。

 private Class<?> getVirtualMachineClass(URLClassLoader systemClassLoader, String className, boolean tryLoadTools) throws Exception { log.trace("Trying to get VM class, loadingTools={}", tryLoadTools); try { return systemClassLoader.loadClass(className); } catch (ClassNotFoundException e) { if (tryLoadTools) { final OS os = getRunningOs(); os.tryToLoadTools(systemClassLoader, jiraHome); return getVirtualMachineClass(systemClassLoader, className, false); } else { throw new ReflectiveOperationException("Failed to load VM class", e); } } }

次に、接続APIのインストール手順を検討します。 JREをJDKに「変換」するタスクは、コンテナOSの定義から始まります。 JIRAでは、OS定義コードは既に実装されています。

 private OS getRunningOs() { final String osName = jiraProperties.getSanitisedProperties().get("os.name"); log.debug("OS name: {}", osName); if (Pattern.compile(".*[Ll]inux.*").matcher(osName).matches()) { return OS.LINUX; } else if (Pattern.compile(".*[Ww]indows.*").matcher(osName).matches()) { return OS.WINDOWS; } else { throw new IllegalStateException("Unknown OS running"); } }

ここで、どのOSで実行されているかがわかったら、アタッチAPIをアタッチする方法を検討してください。最初に、アタッチAPIが実際に構成するものを見てください。私が言ったように、それはプラットフォームに依存しています。

注：tools.jarはプラットフォームに依存しないものとしてリストされていますが、これは完全に真実ではありません。 META-INF / services /では、構成ファイルcom.sun.tools.attach.spi.AttachProviderが非表示になり、環境で利用可能なプロバイダーがリストされます。

＃[solaris] sun.tools.attach.SolarisAttachProvider
＃[windows] sun.tools.attach.WindowsAttachProvider
＃[linux] sun.tools.attach.LinuxAttachProvider
＃[macosx] sun.tools.attach.BsdAttachProvider
＃[aix] sun.tools.attach.AixAttachProvider

これらは、プラットフォームに非常に依存しています。

当面、必要なファイルをアセンブリに接続するために、対応するJDKディストリビューションからライブラリファイルとtools.jarのコピーを抽出して、リポジトリに配置することにしました。
重要なのは、アタッチAPIファイルを読み込んだ後は削除または変更できないため、アドオンを削除および更新できるようにする場合は、jarからライブラリを直接読み込む必要はないことです。それらをjarファイルからJIRAからアクセス可能な静かで落ち着いた場所にコピーします。

 public void tryToLoadTools(URLClassLoader systemClassLoader, JiraHome jiraHome) throws Exception { log.trace("Trying to load tools"); final File instrumentationDirectory = getInstrumentationDirectory(jiraHome);//{JIRA_HOME}/data/instrumentation loadFileFromCurrentJar(instrumentationDirectory, getAttachLibFilename());//    final File tools = loadFileFromCurrentJar(instrumentationDirectory, getToolsFilename());// tools.jar ... }

ファイルをコピーするには、次の方法を使用します。

 private static File loadFileFromCurrentJar(File destination, String fileName) throws IOException { try (InputStream resourceAsStream = AgentInstaller.class.getResourceAsStream("/lib/" + fileName)) { final File existingFile = new File(destination, fileName); if (!existingFile.exists() || !isCheckSumEqual(new FileInputStream(existingFile), resourceAsStream)) { Files.deleteIfExists(existingFile.toPath());//    -   existingFile.createNewFile(); try (OutputStream os = new FileOutputStream(existingFile)) { IOUtils.copy(resourceAsStream, os); } } return existingFile; } }

通常のファイル操作に加えて、このコードはチェックサム計算を実行します。コードの記述時に、ランタイムで更新不可能なコンポーネントを検証するこの方法が最初に思い浮かびました。原則として、アーティファクトをバージョン管理する場合、バージョンチェックを実行することもできます。ファイルがすでにロードされているが、チェックサムがアーカイブからのアーティファクトと一致しない場合、それらを置き換えようとします。

だから、ファイルがあります、ダウンロードする方法を理解しましょう。最も難しいことから始めましょう-ネイティブライブラリをロードします。 attach APIの腸を調べると、タスクを実行すると、次のコードを使用してライブラリがアンロードされることが直接わかります。

 static { System.loadLibrary("attach"); }

これは、ライブラリの場所を「java.library.path」に追加する必要があることを示唆しています

 private void appendLibPath(String instrumentationDirectory) { if (System.getProperty("java.library.path") != null) { System.setProperty("java.library.path", System.getProperty("java.library.path") + System.getProperty("path.separator") + instrumentationDirectory); } else { System.setProperty("java.library.path", instrumentationDirectory); } }

その後、目的のネイティブライブラリファイルを正しいディレクトリに追加し、最初の松葉杖をソリューションに追加します。「Java.library.path」は、ClassLoaderクラスのプライベート静的文字列sys_paths []にキャッシュされます。さて、プライベートには何が必要ですか-キャッシュをリセットしましょう...

 private void resetCache() throws NoSuchFieldException, IllegalAccessException { Field fieldSysPath = ClassLoader.class.getDeclaredField("sys_paths"); fieldSysPath.setAccessible(true); fieldSysPath.set(null, null); }

ここでは、ネイティブ部分をダウンロードしました-JavaのAPIの部分に渡します。 JDKのtools.jarは、システムローダーによってロードされます。同じことをする必要があります。

少し良くなったので、システムローダーがjava.net.URLClassLoaderを実装していることがわかります。
要するに、このローダーはクラスの場所をURLのリストとして保存します。ダウンロードする必要があるのは、このリストにtools- [OS] .jarのURLを追加することだけです。 URLClassLoader APIを研究した後、再び悲しくなりました。必要なことを正確に行うaddURLメソッドが保護されていることがわかります。ええと...細長いプロトタイプへのもう一つのバックアップ：

 final Method method = URLClassLoader.class.getDeclaredMethod("addURL", URL.class); method.setAccessible(true); method.invoke(systemClassLoader, tools.toURI().toURL());

さて、最後に、すべてが仮想マシンクラスをロードする準備ができました。

現在のOSGiクラスローダーではなく、システムに常にダウンロードする必要があります。接続中に、このクラスローダーはネイティブライブラリをロードします。これは一度しか実行できません。 OSGiクラスローダーは、バンドルをインストールするときに作成されます（新しいバンドルを作成するたびに）。そのため、この種のものを取得するリスクがあります。

…19その他
原因：com.sun.tools.attach.AttachNotSupportedException：プロバイダーがインストールされていません
com.sun.tools.attach.VirtualMachine.attach（VirtualMachine.java:203）で

説明は明らかではありませんが、本当の理由は、既にロードされているライブラリをロードしようとしていることです。これについては、attachメソッドを販売して実際の例外を確認することによってのみ知ることができます。

クラスをロードしたら、必要なメソッドをロードして、最終的にエージェントをアタッチできます。

 Method attach = virtualMachine.getMethod("attach", String.class); Method loadAgent = virtualMachine.getMethod("loadAgent", String.class); Method detach = virtualMachine.getMethod("detach"); Object vm = null; try { final String pid = getPid(); log.debug("Current VM PID={}", pid); log.trace("Attaching to VM with PID={}", pid); vm = attach.invoke(null, pid); final File agentFile = getAgentFile(); log.debug("Agent file: {}", agentFile); loadAgent.invoke(vm, agentFile.getAbsolutePath()); } finally { tryToDetach(vm, detach); }

ここでの唯一の微妙な点は、仮想マシンのPIDです。

  private String getPid() { String nameOfRunningVM = ManagementFactory.getRuntimeMXBean().getName(); return nameOfRunningVM.split("@", 2)[0]; }

このメソッドは非標準ですが、非常に機能します。Java9 Process API全般では、問題なくこれを行うことができます。

アドオン

次に、このロジックをアドオンに埋め込みます。アドオンのインストール中にコードを呼び出す機能に興味があります-これは、標準のスプリングInitializingBeanを使用して行われます。

  @Override public void afterPropertiesSet() throws Exception { this.agentInstaller.install(); this.serviceTracker.open(); }

まず、エージェントインストールロジック（上記で説明）を呼び出し、次にServiceTrackerを開きます。これは、OSGiでホワイトボードパターンを実装するための主要なメカニズムの1つです。つまり、このことにより、コンテナ内の特定のタイプのサービスを追加/変更するときにロジックを実行できます。

  private ServiceTracker<InstrumentationConsumer, Void> initTracker(final BundleContext bundleContext, final InstrumentationProvider instrumentationProvider) { return new ServiceTracker<>(bundleContext, InstrumentationConsumer.class, new ServiceTrackerCustomizer<InstrumentationConsumer, Void>() { @Override public Void addingService(ServiceReference<InstrumentationConsumer> serviceReference) { try { log.trace("addingService called"); final InstrumentationConsumer consumer = bundleContext.getService(serviceReference); log.debug("Consumer: {}", consumer); if (consumer != null) { applyInstrumentation(consumer, instrumentationProvider); } } catch (Throwable t) { log.error("Error on 'addingService'", t); } return null; } @Override public void modifiedService(ServiceReference<InstrumentationConsumer> serviceReference, Void aVoid) { } @Override public void removedService(ServiceReference<InstrumentationConsumer> serviceReference, Void aVoid) { } }); }

これで、InstrumentationConsumerクラスを実装するサービスがコンテナに登録されるたびに、次のことを行います。

 private void applyInstrumentation(InstrumentationConsumer consumer, InstrumentationProvider instrumentationProvider) { final Instrumentation instrumentation; try { instrumentation = instrumentationProvider.getInstrumentation(); consumer.applyInstrumentation(instrumentation); } catch (InstrumentationAgentException e) { log.error("Error on getting insrumentation", e); } }

java.lang.instrument.Instrumentationオブジェクトは次のように受信されます。

 @Component public class InstrumentationProviderImpl implements InstrumentationProvider { private static final Logger log = LoggerFactory.getLogger(InstrumentationProviderImpl.class); @Override public Instrumentation getInstrumentation() throws InstrumentationAgentException { try { final Class<?> agentClass = ClassLoader.getSystemClassLoader().loadClass(INSTRUMENTATION_CLASS_NAME);//     ,   javaagents log.debug("Agent class loaded from system classloader", agentClass); final Field instrumentation = agentClass.getDeclaredField(INSTRUMENTATION_FIELD_NAME);//   reflection log.debug("Instrumentation field: {}", instrumentation); final Object instrumentationValue = instrumentation.get(null); if (instrumentationValue == null) { throw new NullPointerException("instrumentation data is null. Seems agent is not installed"); } return (Instrumentation) instrumentationValue; } catch (Throwable e) { String msg = "Error getting instrumentation"; log.error(msg, e); throw new InstrumentationAgentException("Error getting instrumentation", e); } } }

検証エンジンの作成に移りましょう。

検証エンジン

変更を行うことが最も効果的なポイントを見つけます-DefaultIssueServiceクラス（実際、すべての作成/変更呼び出しがこのポイントを通過するわけではありませんが、これは別のトピックです）とそのメソッド：

validateCreate：

 IssueService.CreateValidationResult validateCreate(@Nullable ApplicationUser var1, IssueInputParameters var2);

およびvalidateUpdate：

 IssueService.UpdateValidationResult validateUpdate(@Nullable ApplicationUser var1, Long var2, IssueInputParameters var3);

そして、どのようなロジックが欠落しているのだろうと思います。

メインロジックを呼び出した後、必要に応じて結果を変更できる、コードによる初期パラメーターのカスタム検証が呼び出される必要があります。

ByteBuddyは、アイデアを実装するための2つのオプションを提供します。割り込みの支援とアドバイスメカニズムの支援です。アプローチの違いは、Raphaelのプレゼンテーションのスライドにはっきりと現れています。

Interceptor APIは十分に文書化されており、どのパブリッククラスもその1つとして機能できます。詳細はこちらをご覧ください。 Interceptor呼び出しは、元のメソッドの元のバイトコードINSTEADに埋め込まれています。

この方法を使用しようとすると、2つの重大な欠点が見つかりました。

一般に、元のメソッド、さらにはメソッド呼び出しのオブジェクトを取得する機会があります。ただし、ロード済みクラスのシグネチャの変更に関する制限のため、すでにロード済みのクラスをインスツルメントすると、元のメソッドが失われます（同じクラスのプライベートメソッドとして保存できないため）。したがって、元のロジックを再利用する場合は、自分で再作成する必要があります。
なぜなら実際に別のクラスのメソッドを呼び出す場合、クラスチェーン内のクラス間の可視性を確保する必要があります。クラスがOSGiコンテナー内でインスツルメントされている場合、可視性に問題はありません。ただし、この場合、JIRA APIのほとんどのクラスは、OSGiの外部にあるWebappClassLoaderによってロードされます。つまり、Interceptorのメソッドを呼び出そうとすると、当然のClassNotFoundExceptionが発生します。

プロジェクトの作業の過程で、この問題を解決するオプションが生まれましたが、アプリケーション全体のクラスをロードするロジックに干渉するため、徹底的なテストをせずに使用してスポイラーの下に置くことはお勧めしません。

ブートローダーの問題を解決する

主なアイデアは、WebappClassLoaderの親チェーンを切断し、そこにClassLoaderプロキシを挿入することです。これは、WebappClassLoaderの実際の親にダウンロードを委任する前に、BundleClassLoaderを使用してクラスをロードしようとします。

このように：

アプローチの実装は次のようになります。

 private void tryToFixClassloader(ClassLoader originalClassLoader, BundleWiringImpl.BundleClassLoader bundleClassLoader) { try { final ClassLoader originalParent = originalClassLoader.getParent(); if (originalParent != null) { if (!(originalParent instanceof BundleProxyClassLoader)) { final BundleProxyClassLoader proxyClassLoader = new BundleProxyClassLoader<>(originalParent, bundleClassLoader); FieldUtils.writeDeclaredField(originalClassLoader, "parent", proxyClassLoader, true); } } } catch (IllegalAccessException e) { log.warn("Error on try to fix originalClassLoader {}", originalClassLoader, e); } }

計測アプリケーションブロックで使用する必要があります。

 ... .transform((builder, typeDescription, classloader) -> { builder.method(named("validateCreate").and(ElementMatchers.isPublic())).intercept(MethodDelegation.to(Interceptor.class)); if (!ClassUtils.isVisible(InstrumentationConsumer.class, classloader)) { tryToFixClassloader(classloader, (BundleWiringImpl.BundleClassLoader) Interceptor.class.getClassLoader()); } }) .installOn(instrumentation);

この場合、WebappClassLoaderを介してOSGiクラスをロードできます。注意すべき唯一のことは、OSGiを使用してクラスをロードしようとしないことです。そのロードは、OSGiの外部に委任されます。これは明らかにループと例外につながります。
BundleProxyClassLoaderコード：

 class BundleProxyClassLoader<T extends BundleWiringImpl.BundleClassLoader> extends ClassLoader { private static final Logger log = LoggerFactory.getLogger(BundleProxyClassLoader.class); private final Set<T> proxies; private final Method loadClass; private final Method shouldDelegate; public BundleProxyClassLoader(ClassLoader parent, T proxy) { super(parent); this.loadClass = getLoadClassMethod(); this.shouldDelegate = getShouldDelegateMethod(); this.proxies = new HashSet<>(); proxies.add(proxy); } private Method getLoadClassMethod() throws IllegalStateException { try { Method loadClass = ClassLoader.class.getDeclaredMethod("loadClass", String.class, boolean.class); loadClass.setAccessible(true); return loadClass; } catch (NoSuchMethodException e) { throw new IllegalStateException("Failed to get loadClass method", e); } } private Method getShouldDelegateMethod() throws IllegalStateException { try { Method shouldDelegate = BundleWiringImpl.class.getDeclaredMethod("shouldBootDelegate", String.class); shouldDelegate.setAccessible(true); return shouldDelegate; } catch (NoSuchMethodException e) { throw new IllegalStateException("Failed to get shouldDelegate method", e); } } @Override public Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { log.trace("Trying to find already loaded class {}", name); Class<?> c = findLoadedClass(name); if (c == null) { log.trace("This is new class. Trying to load {} with OSGi", name); c = tryToLoadWithProxies(name, resolve); if (c == null) { log.trace("Failed to load with OSGi. Trying to load {} with parent CL", name); c = super.loadClass(name, resolve); } } if (c == null) { throw new ClassNotFoundException(name); } return c; } } private Class<?> tryToLoadWithProxies(String name, boolean resolve) { for (T proxy : proxies) { try { final String pkgName = Util.getClassPackage(name); //avoid cycle if(!isShouldDelegatePackageLoad(proxy, pkgName)) { log.trace("The load of class {} should not be delegated to OSGI parent, so let's try to load with bundles", name); return (Class<?>) this.loadClass.invoke(proxy, name, resolve); } } catch (ReflectiveOperationException e) { log.trace("Class {} is not found with {}", name, proxy); } } return null; } private boolean isShouldDelegatePackageLoad(T proxy, String pkgName) throws IllegalAccessException, InvocationTargetException { return (boolean)this.shouldDelegate.invoke( FieldUtils.readDeclaredField(proxy, "m_wiring", true), pkgName ); } }

誰かがこのアイデアを開発したい場合に備えて保存しました。

インストルメンテーションを実装するための2番目のオプションは、アドバイスを使用することです。この方法は文書化されたものよりもずっと悪いです。実際、例はGithubのチケットとStackOverflowへの応答でしか見つかりません。

しかし、すべてがそれほど悪いわけではありません

ここで私たちはラファエルに敬意を表する必要があります-私が見たすべての質問とチケットには詳細な説明と例が提供されているので、それを理解することは難しくありません-これらの作品が実を結び、さらに多くのプロジェクトでバイトバディを見ることを願っています。

デフォルトでは、アドバイスメソッドがクラスコードに埋め込まれているという点で、最初のものと異なります。私たちにとって、これは次のことを意味します。

ClassLoadersを使用しないダンス
元のロジックの保存-元のコードの前または後に特定のアクションのみを実行できます

完璧に聞こえます。元の引数、元のコードの結果（例外を含む）、さらに元のコードの前に機能したアドバイスの結果を取得できるシックなAPIが提供されています。ただし、常に「but」があり、埋め込みにはコードにいくつかの制限があり、埋め込みが可能です。

すべての埋め込みコードは1つのメソッドで実行する必要があります
メソッドには、埋め込み先のクラスにアクセスできないクラスメソッドへの呼び出しを含めることはできません。そして匿名（さよならラムダ！）
例外ポップアップはサポートされていません-例外はメソッド本体で明示的にスローする必要があります

Byte Buddyのドキュメントにはこれらの制限の説明はありませんでしたが
、アドバイスのスタイルでロジックを記述してみましょう。覚えているように、必要な計測を最小限に抑える必要があります。これは、特定の検証チェックを無視することを意味します-新しいチェックが表示されたときに、validateCreate / validateUpdateが呼び出されたときに実行されるチェックのリストに自動的に追加され、DefaultIssueServiceクラスのコードを変更する必要がないことを確認します
OSGiでは、これは簡単ですが、DefaultIssueServiceはフレームワークの範囲外であり、ここでOSGiテクニックを使用することはできません。

突然、JIRA APIが役立ちます。各アドオンは、このプラグインを検索できる特定のキーを持つPluginクラス（多くの特別な機能を備えたバンドルのラッパー）のオブジェクトとしてJIRAで表されます。

キーはアドオン構成で設定され、プラグインAPIはDefaultIssueServiceと同じクラスローダーでロードされます-したがって、アドバイスでプラグインを呼び出し、このプラグインに付属するクラスをロードすることを妨げるものは何もありませんたとえば、チェックアグリゲーターなどです。

その後、再び標準のcom.atlassian.jira.component.ComponentAccessor＃getOSGiComponentInstanceOfTypeを介してこのクラスのインスタンスを取得できます。
そして魔法はありません：

 public class DefaultIssueServiceValidateCreateAdvice { @Advice.OnMethodExit(onThrowable = IllegalArgumentException.class) public static void intercept( @Advice.Return(readOnly = false) CreateValidationResult originalResult,//        -   (readOnly = false) @Advice.Thrown Throwable throwable,//     -    @Advice.Argument(0) ApplicationUser user, @Advice.Argument(1) IssueInputParameters issueInputParameters ) { try { if (throwable == null) { //current plugin key final Plugin plugin = ComponentAccessor.getPluginAccessor().getEnabledPlugin("org.jrx.jira.instrumentation.issue-validation"); //related aggregator class final Class<?> issueValidatorClass = plugin != null ? plugin.getClassLoader().loadClass("org.jrx.jira.instrumentation.validation.spi.issueservice.IssueServiceValidateCreateValidatorAggregator") : null; final Object issueValidator = issueValidatorClass != null ? ComponentAccessor.getOSGiComponentInstanceOfType(issueValidatorClass) : null;//      API JIRA if (issueValidator != null) { final Method validate = issueValidator.getClass().getMethod("validate", CreateValidationResult.class, ApplicationUser.class, IssueInputParameters.class); if (validate != null) { final CreateValidationResult validationResult = (CreateValidationResult) validate .invoke(issueValidator, originalResult, user, issueInputParameters); if (validationResult != null) { originalResult = validationResult; } } else { System.err.println("==**Warn: method validate is not found on aggregator " + "**=="); } } } //Nothing should break service } catch (Throwable e) { System.err.println("==**Warn: Exception on additional logic of validateCreate " + e + "**=="); } } }

DefaultIssueServiceValidateUpdateAdviceは、クラス名とメソッド名に似ています。目的のメソッドにアドバイスを適用するInstrumentationConsumerを作成します。

 @Component @ExportAsService public class DefaultIssueServiceTransformer implements InstrumentationConsumer { private static final Logger log = LoggerFactory.getLogger(DefaultIssueServiceTransformer.class); private static final AgentBuilder.Listener listener = new LogTransformListener(log); private final String DEFAULT_ISSUE_SERVICE_CLASS_NAME = "com.atlassian.jira.bc.issue.DefaultIssueService"; @Override public void applyInstrumentation(Instrumentation instrumentation) { new AgentBuilder.Default().disableClassFormatChanges() .with(new AgentBuilder.Listener.Filtering( new StringMatcher(DEFAULT_ISSUE_SERVICE_CLASS_NAME, EQUALS_FULLY), listener )) .with(AgentBuilder.TypeStrategy.Default.REDEFINE) .with(AgentBuilder.RedefinitionStrategy.REDEFINITION) .with(AgentBuilder.InitializationStrategy.NoOp.INSTANCE) .type(named(DEFAULT_ISSUE_SERVICE_CLASS_NAME)) .transform((builder, typeDescription, classloader) -> builder //transformation is idempotent!!! You can call it many times with same effect //no way to add advice on advice if it applies to original class //https://github.com/raphw/byte-buddy/issues/206 .visit(Advice.to(DefaultIssueServiceValidateCreateAdvice.class).on(named("validateCreate").and(ElementMatchers.isPublic()))) .visit(Advice.to(DefaultIssueServiceValidateUpdateAdvice.class).on(named("validateUpdate").and(ElementMatchers.isPublic())))) .installOn(instrumentation); } }

ここで、素敵なボーナスについてお話しします。アドバイスの適用はi等です！アドオンVMを再インストールすると自動的に変換が行われるため、変換を2回適用しないように注意する必要はありません。

追加機能

, - , . , JRE (, JAXB ..), — , ..
, .. .

まあ、事は小さいです-アグリゲーターを書きます。最初に、検証APIを定義します。

 public interface IssueServiceValidateCreateValidator { @Nonnull CreateValidationResult validate( final @Nonnull CreateValidationResult originalResult, final ApplicationUser user, final IssueInputParameters issueInputParameters ); }

次に、呼び出し時に標準のOSGiツールを使用して、使用可能なすべての検証を取得して実行します。

 @Component @ExportAsService(IssueServiceValidateCreateValidatorAggregator.class) public class IssueServiceValidateCreateValidatorAggregator implements IssueServiceValidateCreateValidator { private static final Logger log = LoggerFactory.getLogger(IssueServiceValidateCreateValidatorAggregator.class); private final BundleContext bundleContext; @Autowired public IssueServiceValidateCreateValidatorAggregator(BundleContext bundleContext) { this.bundleContext = bundleContext; } @Nonnull @Override public IssueService.CreateValidationResult validate(@Nonnull final IssueService.CreateValidationResult originalResult, final ApplicationUser user, final IssueInputParameters issueInputParameters) { try { log.trace("Executing validate of IssueServiceValidateCreateValidatorAggregator"); final Collection<ServiceReference<IssueServiceValidateCreateValidator>> serviceReferences = bundleContext.getServiceReferences(IssueServiceValidateCreateValidator.class, null); log.debug("Found services: {}", serviceReferences); return applyValidations(originalResult, serviceReferences, user, issueInputParameters); } catch (InvalidSyntaxException e) { log.warn("Exception on getting IssueServiceValidateCreateValidator", e); return originalResult; } } private IssueService.CreateValidationResult applyValidations(@Nonnull IssueService.CreateValidationResult originalResult, Collection<ServiceReference<IssueServiceValidateCreateValidator>> serviceReferences, ApplicationUser user, IssueInputParameters issueInputParameters) { IssueService.CreateValidationResult result = originalResult; for (ServiceReference<IssueServiceValidateCreateValidator> serviceReference : serviceReferences) { final IssueServiceValidateCreateValidator service = bundleContext.getService(serviceReference); if (service != null) { result = service.validate(result, user, issueInputParameters); } else { log.debug("Failed to get service from {}", serviceReference); } } return result; } }

すべて準備完了-収集、設定

テスト検証

アプローチをテストするために、最も単純なテストを実装します。

 @Component @ExportAsService public class TestIssueServiceCreateValidator implements IssueServiceValidateCreateValidator { @Nonnull @Override public IssueService.CreateValidationResult validate(@Nonnull IssueService.CreateValidationResult originalResult, ApplicationUser user, IssueInputParameters issueInputParameters) { originalResult.getErrorCollection().addError(IssueFieldConstants.ASSIGNEE, "This validation works", ErrorCollection.Reason.VALIDATION_FAILED); return originalResult; } }

新しいタスクを作成してみてください！

これで、開発されたアドオンからアドオンを削除して再インストールできます-JIRAの動作が正しく変更されます。

おわりに

したがって、アプリケーションAPI（この場合はJIRA）を動的に拡張するツールを入手しました。もちろん、このアプローチを実稼働で使用する前に、徹底的なテストが必要ですが、私の意見では、ソリューションは完全には強化されておらず、適切な研究で、このアプローチは「絶望的な問題」を解決するために使用できます-長命のサードパーティの欠陥を修正し、APIを拡張するなど。

プロジェクト自体の完全なコードはGithubで見ることができます-健康のためにそれを使用してください！

PS 記事を複雑にしないために、プロジェクトアセンブリの詳細とJIRAのアドオンの開発の機能については説明しませんでした。これについては、こちらをご覧ください。

時間がないことよりも良い時間：JIRA APIをその場で拡張する