Jersey ResourceConfigは自動的に検出されませんが、アプリケーションは検出しますか？

Question

私は非常に基本的なApplicationを持っている場合は、ジャージーの自動プロジェクト内のすべてのRESTリソースを発見し、私はそれらを手動で登録する必要はありません。

import javax.ws.rs.ApplicationPath; 
@ApplicationPath("/rest") 
public class Application extends javax.ws.rs.core.Application { 

} 

しかし、私はジャージー特定ResourceConfigの使用に切り替える際に、自動発見は機能していないようです。私は、以下に示すようにいずれか#registerClasses()またはパッケージを追加する必要があります。

@ApplicationPath("rest") 
public class ResourceConfig extends org.glassfish.jersey.server.ResourceConfig { 
    public ResourceConfig() { 
     super();   
     register(RolesAllowedDynamicFeature.class); 
     super.packages(true, "org.example"); 
    } 
} 

個別にクラスを登録することや、アプリケーションのパッケージを追加することなく、自動にResourceConfigがApplicationのようなRESTリソースを発見取得する方法はありますか？

Answer 1

クラスパススキャンの原因はApplicationクラスで、ではなく、というものは何も登録しません。あなたのResourceConfig（Applicationを拡張）では、RolesAllowedDynamicFeatureを登録していないと、クラスパススキャンを受けることになります。私の推測では、ResourceConfigに切り替えたので、はに登録しましたRolesAllowedDyanamicFeature（多分あなたが見た例の中から）。これはgetClasses()をオーバーライドしてApplicationクラスで行うこともできます。しかし、私が言ったように、何かをに登録すると、クラスパススキャンが失われ、すべてを手動で登録する必要があります。

回避策は、クラスパススキャンで選択されないすべてのクラスを登録するためにFeatureを実装することです。

@Provider 
public class ClassPathScanWorkAroundFeature implements Feature { 
    @Override 
    public boolean configure(FeatureContext context) { 
     context.register(RolesAllowedDynamicFeauture.class); 
     return true; 
    } 
} 

これはApplicationまたはResourceConfigクラスの両方のために動作します。クラスパススキャン中に何が起こるかは、ジャージーが登録する注釈クラスの両方を@Pathと@Providerのように探すことです。このため、手動で登録し、クラスパススキャンを維持するための回避策があります。

私が指摘することの1つは、Jerseyの開発者の次の記事です。

• When to Use JAX-RS Class-path Scanning Mechanism

基本的に、彼らはそれを使用しないように決して示唆しています。個人的にはパッケージスキャンに固執します。私はそれが本当に人生をはるかに困難にするとは思わない。 Featureを使用する代わりに、実際にはより小さく、コードです。