Introduce message flavor to distinguish serialized message bytes.

[boaks]

Message caches already serialized bytes. But, though the serialization
is depending on TCP or UDP flavor, this caching may fail. Introducing a
message flavor and check the flavor prior using the cached bytes fixes
possible resulting issues.

Signed-off-by: Achim Kraus achim.kraus@bosch-si.com

[sophokles73]

What issues are you anticipating? Since we an Endpoint always either has a TCP or a UDP stack, IMHO there should not be any confusion regarding the serialization format of a message being referenced in any of the stacks, it is either TCP or UDP but there will not be both types being processed in one stack.
Or am I missing something?

[boaks]

Californium: InMemoryObservationStore
Leshan: InMemoryLwM2mObservationStore

private static final DataSerializer serializer = new UdpDataSerializer();

RawData serialize = serializer.serializeRequest(obs.getRequest(), null);
DataParser parser = new UdpDataParser();
Request newRequest = (Request) parser.parseMessage(serialize);

So, if the message was already serialized using the TCP flavor, this fails.
My first workaround was to catch the exception in "parse", reset the bytes to nulll, then serialize and parse again. But the disadvantage would be, that, if this patter is used somewhere else, it mus be fixed also there. Therefore I introduced the flavor to limit the effects.

I also tried to find out, why this serialize/parse was done:
http://dev.eclipse.org/mhonarc/lists/leshan-dev/msg00630.html

But, thought I'm not sure, what exactly must be reset, a choose to stuck with the already contained stuff und fix the serialization flavors instead.

[boaks]

I still think, this solution, using the caching for Message.bytes, is better then always serialize/parse on every notify.

The current fix of #141 must be applied also to other usage (outside californium).