|
From: Craig G. (opennms) <cg...@op...> - 2012-08-11 09:42:20
|
Hi Xose, Marc
Once again I'm afraid I've come up with a new bug in the xml generated
by the soap generator and some other questions. I have found this while
trying to get the PM model implementation to generate correctly.
1.Problem: tipEntityGetMultiple stereotype not generating correct
iterator response element
In pm_cbe_perf_mon_coll_adhoccollectionservice_msg.xsd we can see two
examples of generated iterators;
a) getTrackingRecords is an explicit method declared in the
AdhocCollectionService with stereotype settings 'isBulkPotential' and
'bulk transfer pattern = ITERATOR'.
In the this case the response object getTrackingRecordsResponse
correctly extends iterator:CommonResponse
<xsd:complexType name="getTrackingRecordsResponse">
<xsd:complexContent>
<xsd:extension base="iterator:CommonResponse">
<xsd:sequence>
<xsd:element name="trackingRecords"
type="problem:TrackingRecordResultWithIterator" minOccurs="0" maxOccurs="1">
... etc
b) getAdhocCollections is generated using the tipEntityGetMultiple
stereotype on the AdhocCollection entity
in this case the response object getAdhocCollectionsResponse incorrectly
does not extend iterator:CommonResponse
<xsd:complexType name="getAdhocCollectionsResponse">
<xsd:sequence>
<xsd:element name="AdhocCollections"
type="tns:AdhocCollectionResultWithIterator" minOccurs="0" maxOccurs="1">
... etc
This is a bug and needs fixed quickly for the PM interface to work. We
need to change the soap generator to ensure that all iterator responses
extend from iterator:CommonResponse whether explicitly declared in a
method stereotype or declared through the tipEntityGetMultiple
stereotype. i.e.;
<xsd:complexType name="getAdhocCollectionsResponse">
<xsd:complexContent>
<xsd:extension base="iterator:CommonResponse">
<xsd:sequence>
<xsd:element name="AdhocCollections"
type="tns:AdhocCollectionResultWithIterator" minOccurs="0" maxOccurs="1">
... etc
____________
2. Question / feature request - needs consideration by the team
The filtering mechanism seems overly complex and very different between
the use of primitive.filter and tipEntityGetMultiple
This is a plea to think through whether we could simplify the template
filtering mechanism to support any type of entity rather than having it
type specific. The comments below are observations and will need a bit
more thinking through but I think they align with what is needed for the
inventory interface.
In the TIP Profile the primitive.filter has the following documentation;
'Primitive filter datatype corresponding to a choice of template or
query filter'. This is not what we generate.
The generated XML for attribute filter type primitive.filter in the
ResourceAlarmRetreivalService ( RAM Model) is
<xsd:element name="filter" type="filter:XPathQueryFilter" minOccurs="0"
maxOccurs="1">
In other word there is no choice of template or query filter.
primitive.filter only uses xpath
In the getAdhocCollections request generated from the
tipEntityGetMultiple stereotype we generate
attribute filter of type AdhocCollectionFilterChoice
<xsd:complexType name="getAdhocCollectionsRequest">
<xsd:complexContent>
<xsd:extension base="iterator:CommonRequest">
<xsd:sequence>
<xsd:element name="filter"
type="tns:AdhocCollectionFilterChoice" minOccurs="0" maxOccurs="1">
... etc
<xsd:complexType name="AdhocCollectionFilterChoice">
<xsd:choice>
<xsd:element name="templateFilter"
type="tns:AdhocCollectionTemplateFilter" minOccurs="0" maxOccurs="1"/>
<xsd:element name="queryFilter" type="filter:XPathQueryFilter"
minOccurs="0" maxOccurs="1"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="AdhocCollectionTemplateFilter">
<xsd:complexContent>
<xsd:extension base="filter:TemplateFilter">
<xsd:sequence>
<xsd:element name="templates"
type="tns:ArrayOfAdhocCollectionTemplate" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
In other word we have a choice of AdhocCollectionTemplateFilter or the
XPathQueryFilter which we could get from primitive.filter above
(although the signature is very different). This is overly complex and
inconsistent. We clearly need primitive.filter to generated the same
sort of selection mechanisms as tipEntityGetMultiple but the
primitive.filter template filter needs to be generic to any entity type
rather than specific to a particular entity as in
AdhocCollectionTemplateFilter
Would it be possible for both primitive.filter and tipEntityGetMultiple
to generate something like;
<xsd:complexType name="FilterChoice">
<xsd:choice>
<xsd:element name="templateFilter" type="tns:TemplateFilter"
minOccurs="0" maxOccurs="1"/>
<xsd:element name="queryFilter" type="filter:XPathQueryFilter"
minOccurs="0" maxOccurs="1"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="TemplateFilter">
<xsd:complexContent>
<xsd:sequence>
<xsd:element name="templates" type="tns:ArrayOfTemplate"
minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexContent>
where all Entity Template types then extend Template?
What do you think?
Craig
|