Issue 3752: bug in the Telecom Log Service IDL (log_service-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: I have just noticed a bug in the Telecom Log Service IDL. The "Log" interface defined in the "DsLogAdmin" module defines "set_qos" and "get_qos" operations. And, the DsNotifyLogAdmin::NotifyLog interface inherits both the DsLogAdmin::Log interface (indirectly, through inheritence of DsEventLogAdmin::EventLog) and the CosNotifyChannelAdmin::EventChannel interface. Note that the CosNotifyChannelAdmin::EventChannel interface inherits from CosNotification::QoSAdmin, which also defines "set_qos" and "get_qos" operations! This is invalid IDL inheritence as of CORBA 2.3! The same problem exists for the DsTypedNotifyLogAdmin::TypedNotifyLog interface. It indirectly inherits both DsLogAdmin::Log and CosNotification::QoSAdmin, and thus two versions of "set_qos" and "get_qos". There are a couple of possible solutions to this problem, but perhaps the easiest would be to simply rename the "set_qos" and "get_qos" operations defined in the Log interface as "set_log_qos" and "get_log_qos", respectively. If only there were an RTF that could do this... :-) Resolution: see above Revised Text: Subsequent edition efforts at sections 2.2.4.10 and in the Appendix A should follow Actions taken: July 19, 2000: received issue October 23, 2002: closed issue Discussion: The issue is pretty simple and the easiest solution to resolve it is to rename the set/get_qos operations in the DsLogAdmin::Log by, respectively, set_log_qos and get_log_qos. End of Annotations:===== Reply-To: From: "Michael Greenberg" To: , Cc: Subject: Bug in the Telecom Log Service... Date: Wed, 19 Jul 2000 16:40:15 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 5i1e9m>4!!:AMe9)(Wd9 Hello, I have just noticed a bug in the Telecom Log Service IDL. The "Log" interface defined in the "DsLogAdmin" module defines "set_qos" and "get_qos" operations. And, the DsNotifyLogAdmin::NotifyLog interface inherits both the DsLogAdmin::Log interface (indirectly, through inheritence of DsEventLogAdmin::EventLog) and the CosNotifyChannelAdmin::EventChannel interface. Note that the CosNotifyChannelAdmin::EventChannel interface inherits from CosNotification::QoSAdmin, which also defines "set_qos" and "get_qos" operations! This is invalid IDL inheritence as of CORBA 2.3! The same problem exists for the DsTypedNotifyLogAdmin::TypedNotifyLog interface. It indirectly inherits both DsLogAdmin::Log and CosNotification::QoSAdmin, and thus two versions of "set_qos" and "get_qos". There are a couple of possible solutions to this problem, but perhaps the easiest would be to simply rename the "set_qos" and "get_qos" operations defined in the Log interface as "set_log_qos" and "get_log_qos", respectively. If only there were an RTF that could do this... :-) Regards, Mike P.S. Some of you may recognize my name. I was formerly with NEC... :-) -- Michael J. Greenberg IONA Technologies, Inc. 200 West Street Waltham, MA 02451 Ph: (781)-902-8160 Reply-To: From: "Mike Greenberg" To: Subject: FW: CORBA 2.3 Telecom Log Service IDL compliance Date: Wed, 9 Jan 2002 10:28:36 -0500 Message-ID: <002c01c19922$4f373340$9085413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: p -----Original Message----- > From: Mike Greenberg [mailto:michael.greenberg@iona.com] > Sent: Wednesday, January 09, 2002 10:24 AM > To: 'Thomas Vanier' > Cc: 'juergen.boldt@omg.org' > Subject: RE: CORBA 2.3 Telecom Log Service IDL compliance > > > Hello Thomas, > > Happy New Year to you, also. > > Unfortunately, I don't think the OMG ever formed a Telecom Log Service > RTF, so I don't think this issue has ever been formally resolved. > > Note we are currently working on a product version of the Telecom Log > Service, which will run with both Orbix 2000 and Orbacus 4.1. In > our version, we made a slight modification of the IDL to work around > this issue. Instead of having the DsLogAdmin::Log interface define > its own set of set_qos/get_qos operations, we have it inherit > CosNotification::QosAdmin. > > If you make this same change, our versions of the service will > be interoperable. :-) > > Regards, > Mike > > > -----Original Message----- > > From: vanier@nmu.alcatel.fr > [mailto:vanier@nmu.alcatel.fr]On Behalf Of > > Thomas Vanier > > Sent: Wednesday, January 09, 2002 9:29 AM > > To: michael.greenberg@iona.com > > Subject: CORBA 2.3 Telecom Log Service IDL compliance > > > > > > Hi Michael, > > > > Happy New Year ! > > > > Sorry for disturbing, a small question ... > > > > I've noticed the CORBA 2.3 Telecom Log Service IDL > compliance problem > > you've described (http://cgi.omg.org/issues/issue3752.txt), I've > > contacted Juergen Boldt (OMG) about it. > > > > Have you got any news concerning a fix ? > > Have you renamed get_qos into get_log_qos ? > > In this case, is there any link between NotifyLog.get_log_qos() and > > QoSAdmin.get_qos() ? > > > > > > Regards > > > > Thomas > > > > > From: "karoui" To: Cc: , Subject: issue 3752, vote Date: Mon, 18 Mar 2002 12:24:41 -0000 Organization: PrismTech Message-ID: <002a01c1ce77$e18ba520$8f1c0e50@LATP3850> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C1CE77.E18BA520" X-UIDL: MbZ!!@5Ge9~E^d90S:!! Dear LogService-RTF members, Please find below a short description and the vote proposal of the issue #3752. Issue 3752: ---------- The names of the operations "set_qos" and "get_qos" defined in the DsLogAdmin::Log interface conflict with those defined in the CosNotification::QoSAdmin. This issue appears each time the Telcom Logging Service Interface inherits both the the DsLogAdmin::Log and the CosNotifyChannelAdmin (which in turn inherits QoSAdmin). This is particularly the case of the DsNotifyLogAdmin::NotifyLog and DsTypedNotifyLogAdmin::TypedNotifyLog. Proposed Resolution: ------------------------- The issue is pretty simple and the easiest solution suggested few moths ago was to rename the set/get_qos operations in the DsLogAdmin::Log by set_log_qos and get_log_qos. If this solution is adopted subsequent edition efforts at sections 2.2.4.10 and in the Appendix A should follow. Regards, From: "karoui" To: Subject: issue 3752, vote Date: Mon, 18 Mar 2002 12:31:21 -0000 Organization: PrismTech Message-ID: <003101c1ce78$d04d2a80$8f1c0e50@LATP3850> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01C1CE78.D04D2A80" X-UIDL: jWZ!!=('e9/!Ke9_1l!! Dear LogService-RTF members, Please find below a short description and the vote proposal of the issue #3752. Issue 3752: ---------- The names of the operations "set_qos" and "get_qos" defined in the DsLogAdmin::Log interface conflict with those defined in the CosNotification::QoSAdmin. This issue appears each time the Telcom Logging Service Interface inherits both the the DsLogAdmin::Log and the CosNotifyChannelAdmin (which in turn inherits QoSAdmin). This is particularly the case of the DsNotifyLogAdmin::NotifyLog and DsTypedNotifyLogAdmin::TypedNotifyLog. Proposed Resolution: ------------------------- The issue is pretty simple and the easiest solution suggested few moths ago was to rename the set/get_qos operations in the DsLogAdmin::Log by set_log_qos and get_log_qos. If this solution is adopted subsequent edition efforts at sections 2.2.4.10 and in the Appendix A should follow. Regards, Sender: vanier@nmu.alcatel.fr Date: Tue, 16 Apr 2002 15:01:48 +0200 From: Thomas Vanier Organization: Alcatel CIT - Network Management Unit X-Mailer: Mozilla 4.79 [en] (X11; U; HP-UX B.11.11 9000/785) X-Accept-Language: en, fr To: karoui CC: log-service-rtf@omg.org Subject: Re: issue 3752, vote Hi Sorry for (too) late answering. I think the proposed solution fixes the issue. But according to me, the standard Corba Notification Service provides a dedicated interface (CosNotification::QoSAdmin) to manage Quality of Service. If making the DsLogAdmin::Log interface inherit the CosNotification::QoSAdmin one isn't a problem, I would suggest to : 1) remove get_qos and set_qos operations from the DsLogAdmin::Log interface 2) add a property name (const string LogQoS = "LogQoS") to the DsLogAdmin::interface The property value would be of type DsLogAdmin::QoSList (already defined) Then the logging service would handle Quality of Service the same way the notification service does. Making the DsLogAdmin::Log interface inherit the CosNotification::QoSAdminmay may cause dependency problems. For example, one wouldn't want the DsEventLogAdmin::EventLog inherits CosNotification::QoSAdmin. In this case, if the proposed solution is validated, the related documentation should detail the difference between get_qos/get_log_qos and set_qos/set_log_qos operations concerning the DsNotifyLogAdmin::NotifyLog and DsTypedNotifyLogAdmin::TypedNotifyLog interfaces. Regards, Thomas karoui wrote: Dear LogService-RTF members, Please find below a short description and the vote proposal of the issue #3752. Issue 3752: ---------- The names of the operations "set_qos" and "get_qos" defined in the DsLogAdmin::Log interface conflict with those defined in the CosNotification::QoSAdmin. This issue appears each time the Telcom Logging Service Interface inherits both the the DsLogAdmin::Log and the CosNotifyChannelAdmin (which in turn inherits QoSAdmin). This is particularly the case of the DsNotifyLogAdmin::NotifyLog and DsTypedNotifyLogAdmin::TypedNotifyLog. Proposed Resolution: ------------------------- The issue is pretty simple and the easiest solution suggested few moths ago was to rename the set/get_qos operations in the DsLogAdmin::Log by set_log_qos and get_log_qos. If this solution is adopted subsequent edition efforts at sections 2.2.4.10 and in the Appendix A should follow. Regards, Reply-To: From: "Ramzi Karoui" To: "Thomas Vanier" Cc: Subject: RE: issue 3752, vote Date: Wed, 17 Apr 2002 12:59:52 +0100 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal Hi Thomas, I see your point, but the CosNotification::QoSAdmin interface is not as generic as you presume it to be, it should manage the Notification related QoS only. More importantly, all the current implementations of the Log Service already support the set_qos_xxx/get_xxx_qos , consequently we can consider that the solution proposed is already implemented. So removing the get_qos-xxx and set_qos-xxx operations from the Log interface and adding the property name will induce a bit of work that the log service providers are avoiding, on the other hand this will harm the portability of the current applications. Best Regards -----Original Message----- From: vanier@nmu.ad lcatel.fr [mailto:vanier@nmu.alcatel.fr]On Behalf Of Thomas Vanier Sent: 16 April 2002 14:02 To: karoui Cc: log-service-rtf@omg.org Subject: Re: issue 3752, vote Hi Sorry for (too) late answering. I think the proposed solution fixes the issue. But according to me, the standard Corba Notification Service provides a dedicated interface (CosNotification::QoSAdmin) to manage Quality of Service. If making the DsLogAdmin::Log interface inherit the CosNotification::QoSAdmin one isn't a problem, I would suggest to : 1) remove get_qos and set_qos operations from the DsLogAdmin::Log interface 2) add a property name (const string LogQoS = "LogQoS") to the DsLogAdmin::interface The property value would be of type DsLogAdmin::QoSList (already defined) Then the logging service would handle Quality of Service the same way the notification service does. Making the DsLogAdmin::Log interface inherit the CosNotification::QoSAdminmay may cause dependency problems. For example, one wouldn't want the DsEventLogAdmin::EventLog inherits CosNotification::QoSAdmin. In this case, if the proposed solution is validated, the related documentation should detail the difference between get_qos/get_log_qos and set_qos/set_log_qos operations concerning the DsNotifyLogAdmin::NotifyLog and DsTypedNotifyLogAdmin::TypedNotifyLog interfaces. Regards, Thomas karoui wrote: Dear LogService-RTF members, Please find below a short description and the vote proposal of the issue #3752. Issue 3752: ---------- The names of the operations "set_qos" and "get_qos" defined in the DsLogAdmin::Log interface conflict with those defined in the CosNotification::QoSAdmin. This issue appears each time the Telcom Logging Service Interface inherits both the the DsLogAdmin::Log and the CosNotifyChannelAdmin (which in turn inherits QoSAdmin). This is particularly the case of the DsNotifyLogAdmin::NotifyLog and DsTypedNotifyLogAdmin::TypedNotifyLog. Proposed Resolution: ------------------------- The issue is pretty simple and the easiest solution suggested few moths ago was to rename the set/get_qos operations in the DsLogAdmin::Log by set_log_qos and get_log_qos. If this solution is adopted subsequent edition efforts at sections 2.2.4.10 and in the Appendix A should follow. Regards,