J'essaie d'écrire quelques services Web Java simples afin que nous puissions appeler le code Java de .NET. Jusqu'à présent, j'ai eu une preuve de concept travaillant sous Glassfish. Assez simple lorsque l'IDE fait tout le travail.
Maintenant, je suis vraiment enlérité sur des choses en Java que devrait être vraiment simple . Par exemple, je veux externaliser ma configuration afin que je puisse modifier des trucs comme des chaînes de connexion / des noms d'utilisateur / des variables d'application / etc. sans recompilation.
in .NET, vous alliez simplement coller des chaînes dans le fichier web.config à la racine du site Web et utiliser: Je peux obtenir Java.Util.properties de faire ce que je veux (d'un client autonome), mais je ne peux pas comprendre où placer le fichier .properties et comment obtenir le chemin d'accès à partir du service Web .
J'ai besoin de mon approche pour travailler dans WebSphere Application Server. Merci! configurationManager.appsettings ["Sans quoi que ce soit];
5 Réponses :
La configuration de l'application est malheureusement dépendante du conteneur. En général, vous accédez à votre configuration via JNDI. L'approche que j'ai récemment utilisée était la suivante:
alors c'est une question de faire em.find (paramètre.class, "Welawant"). GetValue () . Sinon, vous pouvez créer une seule bean d'entité avec tous les paramètres sous forme d'attributs.
De toute façon, cette approche réduit la dépendance du conteneur à un minimum.
Hélas, Java EE a un trou géant dans la tête en matière de configuration de l'application.
Votre meilleur pari est de:
Utilisez JNDI pour stocker la configuration dans l'environnement du serveur d'applications. C'est difficile à faire de manière portante, douloureuse et absolue de cauchemar pour l'utilisateur de faire une configuration. Configuration UI dépend du serveur d'applications et de la version utilisée et peut être une utilité de ligne de commande spécifique à ce serveur d'applications.
Utilisez les préférences API pour stocker votre configuration et produire votre propre assurance-emploi pour le modifier. C'est bon ... Sauf que vous ne pouvez pas contrôler lorsque vos paramètres sont rinçus et réintroçus. Certains serveurs d'applications feront cela lorsque votre application est renvoyée, que vous ne voulez probablement pas.
Dans l'ensemble, la situation pue absolument. Il n'y a pas de manière propre et judicieuse pour un serveur d'applications pour fournir une application avec une carte de propriétés simples et une interface utilisateur pour la modifier à l'aide des outils d'administration du serveur d'applications.
J'ai essayé de contourner cela à l'aide de paramètres de contexte Web, mais j'ai constaté qu'ils étaient en buggy. Glassfish ignorait plus que le premier paramètre de contexte Web qui était défini et qu'ils ont été difficiles à accéder sans avoir un contexte de servlet, vous ne pouviez pas vraiment y arriver facilement sur toute l'application.
Si quelqu'un a une meilleure réponse, j'aimerais l'entendre, car la situation telle qu'elle se tient semble carrément incroyable pour une spécification qui a traversé plusieurs itérations majeures.
Voir aussi: Configuration de la configuration et de modification des applications Java EE
Vous pouvez utiliser un MXBean pour stocker les paramètres (carte de la propriété = valeur) afin que vous puissiez lire / mettre à jour les paramètres au moment de l'exécution avec des outils tels que JConsole / Visualvm
Comme d'autres personnes ont mentionné, il dépend considérablement du conteneur, mais des configurations dynamiques presque toujours sont stockées dans une base de données au lieu de fichiers XML ou .properties.
Comme je vois que c'est comme une preuve de concept, voici ici Une solution rapide et sale: (ne faites pas cela pour le code de production) Utiliser les propriétés du système. Inconvénient: avec chaque changement, vous devez redémarrer le conteneur, mais vous n'avez pas besoin de recompiler l'application. P>
Pour utiliser les propriétés du système dans Glassfish, vous pouvez accéder à la section "Configuration -> Propriétés du système" et ajouter des propriétés là-bas. Ensuite, de l'intérieur de votre application, appelez simplement P>
String myValue = System.getProperty("myProperty");
Je ne comprends pas pourquoi vous dites que ces propriétés du système sont une solution rapide et sale, pas pour la production. D'après ce que je peux dire, je pense qu'ils ont leur place en plus de stockage de la base de données, pour des cas rares, ainsi que dans la production.
Pour quelques propriétés, cela peut être correct, mais ils n'étaient pas destinés à remplacer la configuration complète d'une application. Une seule question est la séparation des préoccupations, car elles sont disponibles de n'importe où, des configurations destinées à être utilisées uniquement par une couche peuvent également être utilisées à d'autres endroits. L'autre problème est la sécurité, je ne suis pas sûr, mais je pense qu'ils sont partagés parmi toutes les applications déployées sur le serveur, car elles fonctionnent dans le même JVM. Que se passe-t-il si une application malveillante est déployée et modifie votre configuration en appelant system.setproperty ("myProperty", "Fakevalue")? Ils sont mutables des valeurs super globales.
C'est la meilleure réponse à notre situation, si nous allons passer à cet itinéraire. Nous utilisons un système de stockage de configuration, mais vous avez besoin de l'environnement situé entre différents serveurs de glucides. Nous voulons que le même dossier de guerre fonctionne sur l'un de nos serveurs de verre de verre, à l'exclusion de l'environnement actuel (local, développement, production, etc.) de la guerre est notre objectif afin que nous sachions quelle configuration à obtenir à partir du stockage de configuration. Sinon, nous pensions à stocker dans le stockage de configuration et à la vérification de l'environnement basé sur le serveur, ainsi que par défaut local. Toute autre idée serait aussi appréciée.
La meilleure solution que j'ai trouvée jusqu'à présent est " EAC4J (configuration d'application externe pour Java) ". J'ai utilisé avec succès dans de nombreux projets.
Mettez le code suivant dans la méthode contextInitialisée d'un servletContextListener: Ceci lit de l'application.Properties à partir du dossier Web-INF de votre application Web lorsqu'il commence. Cela nécessitera un redémarrage à chaque fois que le changement de configuration, mais à mon avis, c'est comme ça devrait être.
Hmm. Je doute vraiment de la nécessité de la balise ".NET" dans cette question.