Javaサービスはどのように機能するはずですか？

Question

誰もが不快なブラシを持っているようです Javaサービスプロバイダー, 、Meta-inf/services/com.example.interfaceなどの名前のファイルでできるが、右のXMLパーサーをロードしようとする以外は誰も使用しないということです。サービスプロバイダーAPIを使用するライブラリを使用して、それをだまして、実際にインターフェイスを実装していないが、簡単に行うことができるランタイム拡張クラス（CGLIBを使用）を提供できるようにしようとしています。

基本的に、私が実行する必要があるステップは次のとおりです。

1. getResources（...）に応答するカスタムクラスローダーを作成し、「追加」URLを返します
2. また、「追加の」リソースを求められたときに、CGLIBで操作するクラスのリストを返すために、そのクラスローダーフックgetResourceasStream（...）を持っています
3. 最後に、要求されたときにそのクラスローダーにそれらのクラスをロードしてもらう

しかし、ここが私が迷子になるところです。たとえば、ライブラリがそこにある実装者が何であるかを判断しようとすると、urlsの束を返すgetResources（...）を呼び出します。しかし、getResourceasStream（...）はURLを取得せず、「名前」を取ります。 ClassPathに関連しているように見える名前、したがってどこでも同じ名前。したがって、Meta-inf/services/com.example.interface inは、jarのmeta-inf/services/com.example.interfaceと同じ「名前」を持っていますよね？どういうわけか、これはそれらの爆破されたXMLパーサーで動作します...

もちろん、このすべては、classloader.getsystemResources（...）、classloader.getsystemresourceasStream（...）などを使用するのではなく、classloader.getSystemClassLoader（）を呼び出すのに十分なスマート/親切であると仮定しています。クラスローダーをフックして偽造ファイルを提供する方法はありません。

その場合、CGLIBで実行するまで待機するのではなく、コードがMavenによってパッケージ化されているときにBCELを使用してクラスファイルを操作できると思いますか？

Answer 1

私が説明したアイデアは、正しい軌道に沿っていました。私が犯した間違いは、それを使用することを考えることでした ClassLoader.getResourceAsStream(..) URLの内容にアクセスします。代わりに、あなただけが必要です URL.openStream().

投稿する前に見つけたのですが、 java.util.ServiceLoader （@since 1.6）は、物事を正しく行う方法についての洞察を提供します。