il problema è che il DefaultServerFactory aggiunge tutti applicationConntectors per lo stesso gestore, vedere DefaultServerFactory # accumulo:
@Override
public Server build(Environment environment) {
printBanner(environment.getName());
final ThreadPool threadPool = createThreadPool(environment.metrics());
final Server server = buildServer(environment.lifecycle(), threadPool);
LOGGER.info("Registering jersey handler with root path prefix: {}", applicationContextPath);
environment.getApplicationContext().setContextPath(applicationContextPath);
final Handler applicationHandler = createAppServlet(server,
environment.jersey(),
environment.getObjectMapper(),
environment.getValidator(),
environment.getApplicationContext(),
environment.getJerseyServletContainer(),
environment.metrics());
LOGGER.info("Registering admin handler with root path prefix: {}", adminContextPath);
environment.getAdminContext().setContextPath(adminContextPath);
final Handler adminHandler = createAdminServlet(server,
environment.getAdminContext(),
environment.metrics(),
environment.healthChecks());
final RoutingHandler routingHandler = buildRoutingHandler(environment.metrics(),
server,
applicationHandler,
adminHandler);
server.setHandler(addStatsHandler(addRequestLog(server, routingHandler, environment.getName())));
return server;
}
Quello che dovete fare è implementare il proprio ServerFactory.
È possibile estendere DefaultServerFactory e sovrascrivere il metodo build per impostare i connettori nel modo in cui si desidera che siano. Presumibilmente si vorrà aggiungere un po 'di più di configurazione che indica cosa va dove, dal momento che in termini di vostro YAML non sarà possibile mappare una risorsa a un connettore specifico. Come lo saprebbe il dropwizard?
Per sovrascrivere il comportamento per dropwizard (aggiunta di un nuovo ServerFactory) si può vedere questo post che ho scritto sulla registrazione aggiungendo: Dropwizard doesn't log custom loggers to file
Si tratta fondamentalmente implementando la classe e rendendolo rilevabile per dropwizard. Dopodiché, tutto ciò che devi fare è cambiare il file yaml in modo che punti a ServerFactory corretto.
Se non ti piace questo approccio, è possibile sovrascrivere il metodo get/set della configurazione per tornare la vostra classe. Per questo, la tua classe DEVE estendere DefaultServerFactory, altrimenti il mapping yaml non funzionerà più. È comunque possibile sovrascrivere il metodo di compilazione.
Aggiornamento:
Guardando in un po 'più in dettaglio, si incorrerà in un secondo problema:
vostro ambiente ha un solo ambiente di maglia che si può utilizzare. Dovrai configurare un secondo ambiente jersey poiché attualmente per impostazione predefinita ogni gestore riceverà la stessa configurazione di jersey (l'unica esistente). Questo è il motivo per cui sarà disponibile per tutte le tue configurazioni http. Quindi, in sintesi:
- creare un nuovo ambiente che supporta più configurazioni jersey
- Creare una fabbrica server che sa quello maglia config appartiene a quale Handler e istanzia i gestori in quella forma.
credo sarebbero tenuti questi due passaggi.
In termini di ambiente, sarà necessario creare il proprio ServerCommand (ovvero il comando che avvia il server dropwizard). Guardando in AmbienteComando # puoi vedere dove viene creato l'Ambiente. Questo sarà l'unico posto in cui puoi sovrascrivere l'Ambiente predefinito (per quanto ne so) che è ciò che devi fare per supportare più configurazioni di jersey.
Per essere onesto con te, guardando a questo, non credo che questo fosse quello che i ragazzi del dropwizard avevano in mente.
Sono curioso - qual è il motivo dietro l'esecuzione di ogni risorsa su una porta diversa? –
Ho lo stesso bisogno. Il problema è la sicurezza. Alcuni servizi dovrebbero essere esposti al mondo esterno e alcuni solo nella sottorete. Se metti tutti i servizi privati su una porta separata e poi blocchi l'accesso a quella porta nel firewall, allora sei a posto. – ccleve