Communication entre webapps

Bonjour,

J'ai 2 applications sur un serveur Tomcat et elles requièrent une authentification via un realm (en SSO).

Je cherche "simplement" à accéder à une servlet de mon appli A (qui retourne du code json) à partir d'une servlet de mon appli B.

J'ai essayé le code suivant (sur appli B):

Code:

---

1 2 3 4 5

String params = "param1=value1&param2=value2"; URL calendarServlet = new URL("http://localhost:8080/appliA/calendar.json?"+params); URLConnection calendarConnection = calendarServlet.openConnection(); String calendarJsonString = convertStreamToString(calendarConnection.getInputStream());

---

Le pb est que du fait de la sécurisation du contexte, je reçois le code HTML du formulaire d'authentification et non le code JSON souhaité.
J'en déduit que l'utilisation de la classe URLConnection fait "perdre" la notion SSO.

Je voulais savoir si il existe d'autres façon de se connecter à des applications sans perdre ces données.

Merci d'avance

Manu

Re-salut,

N'ayant pas de réponse j'ai continué mes recherches, j'ai avancé mais je bloque à nouveau. Voici mon nouveau code :

Code:

---

1 2 3 4 5 6 7 8 9 10

ServletContext calendarContext = getServletContext().getContext("/appliA"); URL test = calendarContext.getResource("/index.js"); System.out.println(test);   URL url = calendarContext.getResource("/calendar.json?"+params); System.out.println(url);   URLConnection calendarConnection = test.openConnection(); String calendarJsonString = convertStreamToString(calendarConnection.getInputStream());

---

me retourne

Code:

---

1 2	jndi:/localhost/core/index.js null

---

Alors le fichier /index.js existe physiquement et je m'y connecte sans aucun pb (l'authentification passe sans pb), je récupère le source du fichier dans ma variable calendarJsonString, tout va bien. Par contre, en ce qui concerne ma servlet /calendar.json, elle existe, est correctement mappée, fonctionne ... mais lorsque je tente d'y accéder, calendarContext.getResource me retourne null, et je n'ai pas trouvé de doc là dessus qui m'aide.

Si ça inspire qqu'un ça m'enlèverait une belle épine du pied.

Merci d'avance

Edit: Je n'ai pas précisé mais je travaille sur Tomcat 6.0.20

les paramètres (?.....) ne font pas partie du nom de la servlet et doivent etre retirés. Oui l'utilisation de la classe URL perd le SSO, le SSO est quelque chose qui concerne le navigateur, pas ton code java. Est-il inenvisageable de simplement laisser le navigateur récupérer le contenu de ce servlet? Avec de l'ajax par exemple?

Citation:

---

les paramètres (?.....) ne font pas partie du nom de la servlet et doivent etre retirés.

---

Même sans les paramètres ça me retourne null (j'ai à peu près tout essayé, avec et sans le "/", les paramètres ... tjs null)

Citation:

---

Est-il inenvisageable de simplement laisser le navigateur récupérer le contenu de ce servlet? Avec de l'ajax par exemple?

---

C'est ce que j'ai fait en ne trouvant pas de réponse, et ça fonctionne très bien. Par contre ça implique que je dois passer le résultat de ma requête Ajax en tant que paramètre à ma servlet à chaque fois que j'en ai besoin. J'aurais aimé des servlet plus "autonomes" et je pensais que l'on pouvait garder cette notion de contexte/authentification dans les servlet.

Si tu connais un autre moyen pour échanger des infos entre applications web (avec SSO) ... on sait jamais.

Merci

le SSO n'a pas pour but d'échanger des données entre webapps. Pour l'échange entre servelt, ca ne pose aucun soucis, si ces servlet sont dans la meme webapp, ce qui n'est pas ton cas.
Ensuite, j'aurais plutot pensé laisser la page "résultat" de la servlet aller cherche ses donnée json, pas la page demandeuse de la servlet. Tout dépend bien sur de pourquoi tu as besoin de ces données....

Re,

En fait, dans le cas présent, mon application "A" contient les dates des jours non ouvrés et la "B" génère des rapports pour faire simple.
La servlet de l'appli "B" génère donc un rapport et pour créer celui-ci j'ai besoin de connaître les jours ouvrés/non ouvrés.
Je voulais juste passer à ma servlet les paramètres pour créer le rapport et qu'elle se charge de récupérer les "autres" infos qui n'intéressent pas l'utilisateur final (dont les dates).

C'est un premier cas d'utilisation, et j'aurais voulu centraliser certaines informations dans une seule appli pour ne pas avoir à faire de la réplication sur les autres.

Je pensais donc exposer des servlets sur mon appli "A" qui retournent du json pour faire simple et y accéder à partir de mes autres appli tout en tenant compte que les informations ne sont accessibles que par un user authentifié (et autorisé - dans le cas des jours fériés on s'en fout un peu mais ça peut me servir pour d'autres infos plus sensibles)

Comme ça tu sais tout!

Merci

regroupe tes application, c'est plus simple. La deuxième dépendant fortement des données de la première, il n'y a pas de raison de les séparer, je pense.

Re-salut,

Pour terminer le post, je voudrais centraliser les informations partagées entre plusieurs applications dans une seule fin de faciliter la mise à jour et la gestion de ces informations partagées.
Saisir les jours fériés (c'est un exemple parmi d'autres) dans chaque application (j'en ai au moins 3) et les maintenir à jour n'est certes pas très compliqué mais d'en d'autres cas, la maintenance peut s'avérer lourde et des risques de fautes et/ou d'oublis de saisie ne sont pas négligeables (sans parler de la perte de temps due à la saisie).
Tout ça pour dire que je n'ai pas trouvé de solution à mon problème que je ne pensais pas si "particulier" que ça, mais vu le nombre de pistes trouvées sur Google (0) je commence à désespérer.

Si je trouve un moyen de contourner ce pb, je vous tiens au courant.

Merci et je suis tjs à l'écoute de nouvelles pistes.

généralement quand on veux synchroniser en restant séparé, on utilise une base de donnée commune aux deux application, tout simplement.

Bonjour
Tu pourrais communiquer entre servlet via SAX. Pour ma part je fait des màj d'appli (bdd) via cette solution sans pb. Class et servlet communiquent et tout est transparent.