Menu
▾
▴
Re: [Openoss-devel] Problems with PM XSD generation
|
From: Xose R. S. V. <xr...@op...> - 2012-06-28 07:44:48
|
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> |
