Lightweight Log Service Avatar
  1. OMG Specification

Lightweight Log Service — Open Issues

  • Acronym: LtLOG
  • Issues Count: 6
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Sections 2, 3 and 4

  • Key: LTLOG11-17
  • Legacy Issue Number: 12202
  • Status: open  
  • Source: SPAWAR Systems Center, San Diego ( Mike Schmidt)
  • Summary:

    I have a question about the OMG Lightweight Log version 1.1. (Note: I am aware that the Lightweight Log is not required by SCA 2.2.2. My questions assume that I am testing a radio that has a Lightweight Log.) Section 2 states "...the class Log does not communicate directly with the rest of the environment. Communication with the surrounding environment is handled through three distinct interfaces." It lists these as the LogProducer, LogConsumer, and LogAdmin interfaces. Section 3 defines the CORBA mapping for the LogProducer, LogConsumer, and LogAdministrator interfaces. Section 4 defines a new Log interface: module CosLwLog { interface Log : LogAdministrator, LogConsumer, LogProducer {}; }; The Log interface combines the functionality of the LogProducer, LogConsumer, and LogAdministrator interfaces. This appears to contradict Section 2, which says Log communication is through three distinct interfaces. Should the radio provide the Log interface defined in Section 4? Or should the radio only provide the LogProducer, LogConsumer, and LogAdministrator interfaces to comply with Section 2?

  • Reported: LtLOG 1.1 — Wed, 30 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 4-1 to 4-4

  • Key: LTLOG11-16
  • Legacy Issue Number: 10349
  • Status: open  
  • Source: ( Mike Gudaitis)
  • Summary:

    The IDL in Section 4 does not match the descriptive text in Section 2. Some examples: struct AvailabilityState: offDuty (p 2-6) vs off_duty (p 4-2); logFull (p 2-6) vs log_full (p 4-2). interface LogStatus: getMaxSize (p 2-8) vs get_max_size (p 4-3); getCurrentSize ((p 2-9) vs get_current_size (p 4-3); getNumRecords (p 2-10) vs get_n_records (p 4-3); etc. etc. (many other mistakes!!). What takes precedence, the IDL in section 4, or the text in section 2? I can provide a detailed list of all the mistakes that need to be corrected. Please contact me for the details. /mike.gudaitis@L-3com.com, 315-339-6184

  • Reported: LtLOG 1.1 — Mon, 18 Sep 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mismatch between the methods' notification

  • Key: LTLOG11-14
  • Legacy Issue Number: 7776
  • Status: open  
  • Source: marconiselenia ( paola.castellani)
  • Summary:

    Mismatch between the methods' notification in the first section of the document (diagrams and chapters names like in SCA document, v2.2) and the methods' references used in the idl section. Please confirm/clarify which method's reference name has to be used by external users. Example: method's name: getMaxSize method in idl: get_max_size

  • Reported: LtLOG 1.1 — Mon, 20 Sep 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 2.2.2, 4.1.2

  • Key: LTLOG11-15
  • Legacy Issue Number: 8691
  • Status: open  
  • Source: Rockwell Collins ( Brian Neal)
  • Summary:

    In section 2.2.2 it says LogLevel values 10-26 are reserved for programmer debugging purposes. In section 4.1.2, in the IDL there is the following comment: // Values ranging from 10 to 26 are reserved for // 16 debugging levels. There are 17 values in the range 10-26, which contradicts the comment

  • Reported: LtLOG 1.1 — Fri, 8 Apr 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The Lightweight Log Service does not allow for logging of binary data.

  • Key: LTLOG11-30
  • Legacy Issue Number: 8998
  • Status: open  
  • Source: ITT Industries Aerospace/Communications ( Phil Eyermann)
  • Summary:

    The Lightweight Log Service does not allow for logging of binary data.

  • Reported: LtLOG 1.1 — Thu, 15 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

bootstrapping

  • Key: LTLOG11-31
  • Legacy Issue Number: 9144
  • Status: open  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    Unlike other CosServices, there is no discussion of "bootstrapping", this service. There should be. In particular, there should be, at least, a reserved "ObjectId" for use in "resolve_initial_references".

  • Reported: LtLOG 1.1 — Tue, 8 Nov 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT