eigene TypeSerializer in UniversalSerializer

[manfrede]

Habe soeben versucht einen den UniversalSerializer zu wrappen um eigene Types zu serialisieren.

Code: Select all

public class ExtendedUniversalSerializer implements ISerializer {

  private UniversalSerializer wrappedSerializer;
 
  public ExtendedUniversalSerializer(){
    wrappedSerializer = new UniversalSerializer();
    wrappedSerializer.registerTypeSerializer(new SQLExceptionSerializer());
  }
 
  @Override
  public Object read(DataInputStream pIn) throws Exception {
    return wrappedSerializer.read(pIn);
  }

  @Override
  public void write(DataOutputStream pOut, Object pObject) throws Exception {
    wrappedSerializer.write(pOut, pObject);
  }

}


Habe zuvor nur kurz mal einen Blick in den UniversalSerializer geworfen und gesehen, dass prinzipiell 256 TypeSerializer Platz haben sollten.

Code: Select all

private ITypeSerializer[] deserializerTypes = new ITypeSerializer[256];

Dann kamen noch Ranges dazu, auch gut, schließlich kann man ja noch spezifizieren.

Für meinen eigenen Serializer aber dann noch Platz zu finden hat sich dann aber dann doch schwierig gestaltet, da anscheinend der StringSerializer ziemlich gierig ist.

Code: Select all

/** min. byte value of <code>String</code> type. */
private static final int TYPE_STRING_MIN = 99;

/** max. byte value of <code>String</code> type. */
private static final int TYPE_STRING_MAX = 255;

Hier mal eine Liste aller Ranges die ich gefunden habe:

0 null
1 byte
2 char
3-4 bool
5-6 float
7-8 double
9-10 short
11-12 int
13-14 long
18-19 date
30-32 bytearray
33-35 intarray
36-38 chararray
39-41 array
42-44 list
45-47 map
48-52 beantype
53-55 boolarray
56-58 floatarray
59-61 doublearray
62-64 shortarray
65-67 longarray
68 object
69 throwable
70 bean
71 enum
72 xmlnode
79-98 bigdecimal
99-255 string

Da wirds dann doch schon ziemlich eng.

Hier also meine Frage: Gibts die Möglichkeit den UniversalSerializer in einer Art aufzublasen, sodass eine Range für kundenspezifische Anpassungen übrig bleibt, die in Zukunft auch von Hersteller Seite nicht angetastet wird?

[Development@SIB]

Im Moment sind noch 19 Slots frei. Das sollte in jedem Fall ausreichen.
Es gibt dafür aber keine Garantie das diese auch frei bleiben. Der Serializer wurde zwar schon sehr lange nicht mehr erweitert, aber natürlich wäre das möglich.

Nachdem der Serializer auch eher zu den Klassen gehört die von Entwicklern nahezu gar nicht angepasst werden, wurde für die perfekte Erweiterbarkeit kein Mehraufwand betrieben.

Unser Ansatz war, das es jederzeit möglich sein soll, einen eigenen Serializer zu entwickeln, z.B. könnte Hessian verwendet werden.

Aber worum geht es eigentlich? Der UniversalSerializer behandelt bereits die meisten Objekttypen.
Es ist zB. einfach möglich, den ThrowableSerializer zu erweitern anstatt einen eigenen pro Exception Klasse zu schreiben?
Weiters können ListSerializer oder ObjectSerializer erweitert werden.

Also im Prinzip deckt der UniversalSerializer mit den TypeSerializern die meisten Objekttypen ab und durch Ableitung können eigene Klassen verwendet werden?

Es macht absolut keinen Sinn, einen Serializer pro Klasse zu erstellen. Das erzeugt lediglich unnötig viel Source Code.

[manfrede]

So, dann eben nochmal konkreter:

SQLExceptions treten auf, das ist Fakt. Sei es durch Fehler seitens der JVx Implementierung oder durch Fehler auf der Datenbank was weis ich aber sie treten auf. Der aktuelle Serializer nimmt die Felder für sqlstate und vendorcode nicht auf, das ist auch Fakt.

