Bonjour, ils nous ai demandé d’afficher sur une api nos différents services.
Tel que le service mindefconnect(authentification), BDD, servicemail, espace de stockage.
Pour les deux premiers on a répliqué le code d’une autre appli en l’adaptant.
utilisation de Java.net avec la classe httpURLConnection pour le service d’authentification.
Javax.sql avec la Datasource pour le sgbd.
Pour le service mail on voulais utilisé jakarta mail, mais on ne connais pas le nom du service on a testé :“java:/comp/env/mail/simplicite” comme la valeur était définit à un endroit du template mais le nom de ce service n’est pas connu, le service mail est définit seulement dans le MAIL_SERVICE et non dans le serveur context.xml du serveur Tomcat.
Actuellement en 5.3.37.
Je ne comprend pas bien le besoin… Qu’est ce que vous devez exposer exactement ? Peut on avoir un exemple de ce qui est attendu ?
Il y a déjà beaucoup d’informations techniques sur le health check (qui peut être appelé de manière à retourner du JSON plutôt que du texte : /health.json)
PS: vous pouvez configurer un service mail (statique) dans votre context.xml sous le nom java:comp/env/mail/simplicite l’autre approche (dynamique) étant de le configurer dans le param système MAIL_SERVICE
Si vous êtes dans le cas MAIL_SERVICE et que vous devez exposer les caractéristiques techniques de connexion à ce service il suffit donc de récupérer le contenu de ce param système (qui contient du JSON et exactement le même type de paramètres qu’un mail service statique)
PS2: et s’agissant de la base de données vous avez un accesseur sur les metadata du datasource (null = datasource par défaut) via:
DatabaseMetaData md = Grant.getSystemAdmin().getDBMetaData(null);
Donc pas la peine de passer par les couches basses pour obtenir des infos techniques sur la base.
Pas la peine non plus de passer par des couches trop basses pour appeler des URLs externes, il y a des tools pour ça (ex: Tool.readUrl) ou des outils dédiés type la lib Unirest ou au pire les commons Apache déjà embarqués
Sinon pour ce qui est d’exposer une API custom je ne sais pas quelle approche vous avez choisie mais la bonne approche c’est d’implémenter un objet externe de type API (i.e. qui hérite de RESTServiceExternalObject) et de l’habiliter au groupe PUBLIC si vous voulez qu’il soit librement accessible. Il y a un exemple d’un tel objet externe dans la démo: module-demo-apis/src/com/simplicite/extobjects/DemoAPIs/DemoAPI2.java at master · simplicitesoftware/module-demo-apis · GitHub
Il y a aussi un test du service pour savoir s’il est UP ou DOWN actullement un “ping” est employé pour cela.
PS : ce sont les valeurs d’un autre projet la cible étant de le reproduire.
Pour l’exposition de l’API c’est ce qui été déjà employer quand je l’ai repris.
Justement c’est le param système qui est utilisé et de ce fait le nom que vous avez mis ne semble pas exister dans le context. Actuellement j’avais essayer de reproduire le comportement de mon autre appli mais si simplicité permet de faire les chose plus efficacement je peux remplacer les procédures déjà mise en place(Autnetification et BDD, les deux autres n’étant pas encore appliqué).
Le param système MAIL_SERVICE ne crée pas un service dans le contexte.
Il contient par contre des settings de configuration équivalents. Si votre besoin c’est d’avoir un tel service de contexte, configurez le dans le context.xml, la présence dans le contexte de java:comp/env/mail/simplicite prendra le pas sur la mécanique liée au param système. Mais je ne vois pas en quoi récupérer les infos dans le param système est un problème
Une bonne manière de tester si la base est UP et les doits d’accès OK c’est de faire un Grant.getSystemAdmin().getSystemParam("VERSION"), c’est typiquement ce que fait notre service ping
Le service de ping fonctionnerai aussi pour savoir si le service de MAIL est UP ?
Car la récupération dans le param système des information est simple ce qui est bloquant c’est le test du status du service de mail, c’est pourquoi on voulais passer par le service et au possible il serait préférable de garder la config actuelle plutôt que de la modifier ce qui pourrait avoir des impact sachant que c’est seullement pour une classe d’écoute.
Pour ce qui est de la base je vais me renseigner sur l’utilisation du service de ping et le remplacé dans le code afin d’utiliser les bonnes méthodes.
Quand c’est configuré en service il y a un moyen de savoir ça ? Si oui, la bonne approche est donc bien d’oublier le param système MAIL_SERVICE et de paramétrer le service dans le context.xml genre:
<Resource
name="mail/simplicite"
type="javax.mail.Session"
auth="Container"
mail.from="..."
mail.transport.protocol="smtp"
mail.smtp.host="..."
mail.smtp.port="..."
...
/>
Avec javax.mail c’était possible (java 8 sur un autre projet)
Jakarta devrait prendre le relais. Pour le context.xml il y en a un dans le serveur tomcat dossier conf et un autre dans le template simplicité dossier META-INF. Dans celui du serveur tomcat ça fonctionnerai, si oui ça pourrais avoir un impact avec le service jdbc définit dans celui qui se trouve dans le template ?
Je parle du context.xml de la webapp (dans webapps/ROOT/META-INF/context.xml). J’ai jamais testé dans le cas d’un service global à Tomcat mais j’imagine que ça peut marcher aussi… Rien de spécifique à Simplicité ici, à voir sur l’aide Tomcat ou les forums relatifs à Tomcat.
Et aucune raison qu’il y ait un effet sur le service database si le nommage est bien respecté.
Finalement on a laissé la définition du service mail dans le MAIL_SERVICE et on a instancié un service mail avec les paramètres du MAIL_SERVICE afin de pouvoir le pinger.
This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.