Lightweight Log Service Avatar
  1. OMG Specification

Lightweight Log Service — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
LTLOG11-31 bootstrapping LtLOG 1.1 open
LTLOG11-30 The Lightweight Log Service does not allow for logging of binary data. LtLOG 1.1 open
LTLOG11-6 HALT mode LtLOG 1.0 open
LTLOG11-5 Log Consumer Interface functions LtLOG 1.0 open
LTLOG11-2 line from item 1 LtLOG 1.0 open
LTLOG11-1 section 2.4.2 LtLOG 1.0 open
LTLOG11-8 Suggest adding following to the description of clearLog in section 2.6.4 LtLOG 1.0 open
LTLOG11-7 WRAP mode LtLOG 1.0 open
LTLOG11-4 add ection to retrieveRecords description LtLOG 1.0 open
LTLOG11-3 treatment of currentId should be consistent LtLOG 1.0 open
LTLOG11-28 issue with section 2.4.2 retrieveById LtLOG 1.0b1 open
LTLOG11-29 LW Log Service IDL errors LtLOG 1.0b1 open
LTLOG11-18 use of IDL type string for data that's logged is not cross-language compati LtLOG 1.0b1 open
LTLOG11-19 Text of the Specification: (PSM) LtLOG 1.0b1 open
LTLOG11-22 Text of the Specification: (PIM) LtLOG 1.0b1 open
LTLOG11-25 LogRecordSequence LtLOG 1.0b1 open
LTLOG11-20 Section 4 of the Specification -- the IDL LtLOG 1.0b1 open
LTLOG11-23 Notation used in PIM LtLOG 1.0b1 open
LTLOG11-27 Page 43. In Section 4 The Complete Logging Service IDL LtLOG 1.0b1 open
LTLOG11-21 current write operation LtLOG 1.0b1 open
LTLOG11-26 InvalidParam exception LtLOG 1.0b1 open
LTLOG11-24 Sponsoring Task Force LtLOG 1.0b1 open
LTLOG11-17 Sections 2, 3 and 4 LtLOG 1.1 open
LTLOG11-16 Page: 4-1 to 4-4 LtLOG 1.1 open
LTLOG11-15 Section: 2.2.2, 4.1.2 LtLOG 1.1 open
LTLOG11-14 Mismatch between the methods' notification LtLOG 1.1 open
LTLOG11-11 lack of shalls in specification LtLOG 1.0 open
LTLOG11-10 Suggest breaking up the IDL across the interface boundaries LtLOG 1.0 open
LTLOG11-13 Provide IDL files that allows for name space implementations LtLOG 1.0 open
LTLOG11-12 ISO format conformance LtLOG 1.0 open
LTLOG11-9 Section 3.3.4.1 LtLOG 1.0 open

Issues Descriptions

