J'essaie d'envoyer des objets à partir de faisceaux via un ensemble de communication dédié vers un autre cadre. Pour la communication, j'utilise la sérialisation standard Java (avec ObjectStreams) sur TCP/IP.Désérialisation de tableaux de type personnalisé dans OSGi
Le flux de communication est le suivant: Un expéditeur-faisceau transmettra des objets sérialisables à un expéditeur de transmission qui sérialisera les objets et les enverra via TCP/IP à un transmetteur-récepteur. Le récepteur va ensuite désérialiser les objets reçus et les transmettre au récepteur. Comme l'architecture de chargement de classe OSGi est différente de l'architecture native, je dois faire un peu de bidouille avec le classloader: Comme je suppose que le récepteur-bundle doit connaître les classes qu'il reçoit (= les a-t-il importées ou autrement accessibles? par son chargeur de classe), j'utilise le chargeur de classe du récepteur au lieu du transmetteur-récepteur pour charger la classe. (Via la méthode Bundle.loadClass (..)). Cela fonctionne très bien pour les classes personnalisées, mais cela ne fonctionne pas pour les tableaux de types personnalisés. (qui ne sont pas connus du classloader d'émission-réception, mais au récepteur faisceau.)
Edit: ObjectInputStream.readObject (...) jette un ClassNotFoundException, si elle essaie de désérialiser un tableau. (Je suppose que cette exception provient de la méthode Bundle.loadClass (...) du récepteur-bundle.)
Il fonctionne avec java.util.List ou d'autres classes Serializable. Il fonctionne également pour les types personnalisés qui contiennent des champs d'autres types personnalisés tant qu'ils ne sont pas des tableaux. Donc la question est: Y a-t-il une différence dans la façon dont les tableaux sont de/sérialisés? Ou sont-ils chargés différemment?
C'est vrai, nous sommes en cours d'exécution dans ce bug ici .... une solution de contournement que nous avons essayé est en utilisant Dynamic-Import. Cependant, actuellement, nous évitons simplement d'utiliser des tableaux. – Arvodan