Ich habe nun die Aufgabe den Fehlercode bis in den Client durchzuschleusen um konkret darauf zu reagieren.

Was ist also bitte der Weg des geringsten Widerstandes? Es gibt einen UniversalSerializer der wunderbar funktioniert. Warum sollte ich mir selbst einen schreiben und Gefahr laufen, dass dieser mit JVx nicht harmonisiert? Ich will schließlich nicht allzuweit vom Standard abweichen.

Es macht absolut keinen Sinn, einen Serializer pro Klasse zu erstellen. Das erzeugt lediglich unnötig viel Source Code.

Aber einen bestehenden zu erweitern oder gleich ein neues Framework mit zig Klassen einzuführen machts besser?

Es gibt dafür aber keine Garantie das diese auch frei bleiben.

Genau darum geht es mir doch. Ich bin mit der momentanen Lösung zufrieden, möchte jedoch nicht in 3 Releases in diesen Fehler fallen.

[Development@SIB]

Unser Support ist immer bemüht die bestmögliche Antwort zu finden. Wenn Sie eine spezifische Antwort wollen, dann wäre eine spezifische Frage auch sicher hilfreich. Bei JVx handelt es sich nach wie vor um ein OpenSource Projekt!

Es wurde Ihnen nicht geraten einen eigenen Serializer zu implementieren, lediglich das es so angedacht war für den Fall, wenn der Standard Serializer nicht ausreicht. Wir können Ihnen keine Garantie geben das die Slots frei bleiben. Es gibt eben keine "Erweiterungs API" die das ermöglicht, weil es nicht so programmiert wurde. Sprich wenn Sie eine Klasse ableiten und erweitern, dann müssen Sie schon bei Aktualisierungen selbst prüfen ob Ihr Code noch funktioniert (im Changelog sind Infos zu Änderungen zu finden).

Sie können jedoch gerne ein Ticket eröffnen oder selbst den Code beisteuern um Ihre Anforderungen zu ermöglichen?

Es gibt für die Lösung Ihres Problems mehrere Ansätze:

Eine SQLException könnte auch dort abgefangen werden wo sie auftritt (am Server) und dementsprechend könnte dann entweder eine eigene Exception geworfen werden oder die Fehlerbehandlung am Server ist ausreichend.

DBAccess wirft SQLExceptions zB bei executeFunction, sprich bei gezielten Aufrufen gegen die DB. Diese Funktionalität wird in ihrem LCO gewrapped un könnte dort auch behandelt werden.

Wenn Sie SQLException zum Client serialisieren wollen, dann müssen Sie lediglich den ThrowableSerializer ableiten, anpassen und den eigenen zB. CustomThrowableSerializer registrieren.

[manfrede]

Es gibt eben keine "Erweiterungs API" die das ermöglicht, weil es nicht so programmiert wurde.

Es war nie die Frage ob es eine Erweiterungs API gibt, sondern ob es in Zukunft eine geben wird. Siehe letzter Absatz , originaler Post.

Sie können jedoch gerne ein Ticket eröffnen...

Das habe ich mit FS#1767 versucht und bin kläglich gescheitert.

Wenn Sie eine spezifische Antwort wollen, dann wäre eine spezifische Frage auch sicher hilfreich

Nochmal, siehe letzter Absatz, originaler Post.

DBAccess wirft SQLExceptions zB bei executeFunction, sprich bei gezielten Aufrufen gegen die DB.

SQLExceptions werden kreuz und quer geworfen, jedoch neu verpackt in DataSourceExceptions. Zusätzlich wird dort vorsätzlich die SQLException ohne sqlstate und vendorcode jedoch mit neuerer message neu verpackt. Vermutlich genau deshalb, weil diese Info mit den bisherigen Serializern nicht zum Client durchdringen konnte. Aber das ist eine andere Baustelle.

