2010-04-01 12 views
1

Nous utilisons JMX pour la communication entre différents fichiers EAR sur le même serveur d'applications Websphere (6.1). Tout fonctionne bien si nous utilisons uniquement des types Java comme arguments, mais si nous utilisons nos propres classes comme arguments, le problème est que nous obtenons des ClassCastExceptions du côté du récepteur. C'est évidemment un problème de classloader: si le jar avec les types d'arguments est placé dans le répertoire JRE endossé, de sorte que tous les classloaders utilisent exactement la même classe, les exceptions disparaissent. Mais nous préférerions de beaucoup placer la bibliothèque qui définit les types d'arguments dans le fichier EAR lui-même. Maintenant, ma question: y at-il un truc pour persuader WAS de sérialiser et de désérialiser les arguments lors de l'appel JMX je suppose que dans ce cas, la ClassCastException disparaîtrait.Comment éviter ClassCastException dans les appels JMX avec des arguments complexes sur Websphere appserver

Répondre

0

Vous avez raison de dire qu'il s'agit d'un problème de chargeur de classe et que le fait de passer des objets sérialisés en tant qu'arguments d'appel JMX évite le problème. Mais vous pourriez payer une pénalité de performance significative. La sérialisation/désérialisation des objets n'est pas bon marché.

+0

Droite. Mais ma question était: comment persuader WAS d'utiliser la sérialisation lors de l'exécution d'un appel JMX? Il semble juste les passer par référence, ce qui cause des problèmes ici. –

+0

Sérialisez vous-même les arguments à la main et transmettez-les comme des tableaux d'octets? –