Project

General

Profile

Actions

Support Request #3599

closed

String from LOG_INFO

Added by hidden almost 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Customer:
AUDI
Department:
EF
Requester's Priority:
Normal
Support Level:
2nd Level
Resolution:
Solved Issue
Product Issue Numbers:
Affected Products:
Platform:
Topic:
ADTF::Logging
FAQ Links:

Description

Supportanfrage

LOG_INFO("LOGGING INFO containing Quotes: \"Text in Quotes\"");

führt in ucom::IConsoleDevice zu

<message SourceFile="..\..\..\test\gTest\src\adtf_integration_test.cpp" ExeFile="D:\dev\loggingservice\LoggingService\trunk\test\bin\Release\LoggingService_gTest.exe" Line="126" Level="info" Text="LOGGING INFO containing Quotes: \"Text in Quotes\"" Code="0x00000000" TimeStamp="13407459" ProcessId="2952" ThreadId="10168" Plugin=""runtime""/>

Dabei sind folgende Dinge problematisch:
  • Der String erweckt den Anschein xml-Format zu sein, ist es aber nicht
    • Im Wert vom Attribut Text werden C-Escapes (\") verwendet anstelle von xml Entities (")
    • Im Attribut Plugin stimmt die Zahl der Anführungszeichen nicht Plugin=""runtime""
  • Eine effiziente Verarbeitung der Informationen ist nicht möglich, da der String aufwändig geparsed werden muss
Idee für eine effizientere Kodierung/Dekodierung (Alternative zu xml):
  • ProcessId, ThreadId, Timestamp, Zeilennummer, This-Pointer des Objekts binär kodieren an festen Bytepositionen
  • Danach Pascal-Strings (Länge des Strings wird vorangestellt) für Nachrichteninhalt, Dateinamen, .... Um schnell zum richtigen String springen zu können
Anwendungsfall:
  • Hochfrequente Messages gleichen Typs von einem Objekt filtern.
Fragen:
  • Bestehen die Probleme auch in ADTF3?
  • Gibt es Pläne zur Verbesserung?

Lösung

In ADTF 2 wird sich da wohl nichts mehr tun. In ADTF3 gibts das Problem nicht, da bekommst du immer ein:

struct tLogEntry
{
    tTimeStamp nTimeStamp; ///< time stamp of the log message.
    tUInt8 nLogLevel; ///< the log level, see @ref tLogLevel.
    const tChar* strMessage; ///< the message text, optionally nullptr.
    const tChar* strSource; ///< the origin of the entry, optionally nullptr.
};

Die Elemente sind also nicht als komplexer String codiert, sondern als Elemente diese C-Struktur. Wenn strMessage Hochkommas enthält, dann ist das einfach so.

Pendants zu "ExeFile" und "Plugin" gibts nicht mehr, da dass zum einen Performance Probleme verursacht hat und auch nicht zuverlässig funktioniert hat.

Wenn man nach Plugins filtern will, geht dass indem man sich über adtf::ucom::IPluginLogging selbst beim Plugin als Logger oder Man in The Middle anmeldet.

Actions

Also available in: Atom PDF