Hello,
Since some time we use the Hessian protocol for Java and C++ successfully, but
I observed some important key definitions are IMO incompletely specified which
has relevant implications on current implementations, e.g. the hessian-3.1.3
implementation of caucho.com. In the following I restrict on the version 1.0.2
definition of the hessian protocol.
1) It seems unspecified whether the Hessian map type is supposed to accept
unique keys or possibly multiple equivalent keys (A multi_map in C++
nomenclature).
This has consequences during object persistence, because objects in typical
higher programming languages *are* multimap containers in case of base-derived
hierachies. I stumbled across this issue when I tried to read an object of type
org.springframework.core.NestedRuntimeException
which derives from java.lang.RuntimeException. The derived class
NestedRuntimeException legally (according to language rules of Java) contains
two
data members "cause" (Throwable):
- One from the derived class NestedRuntimeException
- The second one from it's base class java.lang.Throwable.
While the caucho implementation seems to persist the object map of
NestedRuntimeException loss-free (with two occurrences of the key "cause"),
the HessianInput(2) classes do simply override any multiple occurrence of
keys. Of course, loss-free persistence of object maps has it's own problems,
because during object read there exist ambiguities which member (of duplicate
name) belongs to which value.
This essentially means that the hessian protocol *cannot* generally
persist arbitrary object types - it's has the implicit assumption that class
hierachies don't use replicated member names between their class hierachies -
which is actually a bitter source of hard-to-find bugs during object
persistence!
IMO the only safe solution of this problem is that class hierachies are
supposed to store each of it's base classes in a separate object map (each
one only supporting unique keys).
2) It also seems unspecified, to which semantic data type the 16 bit
length specifiers (typically annotated as "b16 b8") belong to. Are these signed
or
unsigned types? Since there does not exist a fundamental 16 bit type in
the hessian standard, this question remains unanswered and has also some
implications for existing implementations. The above mentioned caucho
implementation persists data chunks ('s', 'x', 'b') with size 0x8000. This
number would be too large to be reasonably read as a 16 bit signed number
(which would have a maximum positive value of 0x7fff), and thus implies
an unsigned interpretation. On the other hand - given an unsigned
interpretation -
one could reasonably argue that chunk sizes of 0xFFFF should also be ok.
This point must be clarified.
Greetings from Bremen,
Daniel Krügler
Bruker Daltonik GmbH
------------------------------
Fahrenheitstrasse 4
28359 Bremen, Germany
Permoserstrasse 15
04318 Leipzig, Germany
Geschäftsführer: Frank Laukien, Ph. D., Gerd Hülso, Sebastian Meyer-Plath,
Stefan Ruge, Ian Sanders, Ph. D., Dr. Michael Schubert
Sitz der Gesellschaft: Bremen
Handelsregister Amtsgericht Bremen: HRB 8150
www.bdal.de
------------------------------------------------------------
Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich für die
ordnungsgemäße, vollständige und verzögerungsfreie Übertragung der Nachricht.
Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch
einen Brief oder ein Fax entsprechend bestätigt wird.
Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to
the correct, complete and immediate transmission of the message shall be
excluded. The content of the e-mail including its attachments is only legally
binding if confirmed by Bruker Daltonik GmbH by letter or fax.
_______________________________________________
hessian-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/hessian-interest
