|
From: Xose R. S. V. <xr...@op...> - 2012-08-14 11:38:18
|
Hi Craig I have fixed the velocity template that miss the behaivour that you describe in your email. I will analyze the filtering model and your proposals now. Regards El 11/08/2012 11:42, Craig Gallen (opennms) escribió: > 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 > > > > > > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |