8
votes

Stratégies communes lors de la définition des haricots de printemps pour différents environnements

Quelles sont les stratégies courantes pour définir une bande de haricots, qui sont utilisées différemment dans les environnements de développement et de production?

Disons que j'ai 2 haricots, chacun mettant en œuvre la même interface. Un haricot sert d'abstraction pour le système de fichiers local, l'autre se connecte à un système de fichiers distribués. Pour maintenir le développement aussi stable, possible, l'environnement de développement devrait utiliser la mise en œuvre du système de fichiers local, la version de la production utilise le haricot de fichier de fichiers distribué.

actuellement ce que je fais est de deux définitions XML.

natif.xml xxx

distribué.xml xxx

Lors de la création de contexte d'application, je ometez soit native.xml ou distribué.xml en fonction de l'environnement et saisissez le système System Bean.

Y a-t-il des outils appropriés ou des meilleures pratiques au printemps pour configurer les définitions de haricot pour différents environnements?

Merci.

java spring configuration 0 commentaires

3 Réponses : 3 votes C'est ce que j'ai utilisé dans nombre de mes projets. Avoir tout votre environnement haricots indépendants à dire common.xml et tous les autres à dire dev.xml / qa.xml / prod.xml . Si vous utilisez la fourmi pour créer votre projet, fournissez l'environnement comme argument au processus de construction et laissez le script de construction incluent env.xml approprié et omettez les autres. Je veux dire, le script de construction copiera dev.xml comme env.xml si son environnement de devise ou qa.xml comme env.xml si son QA. Donc, le code qui charge les définitions de haricot utilisera toujours "commun.xml, env.xml". 1 commentaires @chedline Great Technique! 1 votes Cette fonctionnalité est sur le radar de SpringSource et est prévu pour les futures versions. voir ici et ici . 0 commentaires 11 votes Voici quelle documentation de référence de printemps dit sur PropertyPlaceholderConfigureur La propriétéLeLiderConfigurier ne cherche pas les propriétés uniquement dans les propriétés Fichez que vous spécifiez, mais vérifie également les propriétés du système Java s'il ne trouve pas de propriété que vous essayez d'utiliser. Comme vous pouvez le voir ci-dessus, vous pouvez configurer une propriété Système Java sur la machine de développement xxx sur la machine de production xxx afin que vous puissiez définir un contexte de contexte d'application global qui importation chaque paramètre de contexte en couches comme suit xxx Gardez à l'esprit que tous les chemins d'emplacement sont par rapport au fichier de définition effectuant l'importation par conséquent, ce type de configuration est pris en charge par le ressort Il est généralement préférable de conserver une indirection pour de tels emplacements absolus, par exemple, à travers des espaces réservés "$ {...}" qui sont résolus contre les propriétés du système JVM à l'exécution . . 1 commentaires Merci, c'est exactement la stratégie que je cherchais :)

Articles qui pourrait vous intéresser : Comment envoyer une liste vide à la clause IN Code de réponse 403 inattendu lors de la récupération des données des API Impossible de trouver la classe UnityPlayerActivity dans com.unity3d.player Comment définir un tableau dans jsonobject