Re: [Mom4j-dev-l] Fragen zu Properties
Brought to you by:
the_real_grace
Menu
▾
▴
Re: [Mom4j-dev-l] Fragen zu Properties
|
From: Stefan D. <ste...@gm...> - 2003-08-07 15:56:26
|
Hi Torsten, Hm, da hast du Recht. Das mit den Properties ist so eine Sache. Das blöde Object-Property ist mir eh ein Dorn im Auge :-) Wenn der Sender-Client ein Objekt von einer Klasse reinsteckt, welche der Empfäger-Client nicht da hat, dann krachts eh. Wenn man bei der Property den Datentyp mit über die Leitung zum Server und zum nächsten Client schickt, dann wirds halt Schwierig, wenn der Sender ein Java Client und der Empfänger ein Python Client ist. Der Python Client kann mit dem Datentyp des Java-Clients nix anfangen. Da müsste man dann - wenn man die Plattformunabhängigkeit des Kommunikationsprotokolls beibehalten will, plattformunabhängige Datentypen defnieren, die dann der jeweilige Client auf die plattformspezifischen Typen mapped. Z.B. Datentyp java python String java.lang.String string Integer java.lang.Integer int ... > zudem ist > das verhalten von get...Property jetzt nicht spec konform. nicht erlaubte > konvertierungen sollen eine MessageFormatException werfen Meinst du nicht Spec Konform weil evtl. nicht die richtige Exception geworfen wird? Oder meinst du noch was anderes? > Muss oder sollte der Zugriff auf Properties thread safe sein? Nö. Ich habe damals Properties verwendet wegen der abwärtskompatibilität zu JDK 1.1 Ich glaube, das kann man sich jetzt eh schenken :-) Wegen der Konvertierung hast du schon recht: Das ist nicht ganz durchgängig. Wenn an einer neu erzeugten Message ein int property gesetzt wird, landet es als Integer in der Map. Wird die Message gesendet, erfolgt die Konvertierung in einen String. Beim Empfänger landet es erstmal als String in der Map. Erst beim Zugriff auf das Property wird konvertiert. Damit bei einem erneuten Zugriff nicht nochmal konvertiert werden muss, überschreibe ich den String wert mit dem konvertierten Wert. Bei Object-Property ist da natürlich Schluss :-) Den Datentyp mit über die Leitung zu schicken finde ich ok, solange der Datentyp abstrakt bleibt (wegen der Plattformunabhängigkeit). Dann kann man auch bei get Object-Property die richtige Konvertierung machen. Unterstützt ein Client (einer bestimmten Plattform) diesen Datentyp nicht (z.B. gibt es bei Python den Datentyp byte nicht), dann bietet er die Methode get/setByteProperty entweder gar nicht an oder wirft eine Exception wenn er ihn nicht konvertieren kann. Du könntest ja mal einen Vorschlag für so eine Datentyptabelle machen, etwa in der Form: Datentyp (geht über die Leitung) JAVA String java.lang.String Int java.lang.Integer Float java.lang.Float <Custom> <full-qualified-classname> etc. ... und vielleicht gleich eine schönes Utility für die Konvertierung bauen :-) <Custom> heisst, da wird der volle Klassenname reingeschrieben. Das wäre der Fall, wo einer ein Object-Property wo der Typ Anwendungsspezifisch ist. Ich erweitere dann die Tabelle um die Python Datentypen (sofern sie in Python existieren). Die Tabelle wandert dann gleich in die Dokumentation. Was die Konvertierung angeht, da bin ich leidenschaftslos. Ob on demand oder immer. Da musst du entscheiden, was für die Implementierung der Message-Klassen am sinnvollsten ist. ciao Stefan > nochmal ich, > > habe inzwischen die known_issues bzgl. Properties gelesen ;-) ich denke es > wäre sinnvoll die properties auf der empfängerseite zu konvertieren. klar, > dann muss man den property typ mitschicken, das sollte aber kein großes > problem sein, oder?. jetzt liefert die getObjectProperty methode immer ein > String zurück, egal was auf Senderseite reingesteckt wurde. Das macht es > schwer mit properties generisch umzugehen. der empfänger muss bei der > jetzigen implementierung immer wissen, welche properties von welchem typ > sind um die richtige get...Property Methode aufrufen zu können. zudem ist > das verhalten von get...Property jetzt nicht spec konform. nicht erlaubte > konvertierungen sollen eine MessageFormatException werfen. jetzt würden > sie wahrscheinlich eine FormatException oder so was ähnliches werfen(?). > > ciao > torsten > > > Hi Stefan, > > > > ich habe noch ein paar Fragen zu MessageProperties. > > > > Muss oder sollte der Zugriff auf Properties thread safe sein? Du > > verwendest intern ein Properties Object um die Properties zu speichern. > > Der Zugriff ist also thread safe. Ist das nicht nötig, könnte man auch > > eine HashMap nehmen? > > > > Falls eine get..Property Methode auf einen Wert zugreift, der als String > > gespeichert wurde, konvertierst Du den String und speicherst > > gleichzeitig den konvertierten Wert wieder in den Properties. > > Könnte man nicht einfach den konvertierten Wert nicht speichern und bei > > jedem Zugriff konvertieren? Oder beim Zusammenbauen der Message auf der > > Empfänger Seite (hab' ich mir noch nicht angeschaut) konvertieren? > > > > Ich glaube dann wäre es einfacher die Konvertierung in eigene Methoden > > auszulagern und bei der MapMessage wieder zu verwenden. > > > > Ciao > > Torsten > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are available now. > > Download today and enter to win an XBOX or Visual Studio .NET. > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > _______________________________________________ > > Mom4j-dev-l mailing list > > Mom...@li... > > https://lists.sourceforge.net/lists/listinfo/mom4j-dev-l > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Mom4j-dev-l mailing list > Mom...@li... > https://lists.sourceforge.net/lists/listinfo/mom4j-dev-l > -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post |