Swagger-core: Toute solution de contournement pour la configuration de la classe d'application personnalisée pour Swagger avec un Jersey ResourceConfig

Je suis le guide de mise à niveau de 1.3.12 à 1.5.6 ainsi que le guide de configuration du projet Jersey 2.X. Je rencontre un problème avec la sous-classe « Application personnalisée », qui fournit l'exemple de code ci-dessous :

public class SampleApplication extends Application {
    <strong i="7">@Override</strong>
    public Set<Class<?>> getClasses() {
        Set<Class<?>> resources = new HashSet();

        //resources.add(FirstResource.class);
        //resources.add(SecondResource.class);
        //...

        resources.add(io.swagger.jaxrs.listing.ApiListingResource.class);
        resources.add(io.swagger.jaxrs.listing.SwaggerSerializers.class);

        return resources;
    }
}

Notre projet s'écarte de l'exemple que vous fournissez car il étend une classe Jersey ResourceConfig plutôt qu'une Application directement. Le problème est que la classe ResourceConfig elle-même remplace la méthode getClasses() et la déclare finale.

Connaissez-vous un moyen de contourner cette restriction, soit en ajoutant les ressources nécessaires à une autre partie de l'application du maillot, soit en utilisant d'autres moyens de cajoler le fanfaron ? Les ajouter via la méthode d'assistance ResourceConfig.register() rend le fichier swagger.json disponible au chemin habituel, mais ne le remplit pas avec la documentation des classes de point de terminaison qui ont été annotées avec @Api et sont également registered() (et fonctionnaient avant la mise à niveau). Je ne veux pas emprunter la voie du servlet ou du filtre web.xml.

Le swagger.json généré ne contient que les éléments supplémentaires que j'ai définis dans le nouveau BeanConfig, comme ceci :

// http://localhost:8080/v1.0/swagger.json

{
  "swagger": "2.0",
  "info": {
    "description": "Description of my App.",
    "version": "1.0",
    "title": "MyApp"
  },
  "basePath": "/v1.0"
}

Merci de votre aide.