Sérialisation, Transient et ObjectOutputStream

Bonjour,

Je souhaiterai un peu d'aide avec un problème sur lequel je bloque depuis 2 jours...
Alors voilà, mon projet est la création d'une servlet qui fera office de pool de connections Essbase. J'ai donc dévellopé une classe qui permet de request une session à la servlet qui s'occupera de la créer.

Le truc c'est qu'avec la JAPI Essbase, la connection créé est un objet que je dois renvoyer à la classe client pour qu'elle puisse l'utiliser (Cela permet de ne pas divulguer de mots de passes). Je ne peux donc modifier le code source de cet objet généré par la JAPI.

Mon problème est que pour renvoyer cet objet obtenu par la servlet, je dois le sérialiser pour pouvoir l'envoyer par une méthode POST. J'utilise donc Xstream sans trop de soucis pour l'envoyer. J'obtient donc ce que je voulais : mon objet de connection dans ma classe client.. Mais oh surprise, l'objet n'est plus valide ! Alors je décompile la JAPI pour voir ce qui n'était pas sérialisé, et je trouve 5 fields qui sont noté en "transient" et qui par conséquent ne sont pas sérialisés.

Donc ma question est : comment forcer la sérialisation des champs noté transient par Xstream ou équivalent... ? sachant que je ne peux pas modifier la classe objet et donc je ne peux pas initialiser l'objet avec un ReadResolve()

Merci d'avance !

Il n'y a rien de surprenant à ce qu'un objet de ce genre ne puisse pas être sérialisé... Les applications ne peuvent pas se passer des objets Connection ou ce genre d'états internes les unes aux autres.

Si ta servlet crée les connections, alors c'est elle qui les utilise. Les autres doivent passer par ta servlet pour s'en servir.
Rien ne t'empêche de créer par un exemple un objet PseudoConnection qui consiste en fait à contacter ta servlet pour qu'elle utilise une de ses connexions pour faire la requête correspondante.

Merci pour la rapidité de la réponse,

J'ai déjà envisagé cette solution mais le problème c'est que les requetes sont bien trop grosses et il y en a plusieurs dizaines par minutes, donc beaucoup trop de requetes HTTP pour la servlet et beaucoup trop lent...

Il n'y aurai t-il pas moyen de modifier le code source de Xstream pour lui faire ignorer les annotations transient ?

ou existe t-il un autre moyen de passer un objet entre une servlet et une classe/applet/jsp autre que POST ou HTTP ? peut etre de façon binaire ?

Citation:

---

Envoyé par Ethan0026

Il n'y aurai t-il pas moyen de modifier le code source de Xstream pour lui faire ignorer les annotations transient ?

ou existe t-il un autre moyen de passer un objet entre une servlet et une classe/applet/jsp autre que POST ou HTTP ? peut etre de façon binaire ?

---

La représentation binaire de l'objet serait correctement passée, mais elle n'aurait aucun sens en dehors de l'application qui l'a créée. Entre autre, il serait fondamentalement incapable de communiquer avec la base.

Si vraiment tu ne peux pas passer par un proxy, alors tu dois te passer d'un pool de connexion centralisé. À quoi sert-il d'ailleurs ? Au pire, tu peux toujours en faire un agent d'information à qui tout le monde dit quand il ouvre et ferme une connexion, ce qui lui permet d'indiquer combien de connexions sont ouvertes, et si il est acceptable d'en ouvrir une autre tout de suite.

Citation:

---

Envoyé par Ethan0026

Le truc c'est qu'avec la JAPI Essbase, la connection créé est un objet que je dois renvoyer à la classe client pour qu'elle puisse l'utiliser (Cela permet de ne pas divulguer de mots de passes). Je ne peux donc modifier le code source de cet objet généré par la JAPI.

---

J'ai du mal à voir en quoi créer l'objet côté serveur pour l'envoyer côté client résout un problème de divulgation de mot de passe : l'objet va de toute façon contenir des informations de connection ... et au pire, s'il est très light, la connection est liée à la machine hôte, et donc serait refusée par la base si on l'ouvrait côté serveur et qu'on essayait de la reprendre côté client, non ?

La servlet devrait pouvoir servir de proxy, sinon ça revient à laisser les clés aux clients. Auquel cas, pourquoi s'embêter à ne pas leur envoyer les ids de connection (quitte à chiffrer ça un minimum) ...