2014-11-03 7 views
6

Attualmente, faccio qualcosa di simile aJAX-RS: come estendere la classe dell'applicazione per scansionare i pacchetti?

import javax.annotation.Nonnull; 
import javax.ws.rs.ApplicationPath; 
import javax.ws.rs.core.Application; 
import java.util.Collections; 
import java.util.HashSet; 
import java.util.Set; 

@ApplicationPath("oauth") 
public class OAuthApplication extends Application { 
    final Set<Class<?>> classes = new HashSet<>(); 

    @Nonnull 
    @Override 
    public Set<Class<?>> getClasses() { 
     classes.add(RegisterResource.class); 
     return Collections.unmodifiableSet(classes); 
    } 
} 

No se aggiungo dieci nuovi Resource s sul ApplicationPath, ho bisogno di fare

classes.add(<ClassName>.class); 

dieci volte, è noioso e talvolta dimentico pure .

JAX-RS o RESTEasy fornire il modo in cui posso menzionare il nome del pacchetto e le classi vengono scansionate sotto di esso?

So Jersey ha qualcosa come

public class MyApplication extends ResourceConfig { 
    public MyApplication() { 
     packages("org.foo.rest;org.bar.rest"); 
    } 
} 

Reference

tutti i pensieri/idee?

UPDATE

Sembra che possiamo fare in seguito web.xml

<context-param> 
     <param-name>resteasy.scan</param-name> 
     <param-value>true</param-value> 
    </context-param> 

Esiste una specifica Java equivalente?

risposta

1

è una combinazione di tutte le classi di applicazione, ResourceClass e @ApplicationPath

in accordo con il docs e la classe ResourceConfig attrezzi per la maglia modo per farlo è:

@ApplicationPath(value = "/resource") 
public class ApplicationREST extends ResourceConfig { 

    public ApplicationREST() { 
     //add single resources 
     register(SimpleResource1.class); 
     register(SimpleResource2.class); 
     ... 

     //enable multipar feature 
     register(MultiPartFeature.class); 
     ...    

     //enable scan package and recursive 
     packages(true, "com.example.rest"); 
    } 
} 

Spero che questo ti aiuta

+0

L'ho usato ma all'inizio, mi ha dato 500 per non aver registrato MultiPartFeature e dopo averlo registrato, ha dato 404 per tutte le mie API. qualche idea? –

6

"Esiste un equivalente Java specifico?"

è sufficiente lasciare la classe vuota, significato non ignorare getClasses() o getSingletons(). Per the spec - 2.3.2:

[...]

In entrambi questi ultimi due casi, se entrambi Application.getClasses e Application.getSingletons restituire un elenco vuoto, allora tutte le classi di risorse di root e fornitori confezionati nell'applicazione Web deve essere inclusi nel l'applicazione JAX-RS pubblicata. Se getClasses o getSingletons restituiscono un elenco non vuoto, solo le classi o singletons restituiti DEVONO essere inclusi nell'applicazione JAX-RS pubblicata.

Così si può semplicemente fare

@ApplicationPath("oauth") 
public class OAuthApplication extends Application {} 

e classpath otterrà digitalizzata per @Path e @Provider classi. Esegui l'override di entrambi i metodi (restituendo un set non vuoto) e verranno aggiunte solo quelle classi.

Si noti inoltre che public Map<String, Object> getProperties() può essere sovrascritto in modo sicuro. È possibile utilizzare questo per aggiungere proprietà arbitrarie (anche per registrare le classi/funzioni), come seen here, o se è necessario configurare un provider, è possibile farlo in un Feature o DynamicFeature come seen here

+0

Forse questa dovrebbe essere una domanda separata, ma sto trovando che, con la soluzione suggerita qui, la mia applicazione JAX-RS non preleva automaticamente alcuni provider di ExceptionMapper registrati che risiedono in un EJB package separato nell'EAR, che anche contiene la GUERRA. Preferirei non dover aggiungere esplicitamente ogni classe, come indica l'OP, ma è necessario il tipo di collegamento "aggiungi pacchetto" fornito da Jersey, e ancora non riesco a trovare un modo per farlo con RESTEasy. qualche idea? –

+0

Sembra che io abbia bisogno di una domanda diversa perché l'aggiunta esplicita di tutte le classi in un metodo getClasses() sottoposto a override in realtà non funziona. Né li registra come una caratteristica. Deve esserci qualcosa di speciale in questi provider di ExceptionMapper. Hmm ... –

+0

Facendo un piccolo progresso ... i log Wildfly indicano che una delle eccezioni che sembra non essere gestita correttamente è una EJBException: ERRORE [io.undertow.request] (task-121 di default) UT005023: Gestione delle eccezioni richiesta a/rest/authenticate: org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBException: io.jsonwebtoken.ExpiredJwtException. L'aggiunta di un ExceptionMapper per EJBException mi consente di gestire questa eccezione, ma non capisco appieno il motivo per cui ciò si verifica, quando una ExpiredJwtException generata nel mio pacchetto EJB (anziché WAR) non presenta questo problema. –

0

E 'molto semplice:

import javax.ws.rs.ApplicationPath; 
import javax.ws.rs.core.Application; 

@ApplicationPath("/webapi") 
public class MyApp extends Application { 

} 

Analizzerà tutte le classi annotate con @Provider e @Path.

Problemi correlati