Issues for Log Service FTF mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 2726: The text for the copy() and copy_with_id() operations
Issue 2755:
Issue 2756:
Issue 2757:
Issue 2758:
Issue 2759:
Issue 2762:
Issue 2763:
Issue 2764:
Issue 2768:
Issue 2771:
Issue 2773:
Issue 2774:
Issue 2777:
Issue 2920: Telecom logging -- illegal IDL
Issue 3120: Telecom Log Service issue
Issue 3458: Initial references?
Issue 3695: Viewing old logs
Issue 4279: TelecomLogService/2000-01-04 -- typo
Issue 4799: OMG Document formal/01-04-08 --IDL issue

Issue 2726: The text for the copy() and copy_with_id() operations (log_service-ftf)

The text for the copy() and copy_with_id() operations defined on the DsLogAdmin::Log 
interface should specify that a DsLogNotification::ObjectCreation notification will 
be generated as a result of the copy operation.

The Notification Service defines:

	module CosNotification {
		// ...
		interface QoSAdmin {
			QoSProperties get_qos();
			void set_qos(in QoSProperties qos)
				raises(UnsupportedQoS);
			// ...
		};
		// ...
	};

	module CosNotifyChannelAdmin {
		// ...
		interface EventChannel :
				CosNotification::QoSAdmin,
				CosNotification::AdminPropertiesAdmin,
				CosEventChannelAdmin::EventChannel {
			// ...
		};
		// ...
	};

The Logging Service defines:

	module DSLogAdmin {
		// ...
		interface Log {
			// ...
			QoSList get_qos();
			void set_qos(in QoSList qos) raises(UnsupportedQoS);
			// ...
		};
	};

	module DsEventLogAdmin {
		interface EventLog :
				DsLogAdmin::Log,
				CosEventChannelAdmin::EventChannel {};
		// ...
	};

	module DsNotifyLogAdmin {
		interface NotifyLog :
				DsEventLogAdmin::EventLog,
				CosNotifyChannelAdmin::EventChannel {
			// ...
		};
	};

The net result is that DsNotifyLogAdmin::NotifyLog inherits get_qos()
and set_qos() twice, once from QoSNotification::QoSAdmin, and once from
DSLogAdmin::Log, which is illegal. This makes the Logging Service
unimplementable right now.

Looks like the operations in DSLogAdmin::Log will have to be renamed or
the inheritance structure will have to change.

This issue concerns the Telecom Log Service as described in
the dtc/99-07-02 document.

I think the following statements in the spec are not compatible 
together:
 
 "Log forwarding is determined solely by forwarding state, it is not
  affected by the log's administrative state, availability state, log
  duration, scheduling, or log full action."
 
 "A log may be not be able to create any new log records because it is 
  full, locked, or disabled. If a log cannot create new log records when 
  a push operation is invoked, then the push operation should fail and a 
  SystemException should be raised."

If the log records are forwarded, then throwing system exceptions to
the supplier doesn't make sense. 

The Log Service spec doesn't state how a client gets access to the
intial references for the service (namely, the various factories).

  Assuming a log is persistent, how does one access the logged data after the system has been shut down?  It seems important to be able to view this data after the system shuts down to determine if there were any glitches while the system ran or to troubleshoot any problems that occured.

There is a typo on the first sentence on page 2-13. The words "enabled lock" should be "enabled log" in the following sentence : The stop field indicates the date and time at which an unlocked and enabled lock stops functioning.

I think the OMG Telecom Log Service IDL (DsLogAdmin and DsNotifyLogAdmin
modules) isn't in accordance with the CORBA 2.6 "OMG IDL Syntax and
Semantics" specification.

Indeed the DsNotifyLogAdmin::NotifyLog interface inherits from both
DsLogAdmin::Log.get_qos and CosNotification::QoSAdmin.get_qos
operations, this is illegal according to section 3.7.5 (page 3-20) of
the CORBA 2.6 specification.

I've tried to compile the OMG Telecom Log Service with 2 differents ORBs
(ORBacus 4.0.5 and JacORB 1.4beta2) without success.