Menu
▾
▴
Re: [Openoss-devel] Problems with PM XSD generation
|
From: Craig G. (opennms) <cg...@op...> - 2012-07-02 13:40:39
|
Hi Xose, Duncan from Tigerstripe has replied on bugzilla that we need to uncheck the "Run All Rules as Local" https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728 . I have run the MPAC model with "Run All Rules as Local" checked and then as unchecked to ensure that the property is correctly set in tigerstripe.xml. However this does not appear to fix the problem. Dependencies are not being generated by the soap plugin. Could you run the test in your model and get back to Duncan if it is still the issue. Thanks Craig On 28/06/2012 08:22, Xose Ramon Sousa Vazquez wrote: > I have created the bug > Bug 383728 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has > been added to the database > > Email sent to: > |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| > Excluding: > |xr...@op...| > > > > Regards > El 28/06/2012 9:18, Flauw, Marc escribió: >> >> Xose, >> >> Send us the bug pointer and I will escalate it . >> >> Best regards >> >> Marc >> >> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >> *Sent:* Thursday, June 28, 2012 9:17 AM >> *To:* Craig Gallen (opennms) >> *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' >> *Subject:* Re: [Openoss-devel] Problems with PM XSD generation >> >> 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> >> >> -- >> >> *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> >> >> -- >> >> *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> >> >> -- >> >> *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> >> >> -- >> >> *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> >> > > > -- > > *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> > |
