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".

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

In order to add some possibilities to filter records, we would like methods
that retrieve log records according to the fields defined in struct
ProducerLogRecord (namely the level, producerId and producerName).
That would consist in the three following methods to be added on the
LogConsumer object.
That point has been discussed during the Yokohama meeting with the
supporters of this submission (in particular with Jeff Smith) and no
difficulty to add these methods was foreseen.

see above

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.

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

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).

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.

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.

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.

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.

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

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.

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.

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

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

;

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

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.

• 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.

"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.

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)

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".

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.

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

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).

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?

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

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

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

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

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

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

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

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