Menu
▾
▴
Re: [Openoss-devel] Problems with PM XSD generation
|
From: Xose R. S. V. <xr...@op...> - 2012-07-04 07:30:22
|
I have developed a workaround for solve the bug in tigerstripe, you can download from: https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator Please send me feedback about that Regards El 03/07/2012 21:07, Craig Gallen (opennms) escribió: > 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> >> > > -- *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> |
