✔ Object-Serialization Problemchen

[mccae]

Huhu,

Ich bin vor kurzem auf ein Problemchen gestoßen und bitte um eure Hilfe.

Folgendes Szenario:

Applikation lädt über den Object-input-stream ein Objekt welches das "Language" Interface implementiert.

Dies funktioniert auch, solange die Klasse welche das Interface implementiert zu finden ist.

Ist sie aber nicht, da ja das Objekt nur über die Implementiertung des Language Interfaces angesprochen werden soll....

Ich bekomme ClassNotFound - Fehler wenn ich versuche ein solches Objekt zu deserialisieren.

Language extlang = (Language) ((SealedObject) Zahlenzauberer.deCryptObject(ois.readObject(), "Mr.Blowfish"));

Wenn jetzt die Klasse die das Language-Interface implementiert nicht da ist (wie denn auch - sie stammt von einem fremden Computer), dann wird wie bereits gesagt ne ClassNotFoundException geworfen.

Gibt es jetzt eine Möglichkeit ohne viel drumherum an das Objekt zu kommen(welches das Language Interface implementiert)?

Irgendwie stehe ich auf der Leitung,...

Wird es in Richtung "Class" - Klasse wärmer?

 

[kabel2]

Wie solls auch anders funktionieren? Was sollte denn rauskommen, wenn ein extlang.getClass() abgesetzt wird?

Von http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectInputStream.html

ObjectInputStream ensures that the types of all objects in the graph created from the stream match the classes present in the Java Virtual Machine. Classes are loaded as required using the standard mechanisms.

Vielleicht geht da was mit einem ClassLoader, der von extern die benötigten Klassen nachlädt, oder der Stream enthält die Klassen als byte[], und irgendwer macht ein #defineClass(). Oder ein Proxy, der auf Client-Seite das Language interface implementiert und dann (wie auch immer) an den Server funkt.

Entweder der Prophet geht zum Berg, oder der Berg kommt zum Propheten ;-)

 

[mccae]

Wie solls auch anders funktionieren? Was sollte denn rauskommen, wenn ein extlang.getClass() abgesetzt wird?

Von http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectInputStream.html


Vielleicht geht da was mit einem ClassLoader, der von extern die benötigten Klassen nachlädt, oder der Stream enthält die Klassen als byte[], und irgendwer macht ein #defineClass(). Oder ein Proxy, der auf Client-Seite das Language interface implementiert und dann (wie auch immer) an den Server funkt.

Entweder der Prophet geht zum Berg, oder der Berg kommt zum Propheten ;-)

Huhu, es handelt sich hierbei nicht um ein Client / Server szenario...

Es soll Usern möglich sein ihre eigenen "Languages" zu erstellen indem sie das Interface implementieren, und die nach bestimmten Muster verschlüsselte Datei in einen entsprechenden folder dumpen.

Ich möchte auch keine JARs oder so nachladen, da die obige Methode explizit vorgegeben wird.

Kompiliert wird das ganze dann in der Firma mit so ner mysteriösen "Aus Java mach C/C++ mit ausgekoppeltem ,custom JRE" - Applikation, bla bla bla.

Ich könnt ja auch eine Klasse vorgeben die für User vorhanden wäre, und deren serialisierte Kumpels nachladen.

Das ist aber nicht die "Aufgabenstellung" -___-

Ich muss jetzt einen Weg finden, beide Seiten glücklich zu machen

 

[Thomas Darimont]

Hallo,

stellt die Language Klasse nur Daten oder auch Verhalten zur Verfügung? Wenns nur Daten sind, sprich dein Objekt ein reines Transfer-Objekt darstellt könntest du einfach generische Proxies bzw. Hashmaps rausserialisieren.

Siehe:
http://www.tutorials.de/forum/java/250691-dynamisch-zur-laufzeit-getypte-modelle-erzeugen.html

Wenn du dann die Anwendungslogik als Skript ablegen würdest: http://www.tutorials.de/forum/java/...ht-anpassbaren-anwendungen-mit-scripting.html
könntest du diese auch einfach als String serialisieren.


Gruß Tom

 

[mccae]

Hallo,

stellt die Language Klasse nur Daten oder auch Verhalten zur Verfügung? Wenns nur Daten sind, sprich dein Objekt ein reines Transfer-Objekt darstellt könntest du einfach generische Proxies bzw. Hashmaps rausserialisieren.

Siehe:
Dynamisch zur Laufzeit getypte Modelle erzeugen.

Wenn du dann die Anwendungslogik als Skript ablegen würdest: Beispiel zu leicht anpassbaren Anwendungen mit Scripting
könntest du diese auch einfach als String serialisieren.


Gruß Tom

Huhu, das Interface sieht so aus:

package ***.praktikum.iST.lang;

import java.io.Serializable;

/**
 *
 * Das Language Interface wird von iST dazu benutzt lokalisierte Inhalte anzuzeigen.<br>
 * Dynamisch nachgeladene Klassen muessen das Language Interface implementieren damit sie als Sprache gelten.<p>
 *
 * <i>HINWEIS: Die Sprachen die dynamisch nachgeladen werden muessen zuvor mit dem LanguageCreator erstelltworden sein</i><br>
 * <i>Grund: Die Sprachen werden zusaetzlich verschluesselt und dann erst auf der Festplatte abgespeichert!</i>
 *
 *
 * @author mccae
 * @version v1.0.0
 *
 */
public interface Language{
   
    /**
     * Die Klasse die das Interface implementiert sollte durch diese Methode den Namen der Sprache zurueckgeben<p>
     *
     * Ist der Name laenger als 20 Zeichen, wird er von iST getrimmt<p>
     *
     * <i>Zum Beispiel: English, German, Thai, Hebrew, 1337</i>
     *
     * @return Den Namen der Sprache
     */
    public String getName();
   
    /**
     * Alle Klassen die dieses Interface implementieren sollten ueber diese Methode die Uebersetzungen liefern<br>
     * Es liegt am Klassenersteller alles intern abzuspeichern.<p>
     *
     * <i>Beispiel: Applikation fordert ID "MAINFRAME_STARTBTN_LABEL".<br>
     * Rueckgegeben werden soll natuerlich der zur ID gehoerende Text.<br>
     * Dieser ware in diesem Fall: "Start"</i>
     *
     * @param id Die Localization ID
     * @return Der zur ID gehoerige Text.
     */
    public String getString(String id);
   
}

Eigentlich wird nur eine HashMap zur Verfügung gestellt,...

Der Thread auf den dein Link zeigt, macht mir Angst. (Man wird von Code erschlagen).

Werd' ich mir mal in nächster Zeit reinziehen,

Danke,

 

[kabel2]

Aha. Also ab in eine HashMap mit dem Zeug und rüber. HashMaps gibts hoffentlich auf beiden Seiten?!
Es gibt da noch so was nettes wie ein Memento, das die Details der Serialisierung verbirgt, dem Implementierer aber dennoch die Kontrolle läßt.