2015-10-08 12 views
6

Sto cercando di creare un semplice PoC per sostituire un'app che attualmente si basa su file JAR caricati in un'app Web Java (Spring MVC 4.2) principale su dichiarare controller aggiuntivi all'avvio. Sembra più o meno così:Utilizzare la funzionalità @RequestMapping (mappatura del metodo da URL a Java) senza richiesta HTTP/servlet

Client <--HTTP--> Gateway+app (Spring MVC + order.jar)

Exposed endpoints: 
/ping via controller in core Spring app 
/orderApp/doSomething via controller in order.jar 

Idealmente, mi piacerebbe avere ogni file JAR di essere standalone applicazioni Primavera di avvio, lo scambio di dati utilizzando Primavera Integrazione 4,2 (via AMQP) con la mia HTTP gateway di fronte al mondo esterno. Un po 'lo schema:

Client <--HTTP--> Gateway (Spring MVC) <--AMQP--> Standalone orderApp (Spring Boot)

Exposed endpoints: 
/ping via controller in core Spring MVC app 
/{appName}/** via controller in core Spring MVC app 

ho logica nel controller in app MVC che trova che lo scambio AMQP dovrebbe ricevere i messaggi in base al appName, ho puntate la richiesta HTTP utilizzando un gateway, mando alla app appropriata, può elaborarla, rispedire la risposta alla principale app di Spring che inoltra la risposta al client. Nessun problema qui.

Tuttavia, mi piacerebbe se possibile riutilizzare la comoda annotazione @RequestMapping attualmente in uso nei miei file JAR. Questi JAR contengono fondamentalmente controller aggiuntivi, che espongono endpoint sotto una determinata radice.

Domanda

Come attivare manualmente la @RequestMapping logica, dato un URL, un corpo della richiesta e le intestazioni come input? Per esempio, diciamo che ho un applicazione del genere:

@RequestMapping("projects/{projectId}") 
public Project projectById(@PathVariable final String projectId) { 

    (...) 
    return project; 
} 

C'è un modo che da un codice di servizio personalizzato da qualche parte nella mia app standalone ho potuto fare una chiamata, come handler.getResponse("projects/123abc", requestBody, requestHeaders), che sarebbe di trovare automaticamente il metodo chiamare dato i parametri di input/URL?

Non voglio tutte le funzionalità da @RequestMapping (nessun accesso diretto a HttpServletRequest/HttpServletResponse per esempio, ovviamente). Quello che voglio fare è un po 'come una simulazione di HttpServletRequest, ma senza tutto il sovraccarico di servlet e tutto il resto. E dovrebbe essere il codice di "produzione", non qualcosa usato nei test.

In caso contrario, non ho nulla contro l'utilizzo di qualcosa di diverso da @RequestMapping, a condizione che riesca a ottenere lo stesso tipo di mappatura tra URI e metodi Java, ottenendo automaticamente i parametri estratti dall'URI. Un router Spring Integration personalizzato? So che SI ha un supporto request-mapping, ma solo su HTTP da quello che ho visto.

risposta

1

Non è del tutto chiaro quello che stai cercando; hai già detto che stai eseguendo il routing all'app di back-end determinando la chiave di scambio/routing nel controller.

Se si intende che ogni servizio di back-end deve gestire più tipi di richieste e necessita di ulteriore routing, allora sì, un router è probabilmente la soluzione migliore.

La domanda è come comunicare tali informazioni (percorso) al back-end, presumibilmente in una proprietà/intestazione del messaggio.

Si è corretto nel fatto che SI utilizza solo il mapping delle richieste internamente negli endpoint HTTP, ma non vi è nulla che impedisca di scrivere un router basato su annotazione che utilizza le stesse annotazioni.

Problemi correlati