LTKC and LTKCPP frame encoders deliver a run-time error
during encode (serialize). Nothing is actually sent.
Details are provided to aid the programmer tracking down
the bug.
LTKC and LTKCPP XML encoders include <!-- warning -->
lines in the output for missing parameters.
The two together can be wrapped in a routine that looks
something like (only an approximation)
sendMessage (CMessage *pOutMsg)
{
if(FrameEncode(pOutMsg) != OK)
{
printf("Encode failed\n");
/* look for the warnings in here */
XMLEncode(pOutMsg);
}
}
Hope this helps.
-gww
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Kyle Neumeier
Sent: Thursday, July 19, 2007 3:05 PM
To: LLRP Toolkit Development List
Subject: [ltk-d] Malformed Message Handling
As you know Pramari is building an llrp reader emulator based of the epc
spec. We are currently using the java llrp toolkit code to do the
translation between classes and bytes and vice versa. Recently we have
been thinking about the error checking of messages, and I wanted to see
how the other projects (c++ etc) are going to handle this.
When the client forms a message (for example an ADD_ROSPEC), you have to
create an object like this:
AddROSpec aros = new AddRoSpec();
Then you have to create parameters, set values and add them to the
parent
object like this:
ROSpec rs = new ROSpec();
rs.setROSpecID(10);
..
set more rospec params and fields
..
aros.setRoSpecParam(rs);
As you can see, there is alot do do here; there ends up being about 40
lines of code to create a ROSpec if you want to set all the various
parameters. It would be easy -- especially in the early stages of
testing and development -- to forget to create a certain parameters or
even just to forget to add it to its parent object. I assume for the
other projects, something similar will be necessary.
The java classes that we are using create default objects automatically
with default values for required parameters to enforce compliance. From
our point of view, however, this could cause problems, because a user
could be looking for some specific behavior, see that that behavior is
not exhibited even though he has set the value (for example a timeout
value or a boolean value in the reportspec), when in fact he made some
mistake in forming the message (like forgetting to add it to the parent
object). No runtime error (a NullPointer or IndexOutOfBounds etc) will
be generated because the llrp toolkit java classes automatically created
default objects; the problem will be much more difficult to debug than
it has to be because the user can't tell immediately if it is a problem
with the message or a problem with our reader emulator.
We are proposing a change in the java llrp-toolkit classes so that
runtime errors are thrown when messages are serialized (from objects
into a byte array to be sent on the wire) if the user forgot to supply a
required object instead of default parameters being used.
We also want to get other's input on this issue and see how other
projects are planning on handling this problem.
This will also give us a chance to figure out some sort of a process for
making changes to code and such....
Thanks,
Kyle
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
