2016-06-15 2 views
0

Je migre de Jetty 8.1.17 vers Jetty 9.3.9. Notre application embarque Jetée. Auparavant, nous avions un seul fichier de configuration XML jetty.xml qui contenait tout ce dont nous avions besoin.Intégration de la jetée 9.3 avec la configuration Xml modulaire

Je sentais que la jetée avec 9.3.9, il serait beaucoup plus agréable d'utiliser l'approche modulaire qu'ils suggèrent, jusqu'à présent je jetty.xml, jetty-http.xml, jetty-https.xml et jetty-ssl.xml dans mon $JETTY_HOME/etc; ce sont à peu près des copies de celles de la distribution 9.3.9. Cela semble bien fonctionner quand j'utilise start.jar mais pas à travers mon propre code qui embarque Jetty.

Idéalement, je voudrais être en mesure de rechercher tous les fichiers xml jetée dans le dossier $JETTY_HOME/etc et charger la configuration. Cependant pour le mode embarqué, je ne l'ai pas trouvé un moyen de le faire sans définir explicitement l'ordre que ces fichiers doivent être chargés, en raison de <ref id="x"/> dépendances entre les etc.

Ma première tentative est basée sur How can I programmatically start a jetty server with multiple configuration files? et ressemble à:

final List<Object> configuredObjects = new ArrayList(); 
XmlConfiguration last = null; 
for(final Path confFile : configFiles) { 
    logger.info("[loading jetty configuration : {}]", confFile.toString()); 
    try(final InputStream is = Files.newInputStream(confFile)) { 
     final XmlConfiguration configuration = new XmlConfiguration(is); 
     if (last != null) { 
      configuration.getIdMap().putAll(last.getIdMap()); 
     } 
     configuredObjects.add(configuration.configure()); 
     last = configuration; 
    } 
} 

Server server = null; 
// For all objects created by XmlConfigurations, start them if they are lifecycles. 
for (final Object configuredObject : configuredObjects) { 
    if(configuredObject instanceof Server) { 
     server = (Server)configuredObject; 
    } 

    if (configuredObject instanceof LifeCycle) { 
     final LifeCycle lc = (LifeCycle)configuredObject; 
     if (!lc.isRunning()) { 
      lc.start(); 
     } 
    } 
} 

Cependant, je reçois des exceptions au démarrage si jetty-https.xml est chargé avant jetty-ssl.xml ou si je place une référence dans jetty.xml à un objet d'une sous-configuration jetty-blah.xml qui n'a pas été chargé en premier.

Il me semble que Jetty réussit à le faire lui-même quand vous appelez java -jar start.jar, alors qu'est-ce qui me manque pour que Jetty ne se soucie pas de l'ordre dans lequel les fichiers de configuration sont analysés?

Répondre

0

L'ordre est extrêmement important lors du chargement des fichiers XML Jetty.

C'est le cœur de ce que l'ensemble de start.jar et de son système de module est sur, ont un ensemble approprié de propriétés, le classpath du serveur est sain, et en assurant l'ordre de chargement approprié du XML.

Note: ce ne est pas possible d'avoir tout en ${jetty.home}/etc chargé en même temps, que vous obtiendrez des conflits sur implémentations alternatives de technologies communes (quelque chose start.jar gère également pour vous)

+0

Est-il possible que je peux facilement réutiliser/appeler le code de fonction de start.jar dans mon application intégrée, où je peux le présenter avec une liste de fichiers XML et il peut comprendre l'ordre etc pour moi? – adamretter

+0

vous ne pouvez pas démarrer start.jar avec seulement des fichiers xml. il doit travailler avec des modules. –

+0

vous êtes embarqué, déclarez l'ordre de chargement xml dans votre code imbriqué et utilisez-le. pas besoin d'être dynamique à ce sujet. –