Nochmal, es gibt Objekte im Standard JRE bzw. aus 3rd Party Frameworks die mit dem normalen BeanSerializer nicht 1:1 serialisiert werden können. SQLException war ein konkretes Beispiel. Ich habe noch mehrere z.B. aus dem JasperReports Umfeld. Alle Objekte in serialisierbare Objekte einzupacken finde ich nicht erstrebenswert (solange es ich vermeiden kann). Also habe ich mir also gedacht, JVx würde davon profitieren, wenn es für seinen UniversalSerializer die Möglichkeit anbietet eigene TypeSerializer zu erstellen.
Bestehende Serializer zu erweitern und mit If-Else switches zu arbeiten finde ich persönlich unsauber.

Aber gut, die Antwort auf die Frage, ob es in Zukunft eine "Erweiterungs API" geben wird habe ich durch das Ticket eigentlich schon erhalten. Ich werde mich anderweitig umsehen. Trotzdem vielen Dank!

[Development@SIB]

Das Ticket haben Sie selbst geschlossen bzw. den Close Request angefordert. Sie sind damit nicht gescheitert sondern wollten das Feature nicht mehr.

Sie können jederzeit den ObjecSerializer ableiten und beliebige Objekte wie auch immer sie das wollen serialisieren.

Korrekt, Java hat eine Menge libs usw. Aber warum bitte wollen Sie alle Objekte immer zwischen Client und Server austauschen. Es macht absolut keinen Sinn alle Server libs am Client bereitzustellen. Das macht die Applikation größer und den Client nicht besser. Mit JVx werden üblicherweise Multi-Tier Applikationen erstellt, da sollte tunlichst auf eine Trennung der Logik geachtet werden.

Empfehlung: Am Server die Exceptions behandeln und zum Client nur relevante Infos/Exceptions/Objerkte/Beans schicken.

Das irgendetwas vorsätzlich gemacht wird ist schlichtweg nicht richtig! Sie hätten auch jederzeit ein Ticket öffnen können das besagt das SQLException nicht vollständig übertragen wird.

Bei JVx handelt es sich um ein OpenSource Projekt und wenn Sie mit der Funktionalität nicht zufrieden sind, besteht die Möglichkeit diese Funktionalität selbst bereitzustellen oder sich an der Entwicklung des Projektes zu beteiligen.

[manfrede]

Das Ticket FS#1767 wurde durch rjahn mit der Begründung "Won't implement" implement geschlossen, ich habe das nicht angefordert! Ich habe mich lediglich mit einem Workaround zufriedengegeben bis es eine saubere Lösung gibt.

[rjahn]

Stimmt.

Es wurde geschlossen, weil es im Prinzip schon jetzt eine saubere Lösung gibt. Die Slots sind für die Objekttypen gedacht. Somit gibt es nicht pro Klasse einen Slot sondern pro Typ. Alles andere wäre ja zu viel Aufwand und wir wären wohl noch immer nicht fertig mit der Implementierung.

z.B.
Throwable ist ein Typ
List ist ein Type
usw.

Am Ende werden die nicht spezifisch behandelten Typen durch den Object Type behandelt. Eine simple Ableitung der vorhandenen Type Serializer ist also ausreichend um Erweiertungen vorzunehmen.

Es könnte aber durchaus mal passieren das Type Serializer notwendig werden (wobei das in den letzten Jahren nicht der Fall war). Die freien Slots können dafür verwendet werden, aber ja - es gibt kein API um einfach einen Type Serializer in einen freien Slot einzuhängen... Wir können dieses Feature gerne ins Ticket System eintragen.
Aber das Feature um zB via xml die Serializer zu konfigurieren, davon halte ich persönlich nicht viel. Man braucht das Feature zu selten und dann würde Code mitgeschleppt werden der auch gewartet werden muss usw.

Sauber und nicht sauber liegt immer im Auge des Betrachters und wofür etwas entwickelt wurde.