[Openoss-devel] Fwd: Re: Problems - no Tracking Record iterator wsdl

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

-------- Original Message --------
Subject: 	Re: Problems - no Tracking Record iterator wsdl
Date: 	Wed, 21 Mar 2012 08:25:50 +0000
From: 	Craig Gallen (entimoss) <cra...@en...>
Organisation: 	Entmoss Ltd
To: 	Xose Ramon Sousa Vazquez <xr...@op...>
CC: 	'Craig Gallen (opennms)' <cg...@op...>, 'openoss-devel' 
<ope...@li...>, 'pierre gauthier' 
<pie...@os...>, 'Flauw, Marc' <Mar...@hp...>

xose,

sorry, I thought you needed the RAM location. The soap generator is at
https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator

to find other things - for an explanation of the repository layout 
please see 
http://sourceforge.net/apps/mediawiki/openoss/index.php?title=Project_Structure 
its a little out of date but the overall structure hasn't changed

Thanks for your help

Craig

On 21/03/2012 06:24, Xose Ramon Sousa Vazquez wrote:
> I found the problem in a wrapper in the generator that don't 
> initialize the dependecies, so the dep prefix was not included.
>
>
>
> I can checkin the code, but in the svn path that you give me there is 
> no SOAPGenerator there. Must I chechin to another path and then the 
> maven get the implementation?
>
> Regards
> El 16/03/2012 12:36, Xose Ramon Sousa Vazquez escribió:
>> It seems that the closure is not bypassed because of the filters 
>> associated with the rules. I have tested and only the tracking record 
>> iterator is generated. In this review I have found that in the schema 
>> the name used to import is 
>> _cbe_problem_trackingrecorditerator_msg.xsd and the new file 
>> generated is dep_cbe_problem_trackingrecorditerator_msg.xsd. We are 
>> evaluating it to solve this new issue
>>
>>
>> Best regards
>> El 16/03/2012 9:56, Craig Gallen escribió:
>>>
>>> Hi,
>>>
>>> Thanks for looking at this. the svn path for the trunk of the ram 
>>> project is.
>>>
>>> https://collab.tmforum.org/svn/repos/tip/Features/ResourceAlarmManagement/IA/Interface/trunk 
>>>
>>>
>>> Are you sure that including artefacts from dependencies and 
>>> referenced projects will not bypass the closure mechanism and cause 
>>> the plugin to generate all of the artefacts in the dependencies model?
>>>
>>> Craig
>>>
>>> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...]
>>> *Sent:* 15 March 2012 18:20
>>> *To:* Craig Gallen (opennms)
>>> *Cc:* openoss-devel; pierre gauthier; Flauw, Marc
>>> *Subject:* Re: Problems - no Tracking Record iterator wsdl
>>>
>>> Hi, I have analyzed the project and the SOAP Generator code and 
>>> seems that the problem is related with the parametrization of the 
>>> rules used in SOAPGenerator.
>>> When you create the plugin (or generator), in the ts-plugin.xml file 
>>> select the Rules tab. There are defined several rules. Two of them 
>>> related with this generator or plugin (Xsd_IteratorServiceMsg and 
>>> Wsdl_IteratorService_Ws related) have unchecked the option*Includes 
>>> artifacts from dependences and referenced projects*. As the tracking 
>>> records are included as dependencies, the iterator is not generated.
>>>
>>>
>>> I think that this is the cause of the problem. If you want I can 
>>> checkin the*ts-plugin.xml* file with the changes, but I am not sure 
>>> about which svn path must be used.
>>>
>>>
>>> Best regards
>>> El 14/03/2012 12:06, Craig Gallen (opennms) escribió:
>>>
>>> Hi,
>>>
>>> the location of the ram project is
>>> https://collab.tmforum.org/svn/repos/tip/Features/ResourceAlarmManagement/IA/Interface/trunk 
>>>
>>>
>>> The model and dependency projects are in this location.
>>>
>>> there are no log files produced when I run a generate from eclipse
>>>
>>> The  problem is that the trackingrecorditerator.wsdl is not 
>>> generated even though the resourcealarmiterator.wsdl is generated. 
>>> The stereotypes are the same on the respective operations
>>>
>>> Craig
>>>
>>>
>>> On 13/03/2012 11:48, Xose Ramón Sousa wrote:
>>>
>>> Craig I have taken the files from the spec of Ram but I only can get
>>> the model exported.
>>> Please could you give me the location to download the project to 
>>> review it
>>>
>>> Also you can send me the log files stored in the target directory
>>>
>>> Regards
>>>
>>> Enviado desde mi iPhone
>>>
>>> El 12/03/2012, a las 12:19, "Craig Gallen (opennms)"
>>> <cg...@op...> <mailto:cg...@op...>  escribió:
>>>
>>>
>>> Hi,
>>> Quick question.
>>> In the RAM model ResourceAlarmRetrievalService we have two 
>>> operations which have identical stereotypes to return iterators;
>>> getResourceAlarms()  and getTrackingRecords()
>>> both operations state bulk transfer pattern is an iterator
>>> however only getResourceAlarms() generates an additional iterator 
>>> wsdl file
>>>
>>> Where is the tracking record iterator wsdl service defined?
>>>
>>> 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><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>
>