Menu
▾
▴
Re: [Openoss-devel] Problems with PM XSD generation
|
From: Craig G. (opennms) <cg...@op...> - 2012-07-03 19:07:30
|
Xose, are you also doing the primitive.uri / primitive.url changes to support the new profile? Craig On 03/07/2012 11:33, Xose Ramon Sousa Vazquez wrote: > 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> > |