bootstrapping

  • Key: LTLOG11-31
  • Legacy Issue Number: 9144
  • Status: open  
  • Source: Objective Interface Systems ( Mr. 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

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

HALT mode

  • Key: LTLOG11-6
  • Legacy Issue Number: 7208
  • Status: open  
  • Source: prismtech.com ( Dominick Paniscotti)
  • Summary:

    The desired behavior of the log service when the log full action type is set to WRAP needs to be explicitly defined. This comment is based upon experience with the SCA 2.2 JTeL JTAP tests. Open interpretation of this item led to failures characterized by the following questions:

    a. Is a log with a log full action type of WRAP ever considered full? The JTeL JTAP tests expect this, but there is a semantic issue here – writes to a “full log” will be successful. Further, if a log in WRAP mode can become full, then…

    b. When is it considered full? Since log records use variable amounts of storage, a log nearing capacity may have a handful of bytes available, yet not have enough space to store even the smallest of records.

    c. When should the log service detect that the log is full? JTAP expects a log to be set full as soon as storage is exhausted, i.e., at the completion of a write that exactly fills the log. While this does not seem to be what the specification suggests, it illustrates an example of an area left up to interpretation.

    Declaring a log full only in HALT mode and only when a write is attempted would avoid these questions.

  • Reported: LtLOG 1.0 — Thu, 25 Mar 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Log Consumer Interface functions

  • Key: LTLOG11-5
  • Legacy Issue Number: 7207
  • Status: open  
  • Source: prismtech.com ( Dominick Paniscotti)
  • Summary:

    The Log Consumer Interface functions should identify when the InvalidParam exception is raised. (i.e., what constitutes an invalid supplied parameter to these functions?)

  • Reported: LtLOG 1.0 — Thu, 25 Mar 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

line from item 1

  • Key: LTLOG11-2
  • Legacy Issue Number: 7204
  • Status: open  
  • Source: prismtech.com ( Dominick Paniscotti)
  • Summary:

    If the line from item 1 is not deleted, the retrieveRecords function should explicitly state when the log is considered exhausted, i.e. “no further records available”, for purposes of setting the howMany and currentId fields. This comment is made in order to prevent a possible interpretation that may lead to failures in third party test suites (the result of a retrieve contains the howMany requested records with the last record in the log as part of the sequence – possible that a test could expect currentId to be set to zero since there are no more records available).

  • Reported: LtLOG 1.0 — Thu, 25 Mar 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

section 2.4.2

  • Key: LTLOG11-1
  • Legacy Issue Number: 7203
  • Status: open  
  • Source: prismtech.com ( Dominick Paniscotti)
  • Summary:

    The line “If there are no further records available, currentId will be set to zero.” in section 2.4.2 should be deleted. This would make the behavior consistent with the other record retrieval functions. For readability, consider explicitly stating that the line previous to this concerns the case where currentId exists. This last comment applies to the other record retrieval functions as well.

  • Reported: LtLOG 1.0 — Thu, 25 Mar 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Suggest adding following to the description of clearLog in section 2.6.4

  • Key: LTLOG11-8
  • Legacy Issue Number: 7210
  • Status: open  
  • Source: prismtech.com ( Dominick Paniscotti)
  • Summary:

    Suggest adding the following to the description of clearLog in section 2.6.4:

    a. A subsequent invocation of the getNumRecords operation will return 0 (zero).

    b. A subsequent invocation of the getAvailabilityStatus operation will return a log Full field of false.

  • Reported: LtLOG 1.0 — Thu, 25 Mar 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

WRAP mode

  • Key: LTLOG11-7
  • Legacy Issue Number: 7209
  • Status: open  
  • Source: prismtech.com ( Dominick Paniscotti)
  • Summary:

    When in WRAP mode, should the writeRecord(s) function delete as many records as needed to make room for a new record, or only a single record? An explicit statement would mitigate a possible interpretation issue. Further, the functional descriptions should be updated to include the desired behavior in WRAP mode and the management of the log full status once it is resolved.

  • Reported: LtLOG 1.0 — Thu, 25 Mar 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

add ection to retrieveRecords description

  • Key: LTLOG11-4
  • Legacy Issue Number: 7206
  • Status: open  
  • Source: prismtech.com ( Dominick Paniscotti)
  • Summary:

    The section of the note at the end of the retrieveRecordsBy* descriptions that informs of the need to reestablish a recordId due to the potential modification of the currentId parameter should be added to the retrieveRecords description as well.

  • Reported: LtLOG 1.0 — Thu, 25 Mar 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

treatment of currentId should be consistent

  • Key: LTLOG11-3
  • Legacy Issue Number: 7205
  • Status: open  
  • Source: prismtech.com ( Dominick Paniscotti)
  • Summary:

    As discussed in item #1, the treatment of currentId should be consistent across the retrieveRecords and retrieveRecordsBy* functions. Further, the wording used in the descriptions with regard to the currentId and howMany parameters should be the same

  • Reported: LtLOG 1.0 — Thu, 25 Mar 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

issue with section 2.4.2 retrieveById

  • Key: LTLOG11-28
  • Legacy Issue Number: 5885
  • Status: open  
  • Source: ADLINK Technology Ltd ( Vincent Kovarik)
  • Summary:

    We have implemented the above service as part of our SCA Core Framework
    implementation. However, we have an issue with section 2.4.2 retrieveById of
    the document.

    This section states (we have numbered the sentences in question):

    S1: "The log will update howMany to indicate the number of records returned and
    will set currentId to the id of the record following the last retrieved record.

    S2: "If there are no further records available, currentId will be set to zero."

    S3: "If the record specified by the currentId does not exist, or if the Log is
    empty, the retrieveById operation returns an empty list of LogRecords, and sets
    both, currentId and howMany to zero."

    This behavior can create a problem as follows.

    1) A log is operational with 10 records, Id 1 through 10.

    2) An application issues a retrievById request for 5 logs starting at ID 6.

    3) The log retrieves records 6 through 10, updates the howMany to 5, and sets
    the currentId to 11, per S1 above

    NOTE: At this point it is unclear if S2 applies. Certainly, at this point in
    time, no more records are available but setting currentId to zero is in conflict
    with S1 and doesn't appear to make sense. The following steps assume that S1 is
    followed and S2 is ignored.

    4) The log is still operational but has not written any additional records when
    the same application issues a retrievById for 10 records starting at record id
    11 (what it believes to be the next record).

    5) The currentId of 11 does not exist in the log, so S3 applies. Consequently,
    the log returns an empty set of LogRecords and sets both howMany and currentId
    to zero.

    6) The application now believes the currentId in the log has been reset to zero.

    7) The log writes records 11 through 14.

    At this point the application has lost a valid reference into the log to obtain
    the next record by Id.

    We would like to recommend the following changes to the retrieveById .

    S1: No Change

    S2: Strike from the paragraph.

    S3: Strike as worded and add the following conditions:

    S3.A) If the record specified by currentId does not exist AND the currentId
    provided by the call is greater than the Id of the last record written by the
    log, the retrieveById operation returns an empty list of LogRecords, sets
    howMany to zero, and leaves the currentId unchanged.

    S3.B) If the record specified by currentId does not exist AND the currentId
    provided by the call is zero OR less than the first Id of the log, the
    retrieveById operation returns an list of LogRecords starting with the first
    available records, sets howMany to the number of records retrieved, and sets the
    currentId to one past the last record retrieved.

    S3.C) If the record specified by currentId does not exist and the Log is empty,
    the retrieveById operation returns an empty list of LogRecords, sets hoMany to
    zero, and sets the curentId to zero.

    Change S3.A allows a client to request log records and leave the currentId
    pointing the next log record in the eent that at the time of the retrievById
    operation, there were no log records available but the log is operational and
    just had not written any additional records since the applications last request.

    Change S3.B addresses the scenarios where the client may have a Id reference
    that has been written and cleared since it's last retrieveId request and the
    first available log Id is greater than the Id requested. It also provides the
    mechanism for allowing a client to issue a retrieveById without knowing the
    current state of the log and obtain the first set of available log records.

    Change S3.C identifies the empty log condition to the application as opposed to
    simply no further records available at the time of the call.

  • Reported: LtLOG 1.0b1 — Wed, 19 Mar 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

