Issue 7639: section 7.3, p.44, example IDL (mof2idl-ftf) Source: Vanderbilt University (Mr. Jeff Parsons, j.parsons@vanderbilt.edu) Nature: Uncategorized Issue Severity: Summary: forward declared exception (MofError) For now I have instead forward declared MOFObject so I can fully define MofError before the full definition of MOFObject. abstract valuetype (MOFState) has a state member For now I have removed the 'abstract' qualifier. Resolution: Revised Text: Resolution: The abstract modifier of MOFState is in principle wrong and should be removed. This change also resolves issue 7653, since then all derived valuetypes can be declared as "truncatable". Revised Text: This issue is resolved by changing the definition of valuetype MOFState to: valuetype MOFState supports MOFObject { private MOFObject origin; }; This change effects the following section in the specification document: · Section 6.2.2. IDL excerpt must be as described above · Section 7.3: the definition must be changed as described above. This resolution also resolves issue 7653 Actions taken: August 19, 2004: received issue August 1, 2005: closed issue Discussion: End of Annotations:===== ubject: mapping questions Date: Thu, 19 Aug 2004 12:14:48 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mapping questions Thread-Index: AcSGEAfpYhJY+XFITWinW6OkBAEQEQ== From: "Jeff Parsons" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7JHRelj029185 Hi, I understand that there will be some changes to the mapping in the finalization process. However, I'm starting work on a MOF model repository based on the IDL mapping (CMOF, CCM version) so it would be great if I could at least get a sense of where things might be headed. I'm sure I'll have a long list of questions before this project is done, but here are a few to start with: (All the following questions refer to ptc/04-07-01) section 7.3, p.44, example IDL forward declared exception (MofError) For now I have instead forward declared MOFObject so I can fully define MofError before the full definition of MOFObject. abstract valuetype (MOFState) has a state member Subject: mapping questions Date: Thu, 19 Aug 2004 12:14:48 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mapping questions Thread-Index: AcSGEAfpYhJY+XFITWinW6OkBAEQEQ== From: "Jeff Parsons" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7JHRelj029185 Hi, I understand that there will be some changes to the mapping in the finalization process. However, I'm starting work on a MOF model repository based on the IDL mapping (CMOF, CCM version) so it would be great if I could at least get a sense of where things might be headed. I'm sure I'll have a long list of questions before this project is done, but here are a few to start with: (All the following questions refer to ptc/04-07-01) section 7.3, p.44, example IDL forward declared exception (MofError) For now I have instead forward declared MOFObject so I can fully define MofError before the full definition of MOFObject. abstract valuetype (MOFState) has a state member For now I have removed the 'abstract' qualifier. section 6.3.3, p.31, example IDL The operations shown in the example for mapping of associations don't seem to gibe with the operations described section 7.6.3, pp.59-61. The CCM version of the mapping has components supporting abstract interfaces. There is some discussion where I work about whether or not this will have dire consequences. Such a case was throwing an error in our IDL compiler - someone must have thought it was a no-no. For the record, it seems ok to me for components to do this, but I wanted to get some more input on the matter. I guess it boils down to the question of whether it would ever be necessary to narrow to a component's supported interface, or to pass one over the wire as a CORBA::Object. thanks, Subject: Re: issues 7639 - 7640 -- abstract interfaces and components Date: Mon, 23 Aug 2004 16:20:23 +0200 Organization: Fraunhofer FOKUS X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSJHFO1XOHAdPyUTwWdT/X86v111Q== Hi Jeff, sorry for answering your questions/issues that late, but I've been on vacations for three weeks and my eMail stack is rather high;) First of all, I'm happy that someone can give us feedback, since our group is rather small and only a few people seems to be interested in what we are doing - so I appreciate every comment, remark, bug you can report. To your issues: > ===================================================== > This is issue # 7639 > >section 7.3, p.44, example IDL > > forward declared exception (MofError) > > For now I have instead forward declared MOFObject so I can > fully define MofError before the full definition of MOFObject. > > > abstract valuetype (MOFState) has a state member > > For now I have removed the 'abstract' qualifier. In principle, the IDL in ad/04-01-17 (extra IDL sources for MOF2CMM) should be correct and compile-able (we tested it with the QEDO (www.qedo.org OpenSource CCM implementation). For now I have removed the 'abstract' qualifier.