URL di un'applicazione Jersey utilizzando ResourceConfig senza web.xml

Question

Sono migrato da web.xml alla configurazione totalmente Java utilizzando ResourceConfig con Jersey 2.7 e distribuendo su Tomcat 7. Dopodiché non sono più in grado di raggiungere i servizi utilizzando lo stesso urls che stavo usando con l'approccio web.xml. Non capisco come il ResourceConfig sta influenzando i percorsi.

mio precedente web.xml

<?xml version="1.0" encoding="UTF-8"?> 
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"  
version="3.0"> 
<servlet> 
    <servlet-name>my.app</servlet-name> 
    <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class> 
    <init-param> 
     <param-name>jersey.config.server.provider.packages</param-name> 
     <param-value>com.mypackage.resource,com.mypackage.providers</param-value> 
    </init-param> 
    <init-param> 
     <param-name>jersey.config.server.provider.scanning.recursive</param-name> 
     <param-value>true</param-value> 
    </init-param> 
    <init-param> 
     <param-name>jersey.config.server.provider.classnames</param-name> 
     <param-value>org.glassfish.jersey.filter.LoggingFilter</param-value>   
    </init-param> 
    <init-param> 
     <param-name>org.glassfish.jersey.server.ServerProperties.BV_SEND_ERROR_IN_RESPONSE</param-name> 
     <param-value>true</param-value> 
    </init-param> 
    <load-on-startup>1</load-on-startup> 
</servlet> 
<servlet-mapping> 
    <servlet-name>my.app</servlet-name> 
    <url-pattern>/*</url-pattern> 
</servlet-mapping> 

La mia classe di configurazione che si estende ResourceConfig è:

MyRESTAPIApp.java

@ApplicationPath("") 
public class MyRESTAPIApp extends ResourceConfig{ 
    public MyRESTAPIApp() { 
     packages("com.mypackage.resource", "com.mypackage.providers"); 
     register(org.glassfish.jersey.filter.LoggingFilter.class); 
     property("jersey.config.beanValidation.enableOutputValidationErrorEntity.server", "true"); 
    } 
} 

una delle mie risorse è:

FlagResource.java

@Path("my-resource") 
public class FlagResource { 
private MyService myService = new MyService(); 

@GET 
@Produces(MediaType.APPLICATION_JSON) 
public FlagResource getFlagResource(@NotNull @QueryParam("level") Long level) { 
    FlagResource flagResource = myService.getFlagResource(level); 
    return flagResource; 
} 

}

La guerra che sto generando si chiama: my.app.war.

Tomcat stava seguendo normalmente il percorso root del contesto Web dal nome del file war, ma non so se questo cambi quando si utilizza la configurazione basata su codice Java.

GET http://localhost:8080/my.app/my-resource?level=1 

Restituisce un 404

Answer 1

In realtà ho risolto questo con l'aggiunta di "/" come valore dell'annotazione @ApplicationPath, ho pensato che non era necessario perché la documentazione API dice quanto segue per il valore @ApplicationPath param :

Defines the base URI for all resource URIs. A trailing '/' character will be automatically appended if one is not present. 

ho pensato che lasciando una stringa vuota sarà equivalente utilizzare @ApplicationPath ("/") ma non è.

Quindi questo è come la classe di configurazione si presenta ora:

@ApplicationPath("/") 
public class MyRESTAPIApp extends ResourceConfig{ 
    public MyRESTAPIApp() { 
     packages("com.mypackage.resource", "com.mypackage.providers"); 
     register(org.glassfish.jersey.filter.LoggingFilter.class); 
     property("jersey.config.beanValidation.enableOutputValidationErrorEntity.server", "true"); 
    } 
}