The recent update to javaParameterTemplate.vm fixed the problem with the
generated ROSpec class and its ability to handle a Custom parameter as
one of the choices of a SpecParameter (i.e., AISpec, RFSurveySpec, and
Custom).
However, it now appears to me that the LTK Java library only handles the
generic Custom parameter defined in the LLRP namespace (not just in
ROSpec, but wherever there's a custom parameter). Here's the details:
Updating resources\generator.properties with a definition for vendor
extensions (namespace, XML def, and XML schema) and rebuilding LTK Java
does work. The appropriate custom\parameter classes are generated and
the XML validator (class LLRPMessage, method isValidXMLMessage) accepts
vendor extensions as defined in the vendor extension XML scheme. For
instance, here's a snippet of an ADD_ROSPEC message:
<llrp:ADD_ROSPEC
xmlns:llrp="http://www.llrp.org/ltk/schema/core/encoding/xml/1.0
<http://www.llrp.org/ltk/schema/core/encoding/xml/1.0> "
xmlns:Acme="http://www.acme.com/rfid/llrp
<http://www.acme.com/rfid/llrp> "
Version="1" MessageID="1">
<llrp:ROSpec>
<llrp:ROSpecID>1</llrp:ROSpecID>
<llrp:Priority>0</llrp:Priority>
<llrp:CurrentState>Disabled</llrp:CurrentState>
<llrp:ROBoundarySpec>...</llrp:ROBoundarySpec>
<llrp:AISpec>...</llrp:AISpec>
<Acme:AcmeExtension>
<Acme:ExtensionField>1</Acme:ExtensionField>
</Acme:AcmeExtension>
<llrp:ROReportSpec>...</llrp:ROReportSpec>
</llrp:ROSpec>
</llrp:ADD_ROSPEC>
The XML validator (class LLRPMessage, method isValidXMLMessage) accepts
<Acme:AcmeExtension> as a custom parameter choice of SpecParameter.
However, during runtime, <Acme:AcmeExtension> is rejected with the
following stack trace:
org.llrp.ltk.exceptions.InvalidLLRPMessageException: ROSpec has unknown
element AcmeExtension
at org.llrp.ltk.generated.parameters.ROSpec.decodeXML(ROSpec.java:523)
Looking at the code (ROSpec.java), the problem is that the following
code cannot recognize <Acme:AcmeExtension>
// check for all custom parameters for this parameter
// check for regular custom parameter
tempList = element.getChildren("Custom", ns);
for (Element e : tempList) {
specParameterList.add(new Custom(e));
LOGGER.debug("adding SpecParameter to specParameterList ");
}
element.removeChildren("Custom", ns);
Adding the following code will handle <Acme:AcmeExtension> properly:
Namespace nsAcme =
Namespace.getNamespace("http://www.acme.com/rfid/llrp";);
tempList = element.getChildren("AcmeExtension", nsAcme);
for (Element e : tempList) {
specParameterList.add(new AcmeExtension(e));
LOGGER.debug("adding AcmeExtension to customList ");
}
element.removeChildren("AcmeExtension", nsAcme);
Is there any other way to handle vendor-defined, custom parameters?
Christian says that LTKJava was tested with Impinj extensions however I
don't see that in the test cases in CVS. I'd like to see a working
example. That would help me see whether I have a disconnect in my
understanding about how LTKJava is supposed to handle vendor extensions.
Regards,
Rob Buck
This message is intended only for the named recipient. If you are not the
intended recipient, you are notified that disclosing, copying, distributing or
taking any action based on the contents of this information is strictly
prohibited.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
