Menu
▾
▴
openoss-devel — OpenOSS Developer Mailing List
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(53) |
Aug
(86) |
Sep
(55) |
Oct
(19) |
Nov
(12) |
Dec
(9) |
| 2010 |
Jan
(8) |
Feb
(32) |
Mar
(31) |
Apr
(70) |
May
(67) |
Jun
(71) |
Jul
(26) |
Aug
(47) |
Sep
(25) |
Oct
(16) |
Nov
(11) |
Dec
(16) |
| 2011 |
Jan
(30) |
Feb
(31) |
Mar
(71) |
Apr
(64) |
May
(55) |
Jun
(25) |
Jul
(3) |
Aug
(24) |
Sep
(20) |
Oct
(18) |
Nov
(21) |
Dec
(1) |
| 2012 |
Jan
(9) |
Feb
(21) |
Mar
(29) |
Apr
(9) |
May
(9) |
Jun
(54) |
Jul
(37) |
Aug
(24) |
Sep
(43) |
Oct
(34) |
Nov
(25) |
Dec
(27) |
| 2013 |
Jan
(5) |
Feb
(13) |
Mar
(23) |
Apr
(9) |
May
(11) |
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Flauw, M. <Mar...@hp...> - 2012-07-02 08:30:01
|
Dear all, We need to decide on this discussion around Common Model. Do we keep it as one global model or break it down? >From past experience, it is very difficult to break down isolated pieces out of the SID as there are too many relationships in all directions. If we keep one common model, can we just ignore the ManagementJobInterface? We don't want to have it in all generated interfaces, which is the reason it was abstract initially. Is it possible for the Jvt and Impl generators to ignore it (as it is abstract) in the common model and only deal with it when finding a concrete interface that extends it? Best regards Marc -----Original Message----- From: Flauw, Marc Sent: Thursday, June 28, 2012 8:50 AM To: Pierre Gauthier; Craig Gallen (opennms) Cc: openoss-devel Subject: Re: [Openoss-devel] Abstract Facades in common model Pierre, We had a very long discussion on this topic. It is unfortunate you were not able to make, so let's try to summarize this discussion by mail. In JOSIF V1.1.1, Common Model was only common exceptions and common notifications. For V1.1.2, it has in addition base types, NRB types, Management Job and Schedule Definition. The first 2 are pretty generic, only datatypes and quite aligned with what we had so far in Common Model. Now with the 2 last additions, we are adding full package and FT includes an abstract service interface. Independently it is made concrete or not, Craig would need the wsdl for this interface to be generated. As all files from Common Model are copied in all generated interface kits, it means all interfaces would now include ManagementJobInterface wsdl. We don't want that in every interface. So the result of our discussion is that there are 2 possible routes: 1) Keep a rich and unique common model, but limit it to data (xsd) only. This means removing the service interface from the common model. In this case, the only way to provide the operations is to add a new stereotype for FT and use injection. This might be complex to achieve, as Common Model has a dependency on Generic Model and it cannot be the other way around. Adding a stereotype for this would require operations in Generic Model that would reference objects in Common Model which is not possible. 2) Split the Common Model in several smaller models, a bit similar to 3GPP IRPs. Keep the Common Model for the base objects (base and nrb). Introduce a schedule Definition model with only SD. Introduce a File Transfer model with only ManagementJob and the service interface. All those models would have a dependency on the base Common Model. Note also that the File Transfer model would have a dependency on Schedule, but this can easily be handled by adding the right dependency module. Then for PM, we need Schedule + FT, we pick the 2 modules from a central place or library. If schedule only is needed, then just pick its module. The second approach seems the most promising but it is worth more discussion before implementing it. This is what we did agree in the meeting: to have this additional discussion. Best regards Marc -----Original Message----- From: Pierre Gauthier [mailto:pga...@tm...] Sent: Thursday, June 28, 2012 6:31 AM To: Craig Gallen (opennms) Cc: Flauw, Marc; openoss-devel Subject: Re: [Openoss-devel] Abstract Facades in common model Hi, What would be the consequence of making the common model "concrete" with the assumption that the specific APIs would extend this concrete model. Pierre On Jun 27, 2012, at 10:32 AM, Craig Gallen (opennms) wrote: > Hi, > > Yes, The problem is that in every model, the generated marshalling > and marshalling code expects there to be a corresponding set of JAXB > classes which are generated from the model xsd/wsdl which the soap > generator creates. In a number of models, abstract interfaces are > created but these are extended by WSDL which is actually in the model. > However in the new common model case, there is only an abstract > interface and no concrete interface. > > In this case the current soap generator decides not to generate any > wsdl for the abstract interface and this leaves the corresponding > marshalling code without essential classes. At a minimum we need the > soap generator to generate abstract interfaces in the common model > even if there is no concrete interface in the model > > This may lead to a further discussion about possibly having more than > one 'common model' if we want to avoid including abstract interfaces > in TIP interfaces which don't need them. > > Hope this helps > Cheers > > Craig > > > > > > > > > > > On 27/06/2012 09:25, Flauw, Marc wrote: >> Hi Craig, >> >> So if my understanding is correct, you are asking for a change in the SOAP generator. >> >> Is it needed to generate wsdl for abstract service interfaces in all cases? >> I would assume that if the concrete service interface is present, then everything would be generated in the wsdl of the concrete service interface. >> >> Do you confirm the only case not covered is the common Model one, i.e. an abstract service interface with no derived concrete interface in the same project? >> >> Best regards >> >> Marc >> >> -----Original Message----- >> From: Craig Gallen [mailto:gal...@go...] On Behalf Of >> Craig Gallen (opennms) >> Sent: Tuesday, June 26, 2012 4:59 PM >> To: Flauw, Marc >> Cc: openoss-devel >> Subject: Re: Abstract Facades in common model >> >> Hi, >> >> We need to generate the wsdl for the abstract ManagementJobInterface >> because the rest of the build of the common model marshalling and >> unmarshalling for hte RI/CTK expects there to be jaxb classes >> generated from the ManagementJobInterface. These will be abstract >> classes which the later concrete classes extend >> >> Cheers >> Craig >> >> >> >> >> >> On 26/06/2012 06:43, Flauw, Marc wrote: >>> Craig, >>> >>> I think you refer to the ManagementJobInterface. It is true this is an abstract interface and it will be inherited by concrete ones in the interfaces using it. >>> >>> I am not sure to understand why we need to generate the wsdl for it. >>> >>> Best regards >>> >>> Marc >>> >>> -----Original Message----- >>> From: Craig Gallen [mailto:cg...@we...] >>> Sent: Tuesday, June 26, 2012 3:56 AM >>> To: Flauw, Marc; openoss-devel >>> Subject: Abstract Facades in common model >>> >>> Hi, >>> >>> >>> The Common model contains an abstract facade but the soap generator does not generate this if there is no super facade. We should be generating the abstract faecal as abstract WSDL otherwise the Common model does not compile correctly. >>> >>> Craig >> > > > > ---------------------------------------------------------------------- > -------- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions will include endpoint security, mobile security and the > latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Openoss-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openoss-devel > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Openoss-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openoss-devel |
|
From: Craig G. (opennms) <cg...@op...> - 2012-06-29 22:46:28
|
Hi, Sorry, my fault. I was talking rubbish Craig On 29/06/2012 17:16, Flauw, Marc wrote: > Hi Craig, > > There is no such thing as bulkTransferPattern=ID. The only 3 values are NONE, ITERATOR and FILE. > > All generators when finding a tipParameter. passedById=true should generate and identifier and not the class. If this is not the case, then it is a bug. passedbyId is always at param level. > > I just pushed a mail from Duncan indicating a change we should try to make it work. > They have also found a related bug and will generate a kit on the josif update site. > > Best regards > > Marc > > -----Original Message----- > From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms) > Sent: Friday, June 29, 2012 5:57 PM > To: Flauw, Marc > Cc: Pierre Gauthier; openoss-devel > Subject: Re: [Openoss-devel] Abstract Facades in common model > > Marc, > > Suddenly I think I see the problem. > > Although you say that ManagmentJob is being passed by ID , this is not what is actually happening when the model is generated. > While the individual suspend and resume methods have tipPerimeter passedById=true, the The tipOperation stereotype on ManagementJobInterface is set to bulktransferpattern=NONE. This means that EntityIdentifier is not used and the generated code expects ManagmentJob rather than EntityIdentifier. > > I think you need to change bulktransferpattern=ID and all will be well. > > Any feedback from tigerstripe about the bug? > > Have a good weekend > Craig > > > > > On 29/06/2012 07:39, Flauw, Marc wrote: >> Hi Craig, >> >> There is no polymorphism in the methods of the ManagementJobInterface. Yes, the 3 methods are taking a MJ, but by id and a MJ is never returned by value by those methods. >> Suspend and resume have no output param. listAvailableFiles is returning a set of FileDescriptor. >> >> We left the methods returning MJ data, like create, get, set to the concrete service interfaces. We did agree a while ago on that fact. >> >> Inventory pattern might introduce polymorphic operations, but those operations would be added by injection 9at least, this is my understanding). >> >> Best regards >> >> Marc >> >> -----Original Message----- >> From: Craig Gallen [mailto:gal...@go...] On Behalf Of >> Craig Gallen (opennms) >> Sent: Thursday, June 28, 2012 7:31 PM >> To: Flauw, Marc >> Cc: Pierre Gauthier; openoss-devel >> Subject: Re: [Openoss-devel] Abstract Facades in common model >> >> Hi, >> >> Can I add a further point which I have tried to test in the Common Model. It seems that the use of facades which contain methods manipulating abstract entities is a bad idea. We can never extend the interface in a model to have the same methods manage a concrete entity. >> This is illustrated by the following example; >> >> In the common model the new ManagementJobInterface has methods >> which take the abstract ManagementJob as an argument. Simplified this >> looks like; ManagementJobInterface.suspend( ManagementJob ...) >> ManagementJobInterface.resume (ManagementJob ...) >> ManagementJobInterface.list (ManagementJob ...) >> >> ManagementJob is abstract which means that in a concrete interface we will need to create a concrete extension to ManagementJob and provide methods which manage the extension. >> >> However if I create an extension (subclass) of the >> ManagementJobInterface such that; ManagementJobInterfaceExtended >> extends ManagementJobInterface >> >> and give ManagementJobInterfaceExtended the methods >> ManagementJobInterfaceExtended.suspend( ManagementJobExtension) >> ManagementJobInterfaceExtended.resume (ManagementJobExtension) >> ManagementJobInterfaceExtended.list (ManagementJobExtension) >> >> The resulting WSDL has errors because it has the same method Request and Response types but with different signatures. Similar problems occurr in the generated JVT code. Depending on how this is done we will either end up with WSDL which is unusable or with multiple overloaded methods with different signatures, only one of which is actually needed. Either way it is not satisfactory. >> >> In short, defining WSDL interface methods for abstract entities does >> not appear to be a good strategy. We cannot extend the methods in a >> concrete interface to indicate that they are now working on a child of >> the abstract entity. ( I know in theory we could just pass the >> interface an extension class but this introduces some really difficult >> implementation problems if we don't know before hand what the concrete >> class actually should be when WSDL marshalling / unmarshalling. You >> cant instantiate an abstract class and you don't know what concrete >> class will be presented to the interface ) >> >> What does this mean? It suggests that a better strategy would be to >> define ManagementJob as a concrete class which is manipulated by a >> (concrete) ManagementJobInterface. However instead of extending ManagementJob for each usage, we create a field inside ManagementJob which contains a datatype ManagementJobDetails. (This is like the specification pattern in the SID). This ManagementJobDetails datatype could be extended in the model without impacting the generated WSDL interface or could simply contain a set of name value pairs. >> >> I cant think of any other easy solution. What do you think? >> >> Craig >> >> >> >> >> >> >> On 28/06/2012 07:49, Flauw, Marc wrote: >>> Pierre, >>> >>> We had a very long discussion on this topic. It is unfortunate you were not able to make, so let's try to summarize this discussion by mail. >>> >>> In JOSIF V1.1.1, Common Model was only common exceptions and common notifications. >>> For V1.1.2, it has in addition base types, NRB types, Management Job and Schedule Definition. The first 2 are pretty generic, only datatypes and quite aligned with what we had so far in Common Model. >>> >>> Now with the 2 last additions, we are adding full package and FT includes an abstract service interface. Independently it is made concrete or not, Craig would need the wsdl for this interface to be generated. >>> >>> As all files from Common Model are copied in all generated interface kits, it means all interfaces would now include ManagementJobInterface wsdl. We don't want that in every interface. >>> >>> So the result of our discussion is that there are 2 possible routes: >>> 1) Keep a rich and unique common model, but limit it to data (xsd) only. This means removing the service interface from the common model. In this case, the only way to provide the operations is to add a new stereotype for FT and use injection. This might be complex to achieve, as Common Model has a dependency on Generic Model and it cannot be the other way around. Adding a stereotype for this would require operations in Generic Model that would reference objects in Common Model which is not possible. >>> 2) Split the Common Model in several smaller models, a bit similar to 3GPP IRPs. Keep the Common Model for the base objects (base and nrb). Introduce a schedule Definition model with only SD. Introduce a File Transfer model with only ManagementJob and the service interface. All those models would have a dependency on the base Common Model. Note also that the File Transfer model would have a dependency on Schedule, but this can easily be handled by adding the right dependency module. >>> Then for PM, we need Schedule + FT, we pick the 2 modules from a central place or library. If schedule only is needed, then just pick its module. >>> >>> The second approach seems the most promising but it is worth more discussion before implementing it. This is what we did agree in the meeting: to have this additional discussion. >>> >>> Best regards >>> >>> Marc >>> -----Original Message----- >>> From: Pierre Gauthier [mailto:pga...@tm...] >>> Sent: Thursday, June 28, 2012 6:31 AM >>> To: Craig Gallen (opennms) >>> Cc: Flauw, Marc; openoss-devel >>> Subject: Re: [Openoss-devel] Abstract Facades in common model >>> >>> Hi, >>> >>> What would be the consequence of making the common model "concrete" with the assumption that the specific APIs would extend this concrete model. >>> >>> Pierre >>> On Jun 27, 2012, at 10:32 AM, Craig Gallen (opennms) wrote: >>> >>>> Hi, >>>> >>>> Yes, The problem is that in every model, the generated marshalling >>>> and marshalling code expects there to be a corresponding set of JAXB >>>> classes which are generated from the model xsd/wsdl which the soap >>>> generator creates. In a number of models, abstract interfaces are >>>> created but these are extended by WSDL which is actually in the model. >>>> However in the new common model case, there is only an abstract >>>> interface and no concrete interface. >>>> >>>> In this case the current soap generator decides not to generate any >>>> wsdl for the abstract interface and this leaves the corresponding >>>> marshalling code without essential classes. At a minimum we need >>>> the soap generator to generate abstract interfaces in the common >>>> model even if there is no concrete interface in the model >>>> >>>> This may lead to a further discussion about possibly having more >>>> than one 'common model' if we want to avoid including abstract >>>> interfaces in TIP interfaces which don't need them. >>>> >>>> Hope this helps >>>> Cheers >>>> >>>> Craig >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 27/06/2012 09:25, Flauw, Marc wrote: >>>>> Hi Craig, >>>>> >>>>> So if my understanding is correct, you are asking for a change in the SOAP generator. >>>>> >>>>> Is it needed to generate wsdl for abstract service interfaces in all cases? >>>>> I would assume that if the concrete service interface is present, then everything would be generated in the wsdl of the concrete service interface. >>>>> >>>>> Do you confirm the only case not covered is the common Model one, i.e. an abstract service interface with no derived concrete interface in the same project? >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> -----Original Message----- >>>>> From: Craig Gallen [mailto:gal...@go...] On Behalf >>>>> Of Craig Gallen (opennms) >>>>> Sent: Tuesday, June 26, 2012 4:59 PM >>>>> To: Flauw, Marc >>>>> Cc: openoss-devel >>>>> Subject: Re: Abstract Facades in common model >>>>> >>>>> Hi, >>>>> >>>>> We need to generate the wsdl for the abstract >>>>> ManagementJobInterface because the rest of the build of the common >>>>> model marshalling and unmarshalling for hte RI/CTK expects there to >>>>> be jaxb classes generated from the ManagementJobInterface. These >>>>> will be abstract classes which the later concrete classes extend >>>>> >>>>> Cheers >>>>> Craig >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 26/06/2012 06:43, Flauw, Marc wrote: >>>>>> Craig, >>>>>> >>>>>> I think you refer to the ManagementJobInterface. It is true this is an abstract interface and it will be inherited by concrete ones in the interfaces using it. >>>>>> >>>>>> I am not sure to understand why we need to generate the wsdl for it. >>>>>> >>>>>> Best regards >>>>>> >>>>>> Marc >>>>>> >>>>>> -----Original Message----- >>>>>> From: Craig Gallen [mailto:cg...@we...] >>>>>> Sent: Tuesday, June 26, 2012 3:56 AM >>>>>> To: Flauw, Marc; openoss-devel >>>>>> Subject: Abstract Facades in common model >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> The Common model contains an abstract facade but the soap generator does not generate this if there is no super facade. We should be generating the abstract faecal as abstract WSDL otherwise the Common model does not compile correctly. >>>>>> >>>>>> Craig >>>> -------------------------------------------------------------------- >>>> - >>>> - >>>> -------- >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. >>>> Discussions will include endpoint security, mobile security and the >>>> latest in malware threats. >>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> _______________________________________________ >>>> Openoss-devel mailing list >>>> Ope...@li... >>>> https://lists.sourceforge.net/lists/listinfo/openoss-devel >>>> > |
|
From: Flauw, M. <Mar...@hp...> - 2012-06-29 16:16:30
|
Hi Craig, There is no such thing as bulkTransferPattern=ID. The only 3 values are NONE, ITERATOR and FILE. All generators when finding a tipParameter. passedById=true should generate and identifier and not the class. If this is not the case, then it is a bug. passedbyId is always at param level. I just pushed a mail from Duncan indicating a change we should try to make it work. They have also found a related bug and will generate a kit on the josif update site. Best regards Marc -----Original Message----- From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms) Sent: Friday, June 29, 2012 5:57 PM To: Flauw, Marc Cc: Pierre Gauthier; openoss-devel Subject: Re: [Openoss-devel] Abstract Facades in common model Marc, Suddenly I think I see the problem. Although you say that ManagmentJob is being passed by ID , this is not what is actually happening when the model is generated. While the individual suspend and resume methods have tipPerimeter passedById=true, the The tipOperation stereotype on ManagementJobInterface is set to bulktransferpattern=NONE. This means that EntityIdentifier is not used and the generated code expects ManagmentJob rather than EntityIdentifier. I think you need to change bulktransferpattern=ID and all will be well. Any feedback from tigerstripe about the bug? Have a good weekend Craig On 29/06/2012 07:39, Flauw, Marc wrote: > Hi Craig, > > There is no polymorphism in the methods of the ManagementJobInterface. Yes, the 3 methods are taking a MJ, but by id and a MJ is never returned by value by those methods. > Suspend and resume have no output param. listAvailableFiles is returning a set of FileDescriptor. > > We left the methods returning MJ data, like create, get, set to the concrete service interfaces. We did agree a while ago on that fact. > > Inventory pattern might introduce polymorphic operations, but those operations would be added by injection 9at least, this is my understanding). > > Best regards > > Marc > > -----Original Message----- > From: Craig Gallen [mailto:gal...@go...] On Behalf Of > Craig Gallen (opennms) > Sent: Thursday, June 28, 2012 7:31 PM > To: Flauw, Marc > Cc: Pierre Gauthier; openoss-devel > Subject: Re: [Openoss-devel] Abstract Facades in common model > > Hi, > > Can I add a further point which I have tried to test in the Common Model. It seems that the use of facades which contain methods manipulating abstract entities is a bad idea. We can never extend the interface in a model to have the same methods manage a concrete entity. > This is illustrated by the following example; > > In the common model the new ManagementJobInterface has methods > which take the abstract ManagementJob as an argument. Simplified this > looks like; ManagementJobInterface.suspend( ManagementJob ...) > ManagementJobInterface.resume (ManagementJob ...) > ManagementJobInterface.list (ManagementJob ...) > > ManagementJob is abstract which means that in a concrete interface we will need to create a concrete extension to ManagementJob and provide methods which manage the extension. > > However if I create an extension (subclass) of the > ManagementJobInterface such that; ManagementJobInterfaceExtended > extends ManagementJobInterface > > and give ManagementJobInterfaceExtended the methods > ManagementJobInterfaceExtended.suspend( ManagementJobExtension) > ManagementJobInterfaceExtended.resume (ManagementJobExtension) > ManagementJobInterfaceExtended.list (ManagementJobExtension) > > The resulting WSDL has errors because it has the same method Request and Response types but with different signatures. Similar problems occurr in the generated JVT code. Depending on how this is done we will either end up with WSDL which is unusable or with multiple overloaded methods with different signatures, only one of which is actually needed. Either way it is not satisfactory. > > In short, defining WSDL interface methods for abstract entities does > not appear to be a good strategy. We cannot extend the methods in a > concrete interface to indicate that they are now working on a child of > the abstract entity. ( I know in theory we could just pass the > interface an extension class but this introduces some really difficult > implementation problems if we don't know before hand what the concrete > class actually should be when WSDL marshalling / unmarshalling. You > cant instantiate an abstract class and you don't know what concrete > class will be presented to the interface ) > > What does this mean? It suggests that a better strategy would be to > define ManagementJob as a concrete class which is manipulated by a > (concrete) ManagementJobInterface. However instead of extending ManagementJob for each usage, we create a field inside ManagementJob which contains a datatype ManagementJobDetails. (This is like the specification pattern in the SID). This ManagementJobDetails datatype could be extended in the model without impacting the generated WSDL interface or could simply contain a set of name value pairs. > > I cant think of any other easy solution. What do you think? > > Craig > > > > > > > On 28/06/2012 07:49, Flauw, Marc wrote: >> Pierre, >> >> We had a very long discussion on this topic. It is unfortunate you were not able to make, so let's try to summarize this discussion by mail. >> >> In JOSIF V1.1.1, Common Model was only common exceptions and common notifications. >> For V1.1.2, it has in addition base types, NRB types, Management Job and Schedule Definition. The first 2 are pretty generic, only datatypes and quite aligned with what we had so far in Common Model. >> >> Now with the 2 last additions, we are adding full package and FT includes an abstract service interface. Independently it is made concrete or not, Craig would need the wsdl for this interface to be generated. >> >> As all files from Common Model are copied in all generated interface kits, it means all interfaces would now include ManagementJobInterface wsdl. We don't want that in every interface. >> >> So the result of our discussion is that there are 2 possible routes: >> 1) Keep a rich and unique common model, but limit it to data (xsd) only. This means removing the service interface from the common model. In this case, the only way to provide the operations is to add a new stereotype for FT and use injection. This might be complex to achieve, as Common Model has a dependency on Generic Model and it cannot be the other way around. Adding a stereotype for this would require operations in Generic Model that would reference objects in Common Model which is not possible. >> 2) Split the Common Model in several smaller models, a bit similar to 3GPP IRPs. Keep the Common Model for the base objects (base and nrb). Introduce a schedule Definition model with only SD. Introduce a File Transfer model with only ManagementJob and the service interface. All those models would have a dependency on the base Common Model. Note also that the File Transfer model would have a dependency on Schedule, but this can easily be handled by adding the right dependency module. >> Then for PM, we need Schedule + FT, we pick the 2 modules from a central place or library. If schedule only is needed, then just pick its module. >> >> The second approach seems the most promising but it is worth more discussion before implementing it. This is what we did agree in the meeting: to have this additional discussion. >> >> Best regards >> >> Marc >> -----Original Message----- >> From: Pierre Gauthier [mailto:pga...@tm...] >> Sent: Thursday, June 28, 2012 6:31 AM >> To: Craig Gallen (opennms) >> Cc: Flauw, Marc; openoss-devel >> Subject: Re: [Openoss-devel] Abstract Facades in common model >> >> Hi, >> >> What would be the consequence of making the common model "concrete" with the assumption that the specific APIs would extend this concrete model. >> >> Pierre >> On Jun 27, 2012, at 10:32 AM, Craig Gallen (opennms) wrote: >> >>> Hi, >>> >>> Yes, The problem is that in every model, the generated marshalling >>> and marshalling code expects there to be a corresponding set of JAXB >>> classes which are generated from the model xsd/wsdl which the soap >>> generator creates. In a number of models, abstract interfaces are >>> created but these are extended by WSDL which is actually in the model. >>> However in the new common model case, there is only an abstract >>> interface and no concrete interface. >>> >>> In this case the current soap generator decides not to generate any >>> wsdl for the abstract interface and this leaves the corresponding >>> marshalling code without essential classes. At a minimum we need >>> the soap generator to generate abstract interfaces in the common >>> model even if there is no concrete interface in the model >>> >>> This may lead to a further discussion about possibly having more >>> than one 'common model' if we want to avoid including abstract >>> interfaces in TIP interfaces which don't need them. >>> >>> Hope this helps >>> Cheers >>> >>> Craig >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 27/06/2012 09:25, Flauw, Marc wrote: >>>> Hi Craig, >>>> >>>> So if my understanding is correct, you are asking for a change in the SOAP generator. >>>> >>>> Is it needed to generate wsdl for abstract service interfaces in all cases? >>>> I would assume that if the concrete service interface is present, then everything would be generated in the wsdl of the concrete service interface. >>>> >>>> Do you confirm the only case not covered is the common Model one, i.e. an abstract service interface with no derived concrete interface in the same project? >>>> >>>> Best regards >>>> >>>> Marc >>>> >>>> -----Original Message----- >>>> From: Craig Gallen [mailto:gal...@go...] On Behalf >>>> Of Craig Gallen (opennms) >>>> Sent: Tuesday, June 26, 2012 4:59 PM >>>> To: Flauw, Marc >>>> Cc: openoss-devel >>>> Subject: Re: Abstract Facades in common model >>>> >>>> Hi, >>>> >>>> We need to generate the wsdl for the abstract >>>> ManagementJobInterface because the rest of the build of the common >>>> model marshalling and unmarshalling for hte RI/CTK expects there to >>>> be jaxb classes generated from the ManagementJobInterface. These >>>> will be abstract classes which the later concrete classes extend >>>> >>>> Cheers >>>> Craig >>>> >>>> >>>> >>>> >>>> >>>> On 26/06/2012 06:43, Flauw, Marc wrote: >>>>> Craig, >>>>> >>>>> I think you refer to the ManagementJobInterface. It is true this is an abstract interface and it will be inherited by concrete ones in the interfaces using it. >>>>> >>>>> I am not sure to understand why we need to generate the wsdl for it. >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> -----Original Message----- >>>>> From: Craig Gallen [mailto:cg...@we...] >>>>> Sent: Tuesday, June 26, 2012 3:56 AM >>>>> To: Flauw, Marc; openoss-devel >>>>> Subject: Abstract Facades in common model >>>>> >>>>> Hi, >>>>> >>>>> >>>>> The Common model contains an abstract facade but the soap generator does not generate this if there is no super facade. We should be generating the abstract faecal as abstract WSDL otherwise the Common model does not compile correctly. >>>>> >>>>> Craig >>> >>> -------------------------------------------------------------------- >>> - >>> - >>> -------- >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. >>> Discussions will include endpoint security, mobile security and the >>> latest in malware threats. >>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Openoss-devel mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/openoss-devel >>> > |
|
From: Craig G. (opennms) <cg...@op...> - 2012-06-29 15:57:11
|
Marc, Suddenly I think I see the problem. Although you say that ManagmentJob is being passed by ID , this is not what is actually happening when the model is generated. While the individual suspend and resume methods have tipPerimeter passedById=true, the The tipOperation stereotype on ManagementJobInterface is set to bulktransferpattern=NONE. This means that EntityIdentifier is not used and the generated code expects ManagmentJob rather than EntityIdentifier. I think you need to change bulktransferpattern=ID and all will be well. Any feedback from tigerstripe about the bug? Have a good weekend Craig On 29/06/2012 07:39, Flauw, Marc wrote: > Hi Craig, > > There is no polymorphism in the methods of the ManagementJobInterface. Yes, the 3 methods are taking a MJ, but by id and a MJ is never returned by value by those methods. > Suspend and resume have no output param. listAvailableFiles is returning a set of FileDescriptor. > > We left the methods returning MJ data, like create, get, set to the concrete service interfaces. We did agree a while ago on that fact. > > Inventory pattern might introduce polymorphic operations, but those operations would be added by injection 9at least, this is my understanding). > > Best regards > > Marc > > -----Original Message----- > From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms) > Sent: Thursday, June 28, 2012 7:31 PM > To: Flauw, Marc > Cc: Pierre Gauthier; openoss-devel > Subject: Re: [Openoss-devel] Abstract Facades in common model > > Hi, > > Can I add a further point which I have tried to test in the Common Model. It seems that the use of facades which contain methods manipulating abstract entities is a bad idea. We can never extend the interface in a model to have the same methods manage a concrete entity. > This is illustrated by the following example; > > In the common model the new ManagementJobInterface has methods which take the abstract ManagementJob as an argument. Simplified this looks like; ManagementJobInterface.suspend( ManagementJob ...) ManagementJobInterface.resume (ManagementJob ...) ManagementJobInterface.list (ManagementJob ...) > > ManagementJob is abstract which means that in a concrete interface we will need to create a concrete extension to ManagementJob and provide methods which manage the extension. > > However if I create an extension (subclass) of the ManagementJobInterface such that; ManagementJobInterfaceExtended extends ManagementJobInterface > > and give ManagementJobInterfaceExtended the methods ManagementJobInterfaceExtended.suspend( ManagementJobExtension) ManagementJobInterfaceExtended.resume (ManagementJobExtension) ManagementJobInterfaceExtended.list (ManagementJobExtension) > > The resulting WSDL has errors because it has the same method Request and Response types but with different signatures. Similar problems occurr in the generated JVT code. Depending on how this is done we will either end up with WSDL which is unusable or with multiple overloaded methods with different signatures, only one of which is actually needed. Either way it is not satisfactory. > > In short, defining WSDL interface methods for abstract entities does not appear to be a good strategy. We cannot extend the methods in a concrete interface to indicate that they are now working on a child of the abstract entity. ( I know in theory we could just pass the interface an extension class but this introduces some really difficult implementation problems if we don't know before hand what the concrete class actually should be when WSDL marshalling / unmarshalling. You cant instantiate an abstract class and you don't know what concrete class will be presented to the interface ) > > What does this mean? It suggests that a better strategy would be to define ManagementJob as a concrete class which is manipulated by a > (concrete) ManagementJobInterface. However instead of extending ManagementJob for each usage, we create a field inside ManagementJob which contains a datatype ManagementJobDetails. (This is like the specification pattern in the SID). This ManagementJobDetails datatype could be extended in the model without impacting the generated WSDL interface or could simply contain a set of name value pairs. > > I cant think of any other easy solution. What do you think? > > Craig > > > > > > > On 28/06/2012 07:49, Flauw, Marc wrote: >> Pierre, >> >> We had a very long discussion on this topic. It is unfortunate you were not able to make, so let's try to summarize this discussion by mail. >> >> In JOSIF V1.1.1, Common Model was only common exceptions and common notifications. >> For V1.1.2, it has in addition base types, NRB types, Management Job and Schedule Definition. The first 2 are pretty generic, only datatypes and quite aligned with what we had so far in Common Model. >> >> Now with the 2 last additions, we are adding full package and FT includes an abstract service interface. Independently it is made concrete or not, Craig would need the wsdl for this interface to be generated. >> >> As all files from Common Model are copied in all generated interface kits, it means all interfaces would now include ManagementJobInterface wsdl. We don't want that in every interface. >> >> So the result of our discussion is that there are 2 possible routes: >> 1) Keep a rich and unique common model, but limit it to data (xsd) only. This means removing the service interface from the common model. In this case, the only way to provide the operations is to add a new stereotype for FT and use injection. This might be complex to achieve, as Common Model has a dependency on Generic Model and it cannot be the other way around. Adding a stereotype for this would require operations in Generic Model that would reference objects in Common Model which is not possible. >> 2) Split the Common Model in several smaller models, a bit similar to 3GPP IRPs. Keep the Common Model for the base objects (base and nrb). Introduce a schedule Definition model with only SD. Introduce a File Transfer model with only ManagementJob and the service interface. All those models would have a dependency on the base Common Model. Note also that the File Transfer model would have a dependency on Schedule, but this can easily be handled by adding the right dependency module. >> Then for PM, we need Schedule + FT, we pick the 2 modules from a central place or library. If schedule only is needed, then just pick its module. >> >> The second approach seems the most promising but it is worth more discussion before implementing it. This is what we did agree in the meeting: to have this additional discussion. >> >> Best regards >> >> Marc >> -----Original Message----- >> From: Pierre Gauthier [mailto:pga...@tm...] >> Sent: Thursday, June 28, 2012 6:31 AM >> To: Craig Gallen (opennms) >> Cc: Flauw, Marc; openoss-devel >> Subject: Re: [Openoss-devel] Abstract Facades in common model >> >> Hi, >> >> What would be the consequence of making the common model "concrete" with the assumption that the specific APIs would extend this concrete model. >> >> Pierre >> On Jun 27, 2012, at 10:32 AM, Craig Gallen (opennms) wrote: >> >>> Hi, >>> >>> Yes, The problem is that in every model, the generated marshalling >>> and marshalling code expects there to be a corresponding set of JAXB >>> classes which are generated from the model xsd/wsdl which the soap >>> generator creates. In a number of models, abstract interfaces are >>> created but these are extended by WSDL which is actually in the model. >>> However in the new common model case, there is only an abstract >>> interface and no concrete interface. >>> >>> In this case the current soap generator decides not to generate any >>> wsdl for the abstract interface and this leaves the corresponding >>> marshalling code without essential classes. At a minimum we need the >>> soap generator to generate abstract interfaces in the common model >>> even if there is no concrete interface in the model >>> >>> This may lead to a further discussion about possibly having more than >>> one 'common model' if we want to avoid including abstract interfaces >>> in TIP interfaces which don't need them. >>> >>> Hope this helps >>> Cheers >>> >>> Craig >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 27/06/2012 09:25, Flauw, Marc wrote: >>>> Hi Craig, >>>> >>>> So if my understanding is correct, you are asking for a change in the SOAP generator. >>>> >>>> Is it needed to generate wsdl for abstract service interfaces in all cases? >>>> I would assume that if the concrete service interface is present, then everything would be generated in the wsdl of the concrete service interface. >>>> >>>> Do you confirm the only case not covered is the common Model one, i.e. an abstract service interface with no derived concrete interface in the same project? >>>> >>>> Best regards >>>> >>>> Marc >>>> >>>> -----Original Message----- >>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of >>>> Craig Gallen (opennms) >>>> Sent: Tuesday, June 26, 2012 4:59 PM >>>> To: Flauw, Marc >>>> Cc: openoss-devel >>>> Subject: Re: Abstract Facades in common model >>>> >>>> Hi, >>>> >>>> We need to generate the wsdl for the abstract ManagementJobInterface >>>> because the rest of the build of the common model marshalling and >>>> unmarshalling for hte RI/CTK expects there to be jaxb classes >>>> generated from the ManagementJobInterface. These will be abstract >>>> classes which the later concrete classes extend >>>> >>>> Cheers >>>> Craig >>>> >>>> >>>> >>>> >>>> >>>> On 26/06/2012 06:43, Flauw, Marc wrote: >>>>> Craig, >>>>> >>>>> I think you refer to the ManagementJobInterface. It is true this is an abstract interface and it will be inherited by concrete ones in the interfaces using it. >>>>> >>>>> I am not sure to understand why we need to generate the wsdl for it. >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> -----Original Message----- >>>>> From: Craig Gallen [mailto:cg...@we...] >>>>> Sent: Tuesday, June 26, 2012 3:56 AM >>>>> To: Flauw, Marc; openoss-devel >>>>> Subject: Abstract Facades in common model >>>>> >>>>> Hi, >>>>> >>>>> >>>>> The Common model contains an abstract facade but the soap generator does not generate this if there is no super facade. We should be generating the abstract faecal as abstract WSDL otherwise the Common model does not compile correctly. >>>>> >>>>> Craig >>> >>> --------------------------------------------------------------------- >>> - >>> -------- >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. >>> Discussions will include endpoint security, mobile security and the >>> latest in malware threats. >>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Openoss-devel mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/openoss-devel >>> > |
|
From: Craig G. (opennms) <cg...@op...> - 2012-06-29 15:41:27
|
Hi, Well done. for getting this far. Getting the project to compile is a very good first step. First, please send all development questions to the openoss-devel list so we have a public record. 1. Difference between TIP_RAM_CompatibilityTestKit and TIP_RAM_CTK The code in the TIP_RAM_CTK is the complete set of generated code with multiple stubs. This code is regenerated on each build. The TIP_RAM_CompatibilityTestKit is intended for developers to copy and extend the generated stubs in the TIP_RAM_CTK into a permanent context which will not be overwritten on each build. Ultimately the TIP_RAM_CompatibilityTestKit will contain a complete test kit with developer added tests etc. 2. Marshalling / Unmarshalling Soap - video explanations The marshalling is explained in the videos referenced from http://sourceforge.net/apps/mediawiki/openoss/index.php?title=Release_Plan_1.1.2#JOSIF_Developer_On-Ramp_Training_Schedule Have a look at Deep dive - XML Marshalling Design patterns and generated RI and CTK code http://sourceforge.net/projects/openoss/files/JOSIF/DeveloperOnRamp/JOSIF-developer_On_Ramp_JVT_EJB_design2012-02-09.wmv/download 3. How the conversion works You are right in observing that there are two sets of objects in the system. The JVT (Java Value Type) objects follow a TM Forum OSS/J-like design pattern and are generated directly from the model. Both a JVT interface and implementation classes are generated along with a factory. Stub operation tests for the CTK are also generated from the model. This shows a forwards direction for OSS/J users. The tests are written using these objects so that they are generic and could run against any interface profile (SOAP, Rest etc). You should not work directly with the JAXB objects but use the JVT objects and translate. If there are bug in the translation, we can fix them. The second set of objects in the system are generated using Apache CXF wsdl2java. A visitor design pattern is used to map these JAXB objects to the JVT objects (http://en.wikipedia.org/wiki/Visitor_pattern). This is equivalent to the pattern in OSS/J of offering a base EJB interface which was translated to SOAP/XML for the XVT (XML Value Type) design profile. The conversion and subsequent marshalling and unmarshalling is initiated by org.openoss.xml.JvtJaxbTranslator(). This identifies the type of the class to be translated to and from SOAP and finds an initial instance of the JVT and corresponding JAXB request and response objects. It then recursively traverses the tree of objects to translate between types. To understand the object conversion to/from SOAP have a look at ResourceAlarmRetrievalServiceXmlMapper.java in TIP_RAM_SoapImplGenSrcPackage. This is the generated entry point implementation code for the soap call to ResourceAlarmRetrievalService. It is mapped into Apache CXF's JAX-WS implementation through the generated the spring application context; Model_WSAppContext.xml look at the getResourceAlarms method at line 437 of ResourceAlarmRetrievalServiceXmlMapper.java; @javax.jws.WebService(endpointInterface = "org.tmforum.xml.tip.resource.trouble.alarm.ResourceAlarmRetrievalService") public org.tmforum.xml.tip.resource.trouble.alarm.GetResourceAlarmsResponse getResourceAlarms( org.tmforum.xml.tip.resource.trouble.alarm.GetResourceAlarmsRequest xmlRequest) { ... org.openoss.xml.JvtJaxbTranslator jvtJaxbTranslator= new org.openoss.xml.JvtJaxbTranslator(); jvtJaxbTranslator.setLog(getLog()); org.tmforum.tip.org.tmforum.tip.resource.trouble.alarm.GetResourceAlarmsRequest getResourceAlarmsRequest = (org.tmforum.tip.org.tmforum.tip.resource.trouble.alarm.GetResourceAlarmsRequest) jvtJaxbTranslator.toJvtObject(xmlRequest); org.tmforum.tip.org.tmforum.tip.resource.trouble.alarm.GetResourceAlarmsResponse getResourceAlarmsResponse = jvtInterface.getResourceAlarms(getResourceAlarmsRequest); return (org.tmforum.xml.tip.resource.trouble.alarm.GetResourceAlarmsResponse)jvtJaxbTranslator.toJaxbObject(getResourceAlarmsResponse); ... } Hope this helps Craig On 29/06/2012 12:48, Flauw, Marc wrote: > > Kannan, > > I don't know. Craig should be able to answer you on these points. > > Best regards > > Marc > > *From:*KARTHIK KANNAN [mailto:kan...@gm...] > *Sent:* Friday, June 29, 2012 1:33 PM > *To:* Flauw, Marc > *Cc:* sitaraman > *Subject:* Re: Missing TIP_RAM_DocSpecPackage-1.0.2.jar (latest) > > Thanks for replying. > > We have managed to get the RI and CTK working and we are able to make > the CTK on one machine to communicate with RI on another machine. > > Note : We are using TIP_RAM_CTK and not TIP_RAM_CompatibilityTestKit. > > From our understanding, the RI sends the RAM objects to CTK in SOAP > format. Once, the CTK receives the SOAP object, does it convert it > into a RAM object? > > If so, can you point to the part of the code where this conversion > take place. > > If not, please point to the part where the SOAP message is received, > so that we can parse it and build the RAM object. > > Thanks again, for all your help. > > With Regards > > > K.KARTHIK > 9677052524 > > > > On Wed, Jun 27, 2012 at 2:31 PM, Flauw, Marc <Mar...@hp... > <mailto:Mar...@hp...>> wrote: > > Kannan, > > This is not downloaded but built by the build process. Check the > Tigerstripe.xml of your model project and go to the generator settings > and check that it is correctly configured with 1.0.2 > > If this error occurs during the eclipse:eclipse built, then try doing > the clean install and it has good chances of going away. > > Best regards > > Marc > > *From:*KARTHIK KANNAN [mailto:kan...@gm... > <mailto:kan...@gm...>] > *Sent:* Wednesday, June 27, 2012 10:56 AM > *To:* Flauw, Marc > *Cc:* sitaraman > *Subject:* Missing TIP_RAM_DocSpecPackage-1.0.2.jar (latest) > > Hi Marc, > > This is Karthik here. I am working with Dr.Sitaraman and we have > communicated before regarding TIP RAM project. > > While we were trying to build the code, Maven tried to download > TIP_RAM_DocSpecPackage-1.0.2.jar but failed. Can you point to us to > the site, from where we can download this. > > We have TIP_RAM_DocSpecPackage-1.0.1.jar with us. Can we use this as a > replacement for TIP_RAM_DocSpecPackage-1.0.2.jar > > With Regards > > > K.KARTHIK > 9677052524 > |
|
From: Flauw, M. <Mar...@hp...> - 2012-06-29 15:39:19
|
_______________________________________________ tigerstripe-dev mailing list tig...@ec... https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev |
|
From: Flauw, M. <Mar...@hp...> - 2012-06-29 06:40:55
|
Hi Craig, There is no polymorphism in the methods of the ManagementJobInterface. Yes, the 3 methods are taking a MJ, but by id and a MJ is never returned by value by those methods. Suspend and resume have no output param. listAvailableFiles is returning a set of FileDescriptor. We left the methods returning MJ data, like create, get, set to the concrete service interfaces. We did agree a while ago on that fact. Inventory pattern might introduce polymorphic operations, but those operations would be added by injection 9at least, this is my understanding). Best regards Marc -----Original Message----- From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms) Sent: Thursday, June 28, 2012 7:31 PM To: Flauw, Marc Cc: Pierre Gauthier; openoss-devel Subject: Re: [Openoss-devel] Abstract Facades in common model Hi, Can I add a further point which I have tried to test in the Common Model. It seems that the use of facades which contain methods manipulating abstract entities is a bad idea. We can never extend the interface in a model to have the same methods manage a concrete entity. This is illustrated by the following example; In the common model the new ManagementJobInterface has methods which take the abstract ManagementJob as an argument. Simplified this looks like; ManagementJobInterface.suspend( ManagementJob ...) ManagementJobInterface.resume (ManagementJob ...) ManagementJobInterface.list (ManagementJob ...) ManagementJob is abstract which means that in a concrete interface we will need to create a concrete extension to ManagementJob and provide methods which manage the extension. However if I create an extension (subclass) of the ManagementJobInterface such that; ManagementJobInterfaceExtended extends ManagementJobInterface and give ManagementJobInterfaceExtended the methods ManagementJobInterfaceExtended.suspend( ManagementJobExtension) ManagementJobInterfaceExtended.resume (ManagementJobExtension) ManagementJobInterfaceExtended.list (ManagementJobExtension) The resulting WSDL has errors because it has the same method Request and Response types but with different signatures. Similar problems occurr in the generated JVT code. Depending on how this is done we will either end up with WSDL which is unusable or with multiple overloaded methods with different signatures, only one of which is actually needed. Either way it is not satisfactory. In short, defining WSDL interface methods for abstract entities does not appear to be a good strategy. We cannot extend the methods in a concrete interface to indicate that they are now working on a child of the abstract entity. ( I know in theory we could just pass the interface an extension class but this introduces some really difficult implementation problems if we don't know before hand what the concrete class actually should be when WSDL marshalling / unmarshalling. You cant instantiate an abstract class and you don't know what concrete class will be presented to the interface ) What does this mean? It suggests that a better strategy would be to define ManagementJob as a concrete class which is manipulated by a (concrete) ManagementJobInterface. However instead of extending ManagementJob for each usage, we create a field inside ManagementJob which contains a datatype ManagementJobDetails. (This is like the specification pattern in the SID). This ManagementJobDetails datatype could be extended in the model without impacting the generated WSDL interface or could simply contain a set of name value pairs. I cant think of any other easy solution. What do you think? Craig On 28/06/2012 07:49, Flauw, Marc wrote: > Pierre, > > We had a very long discussion on this topic. It is unfortunate you were not able to make, so let's try to summarize this discussion by mail. > > In JOSIF V1.1.1, Common Model was only common exceptions and common notifications. > For V1.1.2, it has in addition base types, NRB types, Management Job and Schedule Definition. The first 2 are pretty generic, only datatypes and quite aligned with what we had so far in Common Model. > > Now with the 2 last additions, we are adding full package and FT includes an abstract service interface. Independently it is made concrete or not, Craig would need the wsdl for this interface to be generated. > > As all files from Common Model are copied in all generated interface kits, it means all interfaces would now include ManagementJobInterface wsdl. We don't want that in every interface. > > So the result of our discussion is that there are 2 possible routes: > 1) Keep a rich and unique common model, but limit it to data (xsd) only. This means removing the service interface from the common model. In this case, the only way to provide the operations is to add a new stereotype for FT and use injection. This might be complex to achieve, as Common Model has a dependency on Generic Model and it cannot be the other way around. Adding a stereotype for this would require operations in Generic Model that would reference objects in Common Model which is not possible. > 2) Split the Common Model in several smaller models, a bit similar to 3GPP IRPs. Keep the Common Model for the base objects (base and nrb). Introduce a schedule Definition model with only SD. Introduce a File Transfer model with only ManagementJob and the service interface. All those models would have a dependency on the base Common Model. Note also that the File Transfer model would have a dependency on Schedule, but this can easily be handled by adding the right dependency module. > Then for PM, we need Schedule + FT, we pick the 2 modules from a central place or library. If schedule only is needed, then just pick its module. > > The second approach seems the most promising but it is worth more discussion before implementing it. This is what we did agree in the meeting: to have this additional discussion. > > Best regards > > Marc > -----Original Message----- > From: Pierre Gauthier [mailto:pga...@tm...] > Sent: Thursday, June 28, 2012 6:31 AM > To: Craig Gallen (opennms) > Cc: Flauw, Marc; openoss-devel > Subject: Re: [Openoss-devel] Abstract Facades in common model > > Hi, > > What would be the consequence of making the common model "concrete" with the assumption that the specific APIs would extend this concrete model. > > Pierre > On Jun 27, 2012, at 10:32 AM, Craig Gallen (opennms) wrote: > >> Hi, >> >> Yes, The problem is that in every model, the generated marshalling >> and marshalling code expects there to be a corresponding set of JAXB >> classes which are generated from the model xsd/wsdl which the soap >> generator creates. In a number of models, abstract interfaces are >> created but these are extended by WSDL which is actually in the model. >> However in the new common model case, there is only an abstract >> interface and no concrete interface. >> >> In this case the current soap generator decides not to generate any >> wsdl for the abstract interface and this leaves the corresponding >> marshalling code without essential classes. At a minimum we need the >> soap generator to generate abstract interfaces in the common model >> even if there is no concrete interface in the model >> >> This may lead to a further discussion about possibly having more than >> one 'common model' if we want to avoid including abstract interfaces >> in TIP interfaces which don't need them. >> >> Hope this helps >> Cheers >> >> Craig >> >> >> >> >> >> >> >> >> >> >> On 27/06/2012 09:25, Flauw, Marc wrote: >>> Hi Craig, >>> >>> So if my understanding is correct, you are asking for a change in the SOAP generator. >>> >>> Is it needed to generate wsdl for abstract service interfaces in all cases? >>> I would assume that if the concrete service interface is present, then everything would be generated in the wsdl of the concrete service interface. >>> >>> Do you confirm the only case not covered is the common Model one, i.e. an abstract service interface with no derived concrete interface in the same project? >>> >>> Best regards >>> >>> Marc >>> >>> -----Original Message----- >>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of >>> Craig Gallen (opennms) >>> Sent: Tuesday, June 26, 2012 4:59 PM >>> To: Flauw, Marc >>> Cc: openoss-devel >>> Subject: Re: Abstract Facades in common model >>> >>> Hi, >>> >>> We need to generate the wsdl for the abstract ManagementJobInterface >>> because the rest of the build of the common model marshalling and >>> unmarshalling for hte RI/CTK expects there to be jaxb classes >>> generated from the ManagementJobInterface. These will be abstract >>> classes which the later concrete classes extend >>> >>> Cheers >>> Craig >>> >>> >>> >>> >>> >>> On 26/06/2012 06:43, Flauw, Marc wrote: >>>> Craig, >>>> >>>> I think you refer to the ManagementJobInterface. It is true this is an abstract interface and it will be inherited by concrete ones in the interfaces using it. >>>> >>>> I am not sure to understand why we need to generate the wsdl for it. >>>> >>>> Best regards >>>> >>>> Marc >>>> >>>> -----Original Message----- >>>> From: Craig Gallen [mailto:cg...@we...] >>>> Sent: Tuesday, June 26, 2012 3:56 AM >>>> To: Flauw, Marc; openoss-devel >>>> Subject: Abstract Facades in common model >>>> >>>> Hi, >>>> >>>> >>>> The Common model contains an abstract facade but the soap generator does not generate this if there is no super facade. We should be generating the abstract faecal as abstract WSDL otherwise the Common model does not compile correctly. >>>> >>>> Craig >> >> >> --------------------------------------------------------------------- >> - >> -------- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. >> Discussions will include endpoint security, mobile security and the >> latest in malware threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Openoss-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openoss-devel >> > |
|
From: Pierre G. <pga...@tm...> - 2012-06-28 20:15:32
|
I think the abstract interface should be defined once and polymorphism must be mandated when you use it. I dont see any problems marshalling or unmarshalling types based on xsi:type. Pierre Le 2012-06-28 à 13:31, "Craig Gallen (opennms)" <cg...@op...> a écrit : > Hi, > > Can I add a further point which I have tried to test in the Common Model. It seems that the use of facades which contain methods manipulating abstract entities is a bad idea. We can never extend the interface in a model to have the same methods manage a concrete entity. This is illustrated by the following example; > > In the common model the new ManagementJobInterface has methods which take the abstract ManagementJob as an argument. Simplified this looks like; > ManagementJobInterface.suspend( ManagementJob ...) > ManagementJobInterface.resume (ManagementJob ...) > ManagementJobInterface.list (ManagementJob ...) > > ManagementJob is abstract which means that in a concrete interface we will need to create a concrete extension to ManagementJob and provide methods which manage the extension. > > However if I create an extension (subclass) of the ManagementJobInterface such that; > ManagementJobInterfaceExtended extends ManagementJobInterface > > and give ManagementJobInterfaceExtended the methods > ManagementJobInterfaceExtended.suspend( ManagementJobExtension) > ManagementJobInterfaceExtended.resume (ManagementJobExtension) > ManagementJobInterfaceExtended.list (ManagementJobExtension) > > The resulting WSDL has errors because it has the same method Request and Response types but with different signatures. Similar problems occurr in the generated JVT code. Depending on how this is done we will either end up with WSDL which is unusable or with multiple overloaded methods with different signatures, only one of which is actually needed. Either way it is not satisfactory. > > In short, defining WSDL interface methods for abstract entities does not appear to be a good strategy. We cannot extend the methods in a concrete interface to indicate that they are now working on a child of the abstract entity. ( I know in theory we could just pass the interface an extension class but this introduces some really difficult implementation problems if we don't know before hand what the concrete class actually should be when WSDL marshalling / unmarshalling. You cant instantiate an abstract class and you don't know what concrete class will be presented to the interface ) > > What does this mean? It suggests that a better strategy would be to define ManagementJob as a concrete class which is manipulated by a (concrete) ManagementJobInterface. However instead of extending ManagementJob for each usage, we create a field inside ManagementJob which contains a datatype ManagementJobDetails. (This is like the specification pattern in the SID). This ManagementJobDetails datatype could be extended in the model without impacting the generated WSDL interface or could simply contain a set of name value pairs. > > I cant think of any other easy solution. What do you think? > > Craig > > > > > > > On 28/06/2012 07:49, Flauw, Marc wrote: >> Pierre, >> >> We had a very long discussion on this topic. It is unfortunate you were not able to make, so let's try to summarize this discussion by mail. >> >> In JOSIF V1.1.1, Common Model was only common exceptions and common notifications. >> For V1.1.2, it has in addition base types, NRB types, Management Job and Schedule Definition. The first 2 are pretty generic, only datatypes and quite aligned with what we had so far in Common Model. >> >> Now with the 2 last additions, we are adding full package and FT includes an abstract service interface. Independently it is made concrete or not, Craig would need the wsdl for this interface to be generated. >> >> As all files from Common Model are copied in all generated interface kits, it means all interfaces would now include ManagementJobInterface wsdl. We don't want that in every interface. >> >> So the result of our discussion is that there are 2 possible routes: >> 1) Keep a rich and unique common model, but limit it to data (xsd) only. This means removing the service interface from the common model. In this case, the only way to provide the operations is to add a new stereotype for FT and use injection. This might be complex to achieve, as Common Model has a dependency on Generic Model and it cannot be the other way around. Adding a stereotype for this would require operations in Generic Model that would reference objects in Common Model which is not possible. >> 2) Split the Common Model in several smaller models, a bit similar to 3GPP IRPs. Keep the Common Model for the base objects (base and nrb). Introduce a schedule Definition model with only SD. Introduce a File Transfer model with only ManagementJob and the service interface. All those models would have a dependency on the base Common Model. Note also that the File Transfer model would have a dependency on Schedule, but this can easily be handled by adding the right dependency module. >> Then for PM, we need Schedule + FT, we pick the 2 modules from a central place or library. If schedule only is needed, then just pick its module. >> >> The second approach seems the most promising but it is worth more discussion before implementing it. This is what we did agree in the meeting: to have this additional discussion. >> >> Best regards >> >> Marc >> -----Original Message----- >> From: Pierre Gauthier [mailto:pga...@tm...] >> Sent: Thursday, June 28, 2012 6:31 AM >> To: Craig Gallen (opennms) >> Cc: Flauw, Marc; openoss-devel >> Subject: Re: [Openoss-devel] Abstract Facades in common model >> >> Hi, >> >> What would be the consequence of making the common model "concrete" with the assumption that the specific APIs would extend this concrete model. >> >> Pierre >> On Jun 27, 2012, at 10:32 AM, Craig Gallen (opennms) wrote: >> >>> Hi, >>> >>> Yes, The problem is that in every model, the generated marshalling >>> and marshalling code expects there to be a corresponding set of JAXB >>> classes which are generated from the model xsd/wsdl which the soap >>> generator creates. In a number of models, abstract interfaces are >>> created but these are extended by WSDL which is actually in the model. >>> However in the new common model case, there is only an abstract >>> interface and no concrete interface. >>> >>> In this case the current soap generator decides not to generate any >>> wsdl for the abstract interface and this leaves the corresponding >>> marshalling code without essential classes. At a minimum we need the >>> soap generator to generate abstract interfaces in the common model >>> even if there is no concrete interface in the model >>> >>> This may lead to a further discussion about possibly having more than >>> one 'common model' if we want to avoid including abstract interfaces >>> in TIP interfaces which don't need them. >>> >>> Hope this helps >>> Cheers >>> >>> Craig >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 27/06/2012 09:25, Flauw, Marc wrote: >>>> Hi Craig, >>>> >>>> So if my understanding is correct, you are asking for a change in the SOAP generator. >>>> >>>> Is it needed to generate wsdl for abstract service interfaces in all cases? >>>> I would assume that if the concrete service interface is present, then everything would be generated in the wsdl of the concrete service interface. >>>> >>>> Do you confirm the only case not covered is the common Model one, i.e. an abstract service interface with no derived concrete interface in the same project? >>>> >>>> Best regards >>>> >>>> Marc >>>> >>>> -----Original Message----- >>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of >>>> Craig Gallen (opennms) >>>> Sent: Tuesday, June 26, 2012 4:59 PM >>>> To: Flauw, Marc >>>> Cc: openoss-devel >>>> Subject: Re: Abstract Facades in common model >>>> >>>> Hi, >>>> >>>> We need to generate the wsdl for the abstract ManagementJobInterface >>>> because the rest of the build of the common model marshalling and >>>> unmarshalling for hte RI/CTK expects there to be jaxb classes >>>> generated from the ManagementJobInterface. These will be abstract >>>> classes which the later concrete classes extend >>>> >>>> Cheers >>>> Craig >>>> >>>> >>>> >>>> >>>> >>>> On 26/06/2012 06:43, Flauw, Marc wrote: >>>>> Craig, >>>>> >>>>> I think you refer to the ManagementJobInterface. It is true this is an abstract interface and it will be inherited by concrete ones in the interfaces using it. >>>>> >>>>> I am not sure to understand why we need to generate the wsdl for it. >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> -----Original Message----- >>>>> From: Craig Gallen [mailto:cg...@we...] >>>>> Sent: Tuesday, June 26, 2012 3:56 AM >>>>> To: Flauw, Marc; openoss-devel >>>>> Subject: Abstract Facades in common model >>>>> >>>>> Hi, >>>>> >>>>> >>>>> The Common model contains an abstract facade but the soap generator does not generate this if there is no super facade. We should be generating the abstract faecal as abstract WSDL otherwise the Common model does not compile correctly. >>>>> >>>>> Craig >>> >>> >>> ---------------------------------------------------------------------- >>> -------- >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. >>> Discussions will include endpoint security, mobile security and the >>> latest in malware threats. >>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Openoss-devel mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/openoss-devel >>> >> > > > |
|
From: Craig G. (opennms) <cg...@op...> - 2012-06-28 17:31:08
|
Hi, Can I add a further point which I have tried to test in the Common Model. It seems that the use of facades which contain methods manipulating abstract entities is a bad idea. We can never extend the interface in a model to have the same methods manage a concrete entity. This is illustrated by the following example; In the common model the new ManagementJobInterface has methods which take the abstract ManagementJob as an argument. Simplified this looks like; ManagementJobInterface.suspend( ManagementJob ...) ManagementJobInterface.resume (ManagementJob ...) ManagementJobInterface.list (ManagementJob ...) ManagementJob is abstract which means that in a concrete interface we will need to create a concrete extension to ManagementJob and provide methods which manage the extension. However if I create an extension (subclass) of the ManagementJobInterface such that; ManagementJobInterfaceExtended extends ManagementJobInterface and give ManagementJobInterfaceExtended the methods ManagementJobInterfaceExtended.suspend( ManagementJobExtension) ManagementJobInterfaceExtended.resume (ManagementJobExtension) ManagementJobInterfaceExtended.list (ManagementJobExtension) The resulting WSDL has errors because it has the same method Request and Response types but with different signatures. Similar problems occurr in the generated JVT code. Depending on how this is done we will either end up with WSDL which is unusable or with multiple overloaded methods with different signatures, only one of which is actually needed. Either way it is not satisfactory. In short, defining WSDL interface methods for abstract entities does not appear to be a good strategy. We cannot extend the methods in a concrete interface to indicate that they are now working on a child of the abstract entity. ( I know in theory we could just pass the interface an extension class but this introduces some really difficult implementation problems if we don't know before hand what the concrete class actually should be when WSDL marshalling / unmarshalling. You cant instantiate an abstract class and you don't know what concrete class will be presented to the interface ) What does this mean? It suggests that a better strategy would be to define ManagementJob as a concrete class which is manipulated by a (concrete) ManagementJobInterface. However instead of extending ManagementJob for each usage, we create a field inside ManagementJob which contains a datatype ManagementJobDetails. (This is like the specification pattern in the SID). This ManagementJobDetails datatype could be extended in the model without impacting the generated WSDL interface or could simply contain a set of name value pairs. I cant think of any other easy solution. What do you think? Craig On 28/06/2012 07:49, Flauw, Marc wrote: > Pierre, > > We had a very long discussion on this topic. It is unfortunate you were not able to make, so let's try to summarize this discussion by mail. > > In JOSIF V1.1.1, Common Model was only common exceptions and common notifications. > For V1.1.2, it has in addition base types, NRB types, Management Job and Schedule Definition. The first 2 are pretty generic, only datatypes and quite aligned with what we had so far in Common Model. > > Now with the 2 last additions, we are adding full package and FT includes an abstract service interface. Independently it is made concrete or not, Craig would need the wsdl for this interface to be generated. > > As all files from Common Model are copied in all generated interface kits, it means all interfaces would now include ManagementJobInterface wsdl. We don't want that in every interface. > > So the result of our discussion is that there are 2 possible routes: > 1) Keep a rich and unique common model, but limit it to data (xsd) only. This means removing the service interface from the common model. In this case, the only way to provide the operations is to add a new stereotype for FT and use injection. This might be complex to achieve, as Common Model has a dependency on Generic Model and it cannot be the other way around. Adding a stereotype for this would require operations in Generic Model that would reference objects in Common Model which is not possible. > 2) Split the Common Model in several smaller models, a bit similar to 3GPP IRPs. Keep the Common Model for the base objects (base and nrb). Introduce a schedule Definition model with only SD. Introduce a File Transfer model with only ManagementJob and the service interface. All those models would have a dependency on the base Common Model. Note also that the File Transfer model would have a dependency on Schedule, but this can easily be handled by adding the right dependency module. > Then for PM, we need Schedule + FT, we pick the 2 modules from a central place or library. If schedule only is needed, then just pick its module. > > The second approach seems the most promising but it is worth more discussion before implementing it. This is what we did agree in the meeting: to have this additional discussion. > > Best regards > > Marc > -----Original Message----- > From: Pierre Gauthier [mailto:pga...@tm...] > Sent: Thursday, June 28, 2012 6:31 AM > To: Craig Gallen (opennms) > Cc: Flauw, Marc; openoss-devel > Subject: Re: [Openoss-devel] Abstract Facades in common model > > Hi, > > What would be the consequence of making the common model "concrete" with the assumption that the specific APIs would extend this concrete model. > > Pierre > On Jun 27, 2012, at 10:32 AM, Craig Gallen (opennms) wrote: > >> Hi, >> >> Yes, The problem is that in every model, the generated marshalling >> and marshalling code expects there to be a corresponding set of JAXB >> classes which are generated from the model xsd/wsdl which the soap >> generator creates. In a number of models, abstract interfaces are >> created but these are extended by WSDL which is actually in the model. >> However in the new common model case, there is only an abstract >> interface and no concrete interface. >> >> In this case the current soap generator decides not to generate any >> wsdl for the abstract interface and this leaves the corresponding >> marshalling code without essential classes. At a minimum we need the >> soap generator to generate abstract interfaces in the common model >> even if there is no concrete interface in the model >> >> This may lead to a further discussion about possibly having more than >> one 'common model' if we want to avoid including abstract interfaces >> in TIP interfaces which don't need them. >> >> Hope this helps >> Cheers >> >> Craig >> >> >> >> >> >> >> >> >> >> >> On 27/06/2012 09:25, Flauw, Marc wrote: >>> Hi Craig, >>> >>> So if my understanding is correct, you are asking for a change in the SOAP generator. >>> >>> Is it needed to generate wsdl for abstract service interfaces in all cases? >>> I would assume that if the concrete service interface is present, then everything would be generated in the wsdl of the concrete service interface. >>> >>> Do you confirm the only case not covered is the common Model one, i.e. an abstract service interface with no derived concrete interface in the same project? >>> >>> Best regards >>> >>> Marc >>> >>> -----Original Message----- >>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of >>> Craig Gallen (opennms) >>> Sent: Tuesday, June 26, 2012 4:59 PM >>> To: Flauw, Marc >>> Cc: openoss-devel >>> Subject: Re: Abstract Facades in common model >>> >>> Hi, >>> >>> We need to generate the wsdl for the abstract ManagementJobInterface >>> because the rest of the build of the common model marshalling and >>> unmarshalling for hte RI/CTK expects there to be jaxb classes >>> generated from the ManagementJobInterface. These will be abstract >>> classes which the later concrete classes extend >>> >>> Cheers >>> Craig >>> >>> >>> >>> >>> >>> On 26/06/2012 06:43, Flauw, Marc wrote: >>>> Craig, >>>> >>>> I think you refer to the ManagementJobInterface. It is true this is an abstract interface and it will be inherited by concrete ones in the interfaces using it. >>>> >>>> I am not sure to understand why we need to generate the wsdl for it. >>>> >>>> Best regards >>>> >>>> Marc >>>> >>>> -----Original Message----- >>>> From: Craig Gallen [mailto:cg...@we...] >>>> Sent: Tuesday, June 26, 2012 3:56 AM >>>> To: Flauw, Marc; openoss-devel >>>> Subject: Abstract Facades in common model >>>> >>>> Hi, >>>> >>>> >>>> The Common model contains an abstract facade but the soap generator does not generate this if there is no super facade. We should be generating the abstract faecal as abstract WSDL otherwise the Common model does not compile correctly. >>>> >>>> Craig >> >> >> ---------------------------------------------------------------------- >> -------- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. >> Discussions will include endpoint security, mobile security and the >> latest in malware threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Openoss-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openoss-devel >> > |
|
From: Flauw, M. <Mar...@hp...> - 2012-06-28 09:22:17
|
_______________________________________________ tigerstripe-dev mailing list tig...@ec... https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev |
|
From: Flauw, M. <Mar...@hp...> - 2012-06-28 09:02:01
|
_______________________________________________ tigerstripe-dev mailing list tig...@ec... https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev |
|
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> |
|
From: Xose R. S. V. <xr...@op...> - 2012-06-28 07:17:56
|
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><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> >>> >> >> > > -- *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> |
|
From: Flauw, M. <Mar...@hp...> - 2012-06-28 06:51:03
|
Pierre, We had a very long discussion on this topic. It is unfortunate you were not able to make, so let's try to summarize this discussion by mail. In JOSIF V1.1.1, Common Model was only common exceptions and common notifications. For V1.1.2, it has in addition base types, NRB types, Management Job and Schedule Definition. The first 2 are pretty generic, only datatypes and quite aligned with what we had so far in Common Model. Now with the 2 last additions, we are adding full package and FT includes an abstract service interface. Independently it is made concrete or not, Craig would need the wsdl for this interface to be generated. As all files from Common Model are copied in all generated interface kits, it means all interfaces would now include ManagementJobInterface wsdl. We don't want that in every interface. So the result of our discussion is that there are 2 possible routes: 1) Keep a rich and unique common model, but limit it to data (xsd) only. This means removing the service interface from the common model. In this case, the only way to provide the operations is to add a new stereotype for FT and use injection. This might be complex to achieve, as Common Model has a dependency on Generic Model and it cannot be the other way around. Adding a stereotype for this would require operations in Generic Model that would reference objects in Common Model which is not possible. 2) Split the Common Model in several smaller models, a bit similar to 3GPP IRPs. Keep the Common Model for the base objects (base and nrb). Introduce a schedule Definition model with only SD. Introduce a File Transfer model with only ManagementJob and the service interface. All those models would have a dependency on the base Common Model. Note also that the File Transfer model would have a dependency on Schedule, but this can easily be handled by adding the right dependency module. Then for PM, we need Schedule + FT, we pick the 2 modules from a central place or library. If schedule only is needed, then just pick its module. The second approach seems the most promising but it is worth more discussion before implementing it. This is what we did agree in the meeting: to have this additional discussion. Best regards Marc -----Original Message----- From: Pierre Gauthier [mailto:pga...@tm...] Sent: Thursday, June 28, 2012 6:31 AM To: Craig Gallen (opennms) Cc: Flauw, Marc; openoss-devel Subject: Re: [Openoss-devel] Abstract Facades in common model Hi, What would be the consequence of making the common model "concrete" with the assumption that the specific APIs would extend this concrete model. Pierre On Jun 27, 2012, at 10:32 AM, Craig Gallen (opennms) wrote: > Hi, > > Yes, The problem is that in every model, the generated marshalling > and marshalling code expects there to be a corresponding set of JAXB > classes which are generated from the model xsd/wsdl which the soap > generator creates. In a number of models, abstract interfaces are > created but these are extended by WSDL which is actually in the model. > However in the new common model case, there is only an abstract > interface and no concrete interface. > > In this case the current soap generator decides not to generate any > wsdl for the abstract interface and this leaves the corresponding > marshalling code without essential classes. At a minimum we need the > soap generator to generate abstract interfaces in the common model > even if there is no concrete interface in the model > > This may lead to a further discussion about possibly having more than > one 'common model' if we want to avoid including abstract interfaces > in TIP interfaces which don't need them. > > Hope this helps > Cheers > > Craig > > > > > > > > > > > On 27/06/2012 09:25, Flauw, Marc wrote: >> Hi Craig, >> >> So if my understanding is correct, you are asking for a change in the SOAP generator. >> >> Is it needed to generate wsdl for abstract service interfaces in all cases? >> I would assume that if the concrete service interface is present, then everything would be generated in the wsdl of the concrete service interface. >> >> Do you confirm the only case not covered is the common Model one, i.e. an abstract service interface with no derived concrete interface in the same project? >> >> Best regards >> >> Marc >> >> -----Original Message----- >> From: Craig Gallen [mailto:gal...@go...] On Behalf Of >> Craig Gallen (opennms) >> Sent: Tuesday, June 26, 2012 4:59 PM >> To: Flauw, Marc >> Cc: openoss-devel >> Subject: Re: Abstract Facades in common model >> >> Hi, >> >> We need to generate the wsdl for the abstract ManagementJobInterface >> because the rest of the build of the common model marshalling and >> unmarshalling for hte RI/CTK expects there to be jaxb classes >> generated from the ManagementJobInterface. These will be abstract >> classes which the later concrete classes extend >> >> Cheers >> Craig >> >> >> >> >> >> On 26/06/2012 06:43, Flauw, Marc wrote: >>> Craig, >>> >>> I think you refer to the ManagementJobInterface. It is true this is an abstract interface and it will be inherited by concrete ones in the interfaces using it. >>> >>> I am not sure to understand why we need to generate the wsdl for it. >>> >>> Best regards >>> >>> Marc >>> >>> -----Original Message----- >>> From: Craig Gallen [mailto:cg...@we...] >>> Sent: Tuesday, June 26, 2012 3:56 AM >>> To: Flauw, Marc; openoss-devel >>> Subject: Abstract Facades in common model >>> >>> Hi, >>> >>> >>> The Common model contains an abstract facade but the soap generator does not generate this if there is no super facade. We should be generating the abstract faecal as abstract WSDL otherwise the Common model does not compile correctly. >>> >>> Craig >> > > > > ---------------------------------------------------------------------- > -------- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions will include endpoint security, mobile security and the > latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Openoss-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openoss-devel > |
|
From: Flauw, M. <Mar...@hp...> - 2012-06-28 06:38:07
|
Pierre, We need Ft and Schedule for PM. There is no point in issuing a V1.1.2 if these features are not present. Best regards Marc From: Pierre Gauthier [mailto:pga...@tm...] Sent: Thursday, June 28, 2012 6:42 AM To: Craig Gallen (opennms) Cc: openoss-devel; Craig Gallen (entimoss); Xo...@do... Subject: Re: [Openoss-devel] Problems with PM XSD generation All, I agree this should be fixed in Tigerstripe and we should NOT move to this new version until this and other related bugs of this new Tigerstripe version are identified and fixed. Pierre On Jun 28, 2012, at 12:32 AM, Craig Gallen (opennms) wrote: 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/> <Mail Attachment.jpeg><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/> <Mail Attachment.jpeg><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/> <Mail Attachment.jpeg><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/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> |
|
From: Flauw, M. <Mar...@hp...> - 2012-06-28 06:20:53
|
Pierre, Our Tigerstripe version is dating back from Feb 2011. I simply announced that Tigerstripe is making a new version available for us so that we can test it. Before doing any regression tests, the minimum is first checking the generators are at least basically working and I think we are at this step now. We don't have structured regression tests yet. We have a serie of test projects, but not fully updated and operational. When using the installer, we have a stable version, both Tigerstripe and generators, but we need to reach a new one with the new Tigerstripe. Best regards Marc From: pierre gauthier [mailto:pie...@gm...] Sent: Thursday, June 28, 2012 6:27 AM To: Flauw, Marc Cc: Xose Ramon Sousa Vazquez; Craig Gallen (opennms); openoss-devel; Craig Gallen (entimoss) Subject: Re: Problems with PM XSD generation Hi Marc, Can you explain why we're moving to a new version of TigerStripe without having executed the proper regression tests ? Regards Pierre On Jun 28, 2012, at 12:17 AM, Craig Gallen (entimoss) wrote: Xose, Thanks for this. I am pretty much stuck until the fix can be made. I tried to go back to the previous tigerstripe version but this no longer works in my workspace. So I cant do anything more until either Tigerstripe or the the Soap generator are fixed. 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/> <Mail Attachment.jpeg><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/> <Mail Attachment.jpeg><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/> <Mail Attachment.jpeg><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/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> |
|
From: Pierre G. <pga...@tm...> - 2012-06-28 04:57:12
|
All, I agree this should be fixed in Tigerstripe and we should NOT move to this new version until this and other related bugs of this new Tigerstripe version are identified and fixed. Pierre On Jun 28, 2012, at 12:32 AM, Craig Gallen (opennms) wrote: 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/> <Mail Attachment.jpeg><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/> <Mail Attachment.jpeg><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/> <Mail Attachment.jpeg><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/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> |
|
From: Craig G. (opennms) <cg...@op...> - 2012-06-28 04:44:13
|
Hi, We discussed this today at the SII call and want to continue the discussion to reach a resolution. There are two issues. If we make an interface concrete in the common model, it will show up as concrete in all of the generated interfaces since the common model XSD's and WSDLs are imported upstream. If we don't want the file management interfaces to be inherited by all interfaces upstream, we need to choose whether to include them or not and this can only be done by creating another 'common model' a model explicitly and only for the interface. We include it if we need it. Craig On 28/06/2012 05:31, Pierre Gauthier wrote: > Hi, > > What would be the consequence of making the common model "concrete" with the > assumption that the specific APIs would extend this concrete model. > > Pierre > On Jun 27, 2012, at 10:32 AM, Craig Gallen (opennms) wrote: > >> Hi, >> >> Yes, The problem is that in every model, the generated marshalling and >> marshalling code expects there to be a corresponding set of JAXB classes >> which are generated from the model xsd/wsdl which the soap generator >> creates. In a number of models, abstract interfaces are created but >> these are extended by WSDL which is actually in the model. However in >> the new common model case, there is only an abstract interface and no >> concrete interface. >> >> In this case the current soap generator decides not to generate any wsdl >> for the abstract interface and this leaves the corresponding marshalling >> code without essential classes. At a minimum we need the soap generator >> to generate abstract interfaces in the common model even if there is no >> concrete interface in the model >> >> This may lead to a further discussion about possibly having more than >> one 'common model' if we want to avoid including abstract interfaces in >> TIP interfaces which don't need them. >> >> Hope this helps >> Cheers >> >> Craig >> >> >> >> >> >> >> >> >> >> >> On 27/06/2012 09:25, Flauw, Marc wrote: >>> Hi Craig, >>> >>> So if my understanding is correct, you are asking for a change in the SOAP generator. >>> >>> Is it needed to generate wsdl for abstract service interfaces in all cases? >>> I would assume that if the concrete service interface is present, then everything would be generated in the wsdl of the concrete service interface. >>> >>> Do you confirm the only case not covered is the common Model one, i.e. an abstract service interface with no derived concrete interface in the same project? >>> >>> Best regards >>> >>> Marc >>> >>> -----Original Message----- >>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms) >>> Sent: Tuesday, June 26, 2012 4:59 PM >>> To: Flauw, Marc >>> Cc: openoss-devel >>> Subject: Re: Abstract Facades in common model >>> >>> Hi, >>> >>> We need to generate the wsdl for the abstract ManagementJobInterface because the rest of the build of the common model marshalling and unmarshalling for hte RI/CTK expects there to be jaxb classes generated from the ManagementJobInterface. These will be abstract classes which the later concrete classes extend >>> >>> Cheers >>> Craig >>> >>> >>> >>> >>> >>> On 26/06/2012 06:43, Flauw, Marc wrote: >>>> Craig, >>>> >>>> I think you refer to the ManagementJobInterface. It is true this is an abstract interface and it will be inherited by concrete ones in the interfaces using it. >>>> >>>> I am not sure to understand why we need to generate the wsdl for it. >>>> >>>> Best regards >>>> >>>> Marc >>>> >>>> -----Original Message----- >>>> From: Craig Gallen [mailto:cg...@we...] >>>> Sent: Tuesday, June 26, 2012 3:56 AM >>>> To: Flauw, Marc; openoss-devel >>>> Subject: Abstract Facades in common model >>>> >>>> Hi, >>>> >>>> >>>> The Common model contains an abstract facade but the soap generator does not generate this if there is no super facade. We should be generating the abstract faecal as abstract WSDL otherwise the Common model does not compile correctly. >>>> >>>> Craig >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Openoss-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openoss-devel >> > |
|
From: Craig G. (opennms) <cg...@op...> - 2012-06-28 04:32:14
|
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><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> >> > > |
|
From: Pierre G. <pga...@tm...> - 2012-06-28 04:31:23
|
Hi, What would be the consequence of making the common model "concrete" with the assumption that the specific APIs would extend this concrete model. Pierre On Jun 27, 2012, at 10:32 AM, Craig Gallen (opennms) wrote: > Hi, > > Yes, The problem is that in every model, the generated marshalling and > marshalling code expects there to be a corresponding set of JAXB classes > which are generated from the model xsd/wsdl which the soap generator > creates. In a number of models, abstract interfaces are created but > these are extended by WSDL which is actually in the model. However in > the new common model case, there is only an abstract interface and no > concrete interface. > > In this case the current soap generator decides not to generate any wsdl > for the abstract interface and this leaves the corresponding marshalling > code without essential classes. At a minimum we need the soap generator > to generate abstract interfaces in the common model even if there is no > concrete interface in the model > > This may lead to a further discussion about possibly having more than > one 'common model' if we want to avoid including abstract interfaces in > TIP interfaces which don't need them. > > Hope this helps > Cheers > > Craig > > > > > > > > > > > On 27/06/2012 09:25, Flauw, Marc wrote: >> Hi Craig, >> >> So if my understanding is correct, you are asking for a change in the SOAP generator. >> >> Is it needed to generate wsdl for abstract service interfaces in all cases? >> I would assume that if the concrete service interface is present, then everything would be generated in the wsdl of the concrete service interface. >> >> Do you confirm the only case not covered is the common Model one, i.e. an abstract service interface with no derived concrete interface in the same project? >> >> Best regards >> >> Marc >> >> -----Original Message----- >> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms) >> Sent: Tuesday, June 26, 2012 4:59 PM >> To: Flauw, Marc >> Cc: openoss-devel >> Subject: Re: Abstract Facades in common model >> >> Hi, >> >> We need to generate the wsdl for the abstract ManagementJobInterface because the rest of the build of the common model marshalling and unmarshalling for hte RI/CTK expects there to be jaxb classes generated from the ManagementJobInterface. These will be abstract classes which the later concrete classes extend >> >> Cheers >> Craig >> >> >> >> >> >> On 26/06/2012 06:43, Flauw, Marc wrote: >>> Craig, >>> >>> I think you refer to the ManagementJobInterface. It is true this is an abstract interface and it will be inherited by concrete ones in the interfaces using it. >>> >>> I am not sure to understand why we need to generate the wsdl for it. >>> >>> Best regards >>> >>> Marc >>> >>> -----Original Message----- >>> From: Craig Gallen [mailto:cg...@we...] >>> Sent: Tuesday, June 26, 2012 3:56 AM >>> To: Flauw, Marc; openoss-devel >>> Subject: Abstract Facades in common model >>> >>> Hi, >>> >>> >>> The Common model contains an abstract facade but the soap generator does not generate this if there is no super facade. We should be generating the abstract faecal as abstract WSDL otherwise the Common model does not compile correctly. >>> >>> Craig >> > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Openoss-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openoss-devel > |
|
From: Craig G. (opennms) <cg...@op...> - 2012-06-27 14:42:31
|
Hi, Thanks for this. This is Josif release currently pointing to the same as the latest tigerstripe version (0.7.0.201206181258) - and is the same one I have been having problems with. Craig On 27/06/2012 14:21, Flauw, Marc wrote: > > *From:*tig...@ec... > [mailto:tig...@ec...] *On Behalf Of *Daniel Johnson > *Sent:* Friday, June 22, 2012 6:26 PM > *To:* Tigerstripe developers list > *Subject:* Re: [tigerstripe-dev] Stable Tigerstripe version > > Hi Marc, > > I have uploaded the latest stable version (I53 build) to a new update > site for you, it is working locally for me. Let me know if you have > any issues. > > http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ > > Thanks, > > Daniel > > On Jun 21, 2012, at 3:00 AM, Flauw, Marc wrote: > > > > Thanks Duncan > > Best regards > > Marc > > *From:*tig...@ec... > <mailto:tig...@ec...> > [mailto:tig...@ec...] > <mailto:[mailto:tig...@ec...]>*On Behalf > Of*dkeysell > *Sent:*Thursday, June 21, 2012 11:51 AM > *To:*Tigerstripe Developers > *Subject:*Re: [tigerstripe-dev] Stable Tigerstripe version > > Hi Marc, > > We will try to create a static update site for you. Once its available > I'll send details. > > Thanks > > Duncan > > > On 21/06/2012 06:48, "Flauw, Marc" <Mar...@hp... > <x-msg://276/Mar...@hp...>> wrote: > > Hi, > > We will be releasing our JOSIF V1.1.2 in July and we would like to > know if Tigerstripe will have a stable version in this timeframe. > It is quite difficult to follow 3 weeks iteration cycle and for our > released version, we would prefer to have that on a more stable > version, given all our generators and our SID Import tool reusing some > of the UML import. > > I sent a mail to Eric a while ago but got no answer. > > Thanks and regards > > Marc > > ------------------------------------------------------------------------ > > _______________________________________________ > tigerstripe-dev mailing list > tig...@ec... <x-msg://276/tig...@ec...> > https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev > > _______________________________________________ > tigerstripe-dev mailing list > tig...@ec... <mailto:tig...@ec...> > https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev > |
|
From: Craig G. (opennms) <cg...@op...> - 2012-06-27 14:33:05
|
Hi, Yes, The problem is that in every model, the generated marshalling and marshalling code expects there to be a corresponding set of JAXB classes which are generated from the model xsd/wsdl which the soap generator creates. In a number of models, abstract interfaces are created but these are extended by WSDL which is actually in the model. However in the new common model case, there is only an abstract interface and no concrete interface. In this case the current soap generator decides not to generate any wsdl for the abstract interface and this leaves the corresponding marshalling code without essential classes. At a minimum we need the soap generator to generate abstract interfaces in the common model even if there is no concrete interface in the model This may lead to a further discussion about possibly having more than one 'common model' if we want to avoid including abstract interfaces in TIP interfaces which don't need them. Hope this helps Cheers Craig On 27/06/2012 09:25, Flauw, Marc wrote: > Hi Craig, > > So if my understanding is correct, you are asking for a change in the SOAP generator. > > Is it needed to generate wsdl for abstract service interfaces in all cases? > I would assume that if the concrete service interface is present, then everything would be generated in the wsdl of the concrete service interface. > > Do you confirm the only case not covered is the common Model one, i.e. an abstract service interface with no derived concrete interface in the same project? > > Best regards > > Marc > > -----Original Message----- > From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms) > Sent: Tuesday, June 26, 2012 4:59 PM > To: Flauw, Marc > Cc: openoss-devel > Subject: Re: Abstract Facades in common model > > Hi, > > We need to generate the wsdl for the abstract ManagementJobInterface because the rest of the build of the common model marshalling and unmarshalling for hte RI/CTK expects there to be jaxb classes generated from the ManagementJobInterface. These will be abstract classes which the later concrete classes extend > > Cheers > Craig > > > > > > On 26/06/2012 06:43, Flauw, Marc wrote: >> Craig, >> >> I think you refer to the ManagementJobInterface. It is true this is an abstract interface and it will be inherited by concrete ones in the interfaces using it. >> >> I am not sure to understand why we need to generate the wsdl for it. >> >> Best regards >> >> Marc >> >> -----Original Message----- >> From: Craig Gallen [mailto:cg...@we...] >> Sent: Tuesday, June 26, 2012 3:56 AM >> To: Flauw, Marc; openoss-devel >> Subject: Abstract Facades in common model >> >> Hi, >> >> >> The Common model contains an abstract facade but the soap generator does not generate this if there is no super facade. We should be generating the abstract faecal as abstract WSDL otherwise the Common model does not compile correctly. >> >> Craig > |
|
From: Xose R. S. V. <xr...@op...> - 2012-06-27 09:02:05
|
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><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> |
|
From: Flauw, M. <Mar...@hp...> - 2012-06-27 08:27:05
|
Hi Craig, So if my understanding is correct, you are asking for a change in the SOAP generator. Is it needed to generate wsdl for abstract service interfaces in all cases? I would assume that if the concrete service interface is present, then everything would be generated in the wsdl of the concrete service interface. Do you confirm the only case not covered is the common Model one, i.e. an abstract service interface with no derived concrete interface in the same project? Best regards Marc -----Original Message----- From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms) Sent: Tuesday, June 26, 2012 4:59 PM To: Flauw, Marc Cc: openoss-devel Subject: Re: Abstract Facades in common model Hi, We need to generate the wsdl for the abstract ManagementJobInterface because the rest of the build of the common model marshalling and unmarshalling for hte RI/CTK expects there to be jaxb classes generated from the ManagementJobInterface. These will be abstract classes which the later concrete classes extend Cheers Craig On 26/06/2012 06:43, Flauw, Marc wrote: > Craig, > > I think you refer to the ManagementJobInterface. It is true this is an abstract interface and it will be inherited by concrete ones in the interfaces using it. > > I am not sure to understand why we need to generate the wsdl for it. > > Best regards > > Marc > > -----Original Message----- > From: Craig Gallen [mailto:cg...@we...] > Sent: Tuesday, June 26, 2012 3:56 AM > To: Flauw, Marc; openoss-devel > Subject: Abstract Facades in common model > > Hi, > > > The Common model contains an abstract facade but the soap generator does not generate this if there is no super facade. We should be generating the abstract faecal as abstract WSDL otherwise the Common model does not compile correctly. > > Craig |
|
From: Pierre g. <pie...@os...> - 2012-06-26 17:23:26
|
Hi Craig, Looks like we have regression testing issues with this Tigerstripe version. Can we wait until we finish regression testing before moving to this version of TigerStripe ? Also what is the status of the build ? Pierre Le 2012-06-26 à 11:03, "Craig Gallen (entimoss)" <cra...@en...> a écrit : > 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)) { >>>>>> |
197 messages has been excluded from this view by a project administrator.
