Menu
▾
▴
Re: [Openoss-devel] Problems with PM XSD generation
|
From: Xose R. S. V. <xr...@op...> - 2012-06-28 07:17:56
|
Hi all. I have post the problem in the user list as the bug creation recommends. Nobody answer that so I am going to create the bug. I have a first version of the workaround but aome problems are derived in the cast operations in the src_shared classes, so I must investigate deeper. If this issue is solved I can send you Craig a preeliminary patch and then check the behaivour of the other $allxxxx context elements. Regards El 28/06/2012 6:32, Craig Gallen (opennms) escribió: > Xose & Marc, > > Is there a plan to complete primitive.url / primitive.uri in the soap > generator. I have support for it in the Java generators but need the > Soap generator working with this stereotype to test this code. > > Also has a bug been raised against Tigerstripe for the $allPackage > issue ? I'd prefer to fix the problem in tigerstripe rather than have > Xose get a work around because if this isnt working, its possible > other 'get all collections' of artificates are not working. So this > could be a general problem for the other generators including Cisco's own. > > Xose, have you raised a bug report and if so what is the bug number? > > Marc, when we have a bug report, can we escalate this directly to the > tigerstripe team because it is a show stopper for us. > > I'm afraid I cannot do any more development until this is fixed. > > Thanks for your help > > Craig > > > >> >> >> >> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >>> I am going to test a workaround to see if this could be supported >>> without change the tigerstripe core. >>> >>> Regards >>> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >>>> Hi, >>>> >>>> So is there a work around or do we have to wait for Tigerstripe to >>>> sort this out. >>>> The old version of tigerstripe (6.9.xxx) is no longer available to >>>> download. >>>> >>>> Craig >>>> >>>> >>>> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >>>>> Thanks Craig. >>>>> I have performed some test and I can see an error in the Default >>>>> Velocity context contents. When the $allPackage variable is used >>>>> in the dependencyAnalyzer.vm template, it is expected that all >>>>> artifacts, including the dependences, are included in that >>>>> collection. In my tests I've got this behaivour: >>>>> >>>>> Old version of tigerstripe( Tigerstripe Core (Incubation) >>>>> 0.6.935.201102010903 org.eclipse.tigerstripe.base.feature.group) >>>>> %%%Calculate the dependencies/closure with >>>>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>>>> org.tmforum.tip.resource.trouble(428889018), >>>>> org.tmforum.tip.resource(240211633), >>>>> org.tmforum.tip.cbe.perf(1039318676), >>>>> org.tmforum.tip.common.notifications(23492680), >>>>> org.tmforum.tip.resource.res(1133197283), >>>>> org.tmforum.tip.cbe.root(1039387789), org.tmforum.tip(-660924437), >>>>> org.tmforum.tip.cbe.root._char(-1449023596), >>>>> org.tmforum(1644248382), org(110308), >>>>> org.tmforum.tip.common(442435918), >>>>> org.tmforum.tip.cbe.party(-2140978021), >>>>> org.tmforum.tip.cbe.problem(292836116), >>>>> org.tmforum.tip.cbe.root.tip.fmk(693071952), >>>>> org.tmforum.tip.internal.filter(-1708340282), >>>>> org.tmforum.tip.internal.extensibility(-1665414181), >>>>> org.tmforum.tip.internal(1151687008), >>>>> org.tmforum.tip.cbe.root.tip(1325885370), >>>>> org.tmforum.tip.internal.notifications(-1680981798), >>>>> org.tmforum.tip.common.exceptions(234099364), >>>>> org.tmforum.tip.cbe.party.role(1514413545), >>>>> org.tmforum.tip.internal.entity(-1732123599), >>>>> org.tmforum.tip.resource.res.tip(-1716701168), >>>>> org.tmforum.tip.internal.exceptions(-367434926), >>>>> org.tmforum.tip.cbe(1681757027), >>>>> org.tmforum.tip.internal.iterator(866200892), >>>>> org.tmforum.tip.resource.res.tip.nrb(290014272)] [2012-06-26 >>>>> 10:21:29.996+0200] >>>>> >>>>> New version og tigerstripe( Tigerstripe Core (Incubation) >>>>> 0.7.0.201206181258 org.eclipse.tigerstripe.base.feature.group): >>>>> %%%Calculate the dependencies/closure with >>>>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>>>> org.tmforum.tip.resource.trouble(428889018), >>>>> org.tmforum.tip.resource(240211633)] [2012-06-26 10:28:54.989+0200] >>>>> >>>>> So it seems that this is root cause for the missed files. >>>>> I will create a bug in Tigerstripe. >>>>> >>>>> Regards >>>>> >>>>> El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: >>>>>> Hi >>>>>> From eclipse, Soap generator subversion; >>>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>>> Revision 3453 >>>>>> (last change revision 3444 last commit author xrsousa) >>>>>> >>>>>> Craig >>>>>> >>>>>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>>>>>> Hi Craig, when you talk about the updated Soap Plugin, which >>>>>>> version (in svn url) are using?, because the two first issues >>>>>>> seems to be solved in the trunk with the other Tigerstripe version. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >>>>>>>> Hi Xose, >>>>>>>> >>>>>>>> I just updated my tigerstripe to the latest release >>>>>>>> 0.7.0.20120618258 but Ialso updated the Soap plug-in and have >>>>>>>> found multiple problems but I am not sure if they are all >>>>>>>> related to the tigerstripe upgrade or to the current state of >>>>>>>> the soap plugin. Could you build the RAM project and check the >>>>>>>> generated XSD's to see the problem. >>>>>>>> >>>>>>>> 1. when you build the RAM project there is a problem with model >>>>>>>> closure. None of the Dependency XSD's get generated in the >>>>>>>> RAM_Model project >>>>>>>> >>>>>>>> 2. TrackingRecordResultWithIterator referenced as >>>>>>>> 'problem:TrackingRecordResultWithIterator' in >>>>>>>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd is >>>>>>>> never generated. >>>>>>>> >>>>>>>> 3. Tigerstripe 0.7.0.20120618258. handles primitive.string >>>>>>>> differently and generates type 'String' instead of >>>>>>>> 'java.lang.String' this results in type :String instead of >>>>>>>> xsd:string. I did a quick fix given in the following patch adding >>>>>>>> || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>>>>> >>>>>>>> to >>>>>>>> || >>>>>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>>>>> this means that old and new versions of tigerstipe will work >>>>>>>> >>>>>>>> There is a patch below but havent checked this in because I >>>>>>>> was not sure that else you were doing to the Soap plugin >>>>>>>> >>>>>>>> Craig >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ### Eclipse Workspace Patch 1.0 >>>>>>>> #P TIP_Soap_Generator >>>>>>>> Index: >>>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>>>>> =================================================================== >>>>>>>> --- >>>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>>>>> (revision 3453) >>>>>>>> +++ >>>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>>>>> (working copy) >>>>>>>> @@ -510,8 +510,8 @@ >>>>>>>> */ >>>>>>>> if (refType.isPrimitive() >>>>>>>> || >>>>>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>>>>> - || "java.lang.String".equalsIgnoreCase(refType >>>>>>>> - .getFullyQualifiedName())) { >>>>>>>> + || >>>>>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>>>>> + || >>>>>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { >>>>>>>> // tigerstripe 1.7.0 now generates String and not java.lang.String >>>>>>>> PluginLog.logDebug("\'" + refTypeFullName >>>>>>>> + "\' is a primitive type in current TIP >>>>>>>> profile."); >>>>>>>> type = mapPrimitivesToXsdType(refType.getName(), >>>>>>>> isArray(refType), >>>>>>>> @@ -519,7 +519,7 @@ >>>>>>>> } >>>>>>>> >>>>>>>> /** >>>>>>>> - * Map datatyeps and enumerations >>>>>>>> + * Map datatypes and enumerations >>>>>>>> */ >>>>>>>> // if (refType.isDatatype() || refType.isEnum() >>>>>>>> else if (isDatatype(refType) || isEnumeration(refType)) { >>>>>>>> Index: >>>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>>>>> =================================================================== >>>>>>>> --- >>>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>>>>> (revision 3453) >>>>>>>> +++ >>>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>>>>> (working copy) >>>>>>>> @@ -170,8 +170,9 @@ >>>>>>>> private void addReferencedPackage(IType type) { >>>>>>>> >>>>>>>> if (type.isPrimitive() >>>>>>>> - || >>>>>>>> "primitive".equalsIgnoreCase(type.getPackage()) || >>>>>>>> - >>>>>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>>>>>> { >>>>>>>> + || "primitive".equalsIgnoreCase(type.getPackage()) >>>>>>>> + || >>>>>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>>>>>>> + || >>>>>>>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) { // >>>>>>>> tigerstripe 1.7.0 now generates String and not java.lang.String >>>>>>>> //will map objectName to EntityIdentifier or >>>>>>>> ArrayOfEntityIdentifier >>>>>>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>>>>>> PluginLog.logDebug("type \'" + type >>>>>>>> @@ -378,8 +379,8 @@ >>>>>>>> */ >>>>>>>> if (refType.isPrimitive() >>>>>>>> || >>>>>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>>>>> - || "java.lang.String".equalsIgnoreCase(refType >>>>>>>> - .getFullyQualifiedName())) { >>>>>>>> + || >>>>>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>>>>> + || >>>>>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { >>>>>>>> // tigerstripe 1.7.0 now generates String and not java.lang.String >>>>>>>> PluginLog.logDebug("\'" + typeName >>>>>>>> + "\' is a primitive type in current TIP >>>>>>>> profile."); >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>>>>>>>> Hi all. I think that I have found the error and I will try to >>>>>>>>> fix it as soon as possible. There are some related issues, one >>>>>>>>> error in the codification of a method and a forgetted >>>>>>>>> evaluation of filtering in the velocity template and also a >>>>>>>>> case related with primitive type filter not supported in the >>>>>>>>> build of the closure outside the interfaces. >>>>>>>>> >>>>>>>>> In the interfaces build the search is performed as >>>>>>>>> follows(this works fine as reported Marc): >>>>>>>>> >>>>>>>>> if >>>>>>>>> ("objectName".equalsIgnoreCase(argType.getName())) { >>>>>>>>> /* >>>>>>>>> * This data type 'objectName' >>>>>>>>> defines the protocol >>>>>>>>> * neutral unique name of an >>>>>>>>> object. This data type will >>>>>>>>> * be replaced by the generators >>>>>>>>> by an EntityIdentifier >>>>>>>>> */ >>>>>>>>> String pkg = PluginConstants >>>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>>>>>>>> if (!this.map.containsKey(pkg)) { >>>>>>>>> // >>>>>>>>> // New package - add new >>>>>>>>> pkg=prefix mapping >>>>>>>>> // assignment >>>>>>>>> // >>>>>>>>> String prefix = >>>>>>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>>>>>> pkg, this.map); >>>>>>>>> this.map.put(pkg, prefix); >>>>>>>>> } >>>>>>>>> } else if >>>>>>>>> ("filter".equalsIgnoreCase(argType.getName())) { >>>>>>>>> /* >>>>>>>>> * This data type 'filter'. This >>>>>>>>> data type will >>>>>>>>> * be replaced by the generator to >>>>>>>>> */ >>>>>>>>> String pkg = PluginConstants >>>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>>>>>>>> if (!this.map.containsKey(pkg)) { >>>>>>>>> // >>>>>>>>> // New package - add new >>>>>>>>> pkg=prefix mapping >>>>>>>>> // assignment >>>>>>>>> // >>>>>>>>> String prefix = >>>>>>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>>>>>> pkg, this.map); >>>>>>>>> this.map.put(pkg, prefix); >>>>>>>>> } >>>>>>>>> } else if >>>>>>>>> (XmlSchemaHelpers.isUnbounded(argType)) { >>>>>>>>> String pkg = PluginConstants >>>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>>>>>>>> if (!this.map.containsKey(pkg)) { >>>>>>>>> // >>>>>>>>> // New package - add new >>>>>>>>> pkg=prefix mapping >>>>>>>>> // assignment >>>>>>>>> // >>>>>>>>> String prefix = >>>>>>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>>>>>> pkg, this.map); >>>>>>>>> this.map.put(pkg, prefix); >>>>>>>>> } >>>>>>>>> } else { >>>>>>>>> // XSD default namespace is enough >>>>>>>>> } >>>>>>>>> >>>>>>>>> and in the build of the closure we have got (this fails as >>>>>>>>> reported Craig): >>>>>>>>> >>>>>>>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>>>>>>> PluginLog.logDebug("type \'" + type >>>>>>>>> + "\' is an array of primitive."); >>>>>>>>> addReferencedPackage(PluginConstants >>>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>>>>>>>> }else if (XmlSchemaHelpers.isUnbounded(type)){ >>>>>>>>> //will map to array of primitive >>>>>>>>> addReferencedPackage(PluginConstants >>>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>>>>>>>> } else { >>>>>>>>> //normal primtive like xsd:int >>>>>>>>> } >>>>>>>>> >>>>>>>>> so the filtering never is considered. >>>>>>>>> >>>>>>>>> I will perform clean tests because was very difficult to find >>>>>>>>> the real cause of the problem, the log file is not very clear >>>>>>>>> in debug scenarios ( a lot of similar log text, no log from >>>>>>>>> the templates and also cannot put the line number in the log >>>>>>>>> file (tigerstripe issue)) and these problems have delayed my >>>>>>>>> response. >>>>>>>>> If the test go ok I will check out the changes to the trunk >>>>>>>>> >>>>>>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> >>>>>>>>> >>>>>>>>> El 01/06/2012 16:58, Craig Gallen escribió: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>>>>>>>>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>>>>>>>>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>>>>>>>>> shows an error. >>>>>>>>>> >>>>>>>>>> I think Xose is looking into it >>>>>>>>>> >>>>>>>>>> Craig >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Flauw, Marc [mailto:Mar...@hp...] >>>>>>>>>> Sent: 01 June 2012 10:25 >>>>>>>>>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>>>>>>>>> gauthier >>>>>>>>>> Subject: RE: Problems with PM XSD generation >>>>>>>>>> >>>>>>>>>> Craig, >>>>>>>>>> >>>>>>>>>> There is one same filter in the getReosurceAlarms operation, filter >>>>>>>>>> argument. >>>>>>>>>> The XPathFilter is defined in the internal_filter.xsd >>>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> >>>>>>>>>> Marc >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>>>>>>>>> Gallen (opennms) >>>>>>>>>> Sent: Thursday, May 31, 2012 11:58 PM >>>>>>>>>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>>>>>>>>> Subject: Problems with PM XSD generation >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I have been testing the TIP_PM_Col project model and have found that the >>>>>>>>>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>>>>>>>>> >>>>>>>>>> in line 62 we have >>>>>>>>>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>>>>>>>>> minOccurs="0" maxOccurs="1"> >>>>>>>>>> >>>>>>>>>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>>>>>>>>> it reports this error as: >>>>>>>>>> >>>>>>>>>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>>>>>>>>> 'element'. Recorded reason: >>>>>>>>>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>>>>>>>>> the prefix 'filter' is not >>>>>>>>>> declared'. >>>>>>>>>> >>>>>>>>>> Is this a known problem or a new bug? >>>>>>>>>> >>>>>>>>>> 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> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *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> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *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> >>>>> >>>> >>>> >>> >>> >>> -- >>> >>> *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> >>> >> >> > > -- *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> |
