Menu
▾
▴
Re: [Openoss-devel] Problems with PM XSD generation
|
From: Xose R. S. V. <xr...@op...> - 2012-07-03 10:41:30
|
Hi all. I am developing a module that get the packages to perform the funcionallity desired, but in the models there are changes in the way they are instantied so a deeper revision is needed. I have got the code to obtain the packages and now we are changing the models, but has a lot of dependences in building the closure. I am trying to finish it and the publish on the sandbox area better to perform tests and avoid regression problems. Regards El 02/07/2012 15:40, Craig Gallen (opennms) escribió: > 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> >> > > -- *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> |