LW Log Service IDL errors

  • Key: LTLOG11-29
  • Legacy Issue Number: 5884
  • Status: open  
  • Source: Anonymous
  • Summary:

    The Lightweight Log draft adopted specification contains some errors in
    its IDL.

    There is a struct called ProducerLogRecord, which is being referred to
    later on as LogProducerRecord in the LogProducer interface (page 56).
    Furthermore, the LogFullAction enum is wrongly referred to as
    LogFullActionType. The same goes for AdministrativeState which is being
    referred to as AdministrativeStateType from the LogAdministrator
    interface definition.

  • Reported: LtLOG 1.0b1 — Thu, 13 Mar 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

use of IDL type string for data that's logged is not cross-language compati

  • Key: LTLOG11-18
  • Legacy Issue Number: 5920
  • Status: open  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    Discussion:
    The data that can be logged with the Lightweight Log service is an encoding of arbitrary binary data. The type used in the ProducerLogRecord for this data is "string" in both the PIM and the PSM. This is inappropriate, since strings are not considered to be arbitrary encodings. They are associated with particular (and different) character encodings in different technologies. This can be seen even within the CORBA PSM, where the Java language mapping transforms a string to sixteen-bit characters internally.

    Proposed Resolution:
    Change the type of the logData field in the ProducerLogRecord to OctetSeq

  • Reported: LtLOG 1.0b1 — Wed, 30 Apr 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Text of the Specification: (PSM)

  • Key: LTLOG11-19
  • Legacy Issue Number: 5917
  • Status: open  
  • Source: Anonymous
  • Summary:

    Page 3-2, Section 3.2 at the top omits any mapping to the
    Platform Specific Model of the PIM section 2.2.1 InvalidParam
    exception. The appropriate text needs to be added.
    (Since the actual IDL is mostly derived from the Section 3.2
    details, this omission apparently led to the omission of the
    exception declaration from the IDL, cited above.)

    Page 3-3, section 3.2.4, remove syntax error
    from:
    enum LogFullAction (WRAP, HALT);
    to:
    enum LogFullAction

    {WRAP, HALT}

    ;

    Page 3-5, section 3.2.7 has a wrong-word problem in the PSM code.
    change:
    <ProducerLogRecordType
    to:
    <ProducerLogRecord

    Page 3-5, section 3.2.7, the Description box for producerID has
    some residual cut-and-paste text from the SCA that needs to be
    removed or revised. The questionable text is:
    "SCA Resource and Core Framework"

    Page 3-6, section 3.2.9 has another code-level wrong word problem.
    change:
    <LogRecordType
    to:
    <LogRecord

    Page 3-11, end of section 3.3.1.4, add the missing preposition.
    change:
    "signature the equivalent"
    to:
    "signature to the equivalent"

    Page 3-15, section 3.3.3 contains two kinds of problems at the
    code level.
    (1) LogProducerRecord & LogProducerRecordSequence
    are word-transposition misnomers for
    ProducerLogRecord & ProducerLogRecordSequence
    (2) The desired sequence has already been more properly defined
    in section 3.2.7 earlier.

    Page 3-19, section 3.3.4.3 needed to replace all the
    full-upper-uppercase references to LOCKED & UNLOCKED by
    their full-lower-case equivalents locked & unlocked, as per
    section 3.2.2 and per the manner of usage in section 3.3.1.6

  • Reported: LtLOG 1.0b1 — Wed, 23 Apr 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Text of the Specification: (PIM)

  • Key: LTLOG11-22
  • Legacy Issue Number: 5916
  • Status: open  
  • Source: Anonymous
  • Summary:

    This is mostly sequential. There is considerable, coding-oriented
    meat here. Forgive the initial attention to a few trivial
    capitalization/editing problems noted.

    Needs a consistent capitalization of RecordID/RecordId (recordId?),
    starting with the table of contents and including every figure and
    code example, as well as the text. (The IDL uses the former, but the specification text
    uses both. (I understand that the CORBA is supposed to be
    case-insensitive, but that will not be true of the generated
    C++ or Java code.)

    Page 2-5, section 2.2.2 ",do denote" should be ", to denote"

    Page 2-7, section 2.2.9 "LogRecordType" should be "LogRecord type"

    Page 2-15, near end of section 2.5 "unique record Id" should be
    changed to "unique recordId" (join the separated words, and use
    whatever consistent capitalization is selected).

    Page 2-16, section 2.6.2 "Void" type in the parameters box should
    be "void" for consistency.

    Page 2-17, section 2.6.3 "Void" type in the parameters box should
    be "void" for consistency.

    Page 2-18, section 2.6.5, code snipet "Destroy () : void"
    should be "destroy () : void" for consistency.

  • Reported: LtLOG 1.0b1 — Wed, 23 Apr 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

LogRecordSequence

  • Key: LTLOG11-25
  • Legacy Issue Number: 5915
  • Status: open  
  • Source: Anonymous
  • Summary:
    • It is inconsistent to define LogRecordSequence outside of
      the interface of its user LogConsumer
      while attempting to define ProducerLogRecordSequence inside of
      the interface of its user LogProducer.
  • Reported: LtLOG 1.0b1 — Wed, 23 Apr 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 4 of the Specification -- the IDL

  • Key: LTLOG11-20
  • Legacy Issue Number: 5914
  • Status: open  
  • Source: Anonymous
  • Summary:

    "Complete Logging Service IDL"

    • Names the raised exception "InvalidParam" without ever
      declaring it. Add to the IDL, probably near the beginning,
      the following declaration, or its equivalent:
      exception InvalidParam { string Details; }

      ;

    • Syntax error in:
      enum LogFullAction (WRAP, HALT);
      Change to:
      enum LogFullAction {WRAP, HALT}

      ;

    [Error above is also in the specification text, section 3.2.4]

    • These types appear needed by the IDL but nowhere actually
      defined in the IDL:
      ProducerLogRecordSequence
      LogProducerRecord

    They are naming-confusion/consistency problems, and they
    also appear in the text of the specification.
    They involve writers' confusion between the interface
    name ("LogProducer") and the type names ProducerLog...
    It is correctable by changing the current defective declaration
    from:
    typedef sequence<LogProducerRecord
    LogProducerRecordSequence;
    to:
    typedef sequence<ProducerLogRecord
    ProducerLogRecordSequence;
    The text of the specification in section 3.3.3 (page 3-15) should
    also be corrected for these word inversion problems.

    end 1st issue. These are IDL issues in addition to the ones identified in 5885.

  • Reported: LtLOG 1.0b1 — Wed, 23 Apr 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation used in PIM

  • Key: LTLOG11-23
  • Legacy Issue Number: 5889
  • Status: open  
  • Source: hqda.army.mil ( Michael McClimens)
  • Summary:

    Throughout the PIM. "void" is used to indicate that no data is returned from the operation. The comment is about the PIM operations where void is specified for the return type. Recommend that "void" be removed from the PIM. Void is not conformant to UML PIM.
    void is language (c, Java) specific

    + oper1 (in MyType, in MyType)

  • Reported: LtLOG 1.0b1 — Wed, 16 Apr 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 43. In Section 4 The Complete Logging Service IDL

  • Key: LTLOG11-27
  • Legacy Issue Number: 5888
  • Status: open  
  • Source: hqda.army.mil ( Michael McClimens)
  • Summary:

    Page 43. In Section 4 The Complete Logging Service IDL, the text incorrectly uses all capitol letters for PRAGMA. Therefore

    Recommendation: Change #PRAGMA prefix "omg.org" to
    #pragma prefix "omg.org".

  • Reported: LtLOG 1.0b1 — Wed, 16 Apr 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

current write operation

  • Key: LTLOG11-21
  • Legacy Issue Number: 5913
  • Status: open  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The current write operation only has on parameter (ProducerLogRecordSequence) that allows a sequence of log records to be written.

    add an additional write operation with a simple parameter that allows a single log record to be written and does not require a sequence.

  • Reported: LtLOG 1.0b1 — Wed, 23 Apr 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

InvalidParam exception

  • Key: LTLOG11-26
  • Legacy Issue Number: 5908
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Neither the PSM for CORBA nor the IDL mention the
    InvalidParam exception. (The IDL uses the exception,
    but does not define it.)

  • Reported: LtLOG 1.0b1 — Tue, 22 Apr 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sponsoring Task Force

  • Key: LTLOG11-24
  • Legacy Issue Number: 5890
  • Status: open  
  • Source: hqda.army.mil ( Michael McClimens)
  • Summary:

    The name of the sponsoring task force is Real-time, Embedded, and Specialized Systems (RTESS). Currently references do not consistently include the acronym.

    Recommendation: Update page .8, Section .10 text and page 7, Section .8, both title and text to be:
    Real-time, Embedded, and Specialized Systems (RTESS).

  • Reported: LtLOG 1.0b1 — Wed, 16 Apr 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

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

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

lack of shalls in specification

  • Key: LTLOG11-11
  • Legacy Issue Number: 7214
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Recommendation add shalls to specification to help with testability of
    specification and conformance

  • Reported: LtLOG 1.0 — Fri, 2 Apr 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Suggest breaking up the IDL across the interface boundaries

  • Key: LTLOG11-10
  • Legacy Issue Number: 7212
  • Status: open  
  • Source: prismtech.com ( Dominick Paniscotti)
  • Summary:

    Suggest breaking up the IDL across the interface boundaries. This allows the users of the log the ability to only include the interface(s) they need to

  • Reported: LtLOG 1.0 — Thu, 25 Mar 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide IDL files that allows for name space implementations

  • Key: LTLOG11-13
  • Legacy Issue Number: 7216
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Provide IDL files that allows for name space implementations
    Recommendation: Separate idl files for each interface as another Annex

  • Reported: LtLOG 1.0 — Fri, 2 Apr 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ISO format conformance

  • Key: LTLOG11-12
  • Legacy Issue Number: 7215
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Recommendation: When making changes to specification, conform the format to
    OMG's new specification format

  • Reported: LtLOG 1.0 — Fri, 2 Apr 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 3.3.4.1

  • Key: LTLOG11-9
  • Legacy Issue Number: 7211
  • Status: open  
  • Source: prismtech.com ( Dominick Paniscotti)
  • Summary:

    In Section 3.3.4.1, the “Difference to the Telecom Log Service” indicates that a return result has been added. The set_max_size function return type is void

  • Reported: LtLOG 1.0 — Thu, 25 Mar 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT