[platform-core-dev] Re: Eclipse RFC 0003/platform-core-dev submission

[paules@xxxxxxxxxx]

Please accept this submission to the platform-core-dev mailing list:

     It has been proven by the proposal of RFC 0003 and XML's utility and
maturity that XML is the most appropriate format for log records.  Plain
text logs are often difficult to read, query and negotiate
programmatically.  To carry forward the progress and success of XML as a
data transport in the logging arena, an open format of capturing any log
message wrapped in XML is necessary.  The existing XML infrastructure
permits static data structure (i.e. DOM) and/or event driven (i.e. SAX)
parsing depending on the context for retrieving logged records.  Finally,
since XML is a string representation of any form of data, flowing remains
simple and loosely coupled to data structure APIs.  To quote Sun et al,
"Java is the behavior and XML is the data".  Since logs are pure data, it
seems only natural to use XML.

     The most robust but yet simplistic base-case in XML logging is a
primitive name-value pair record.  For example,

boolean continue = true;

<boolean member="continue" value="true">

     This XML fragment  is robust since it does not relay on any predefined
message record API or DTD format that may change from version to version
and is intuitive to both the human readers and XML parsers.  In this
illustration of logging a Java primitive, using an XML empty tag with the
primitive type as the tag name and the instance variable's name (when
available) and value as attributes, represents a well-formed, simple and
intuitive XML log record.  Building an intuitive XML logging standard will
eliminate much unnecessary overhead in creating and maintaining a closed
logging format.

     To carry this thread one step further, our simply base case can be
extended to the most complex of hierarchal objects.  Using the same notion
of an open standard of logging Java primitives wrapped in XML, objects can
be serialized using the same format.  For example,

public class HelloWorld{
    private int number;
    private HelloWorld child;

    public HelloWorld(int number){
        this.number= number;
        child = new HelloWorld(number++);
    }

    public int getNumber(){return number;}
    public HelloWorld getChild(){return child;}
}

<HelloWorld number="1">
    <HelloWorld member="child" number="2">
        ...
    </HelloWorld>
</HelloWorld>

     In this illustration, the 'HelloWorld' object is serialized into a
'HelloWorld' tag with all simple or primitive instance variables that are
public and/or with public getter methods as name-value pair attributes and
complex or nested objects that are public and/or with public getter methods
as sub-elements of the parent tag.  The structure of the XML fragment
displays the object's class structure without the need for unnecessary
metadata.  The representation of any object can be customized to either a
breadth or depth introspection in the XML formatter and filter APIs.  This
particular example, although programmatically causing an infinite loop,
shows how recursive objects could present a problem.  This problem is
addressed by defining a limit on the levels of nesting permitted, in effect
as a form of filtering.  Also, repeat objects an be eliminate by providing
a reference or a XML 'IDREF' tag pointing to the previously logged object.
In essence, effort can be invested into robust formatter and filter APIs
that may be extended for special casing specific types of objects rather
than enforcing a set of log record types.  Finally, the addition of context
information such as record identification, time stamps, logging level,
and/or sequencing references can be done to the desired detail in the
formatter and filter APIs irrespective of the entity that is bring logged.

     Another beneficial result of adopting an open XML logging format is it
maps to the JCP's JSR 47.  JSR 47 provides a specification for logging APIs
starting in JDK 1.4 suitable for logging records from within Java
applications.  The utility of JDK logging APIs includes enabling  or
disabling logging at run-time, logging levels, and registration and
bridging of new and extended logging services.  The future migration to
JSR47 when it becomes available, would be seamless given a JSR compliant
XML stream formatter and the associated filtering APIs.  For more detailed
information on the proposed JSR 47 logging APIs, consult
ftp://ftp.java.sun.com/pub/spec/internal/logging/dwh123789/logging-0_8-pfd-spec.pdf


     Finally, looking towards the future of logging in Eclipse, the
creation of standardized logging classes would provide users with APIs for
convenience and uniformity.  For example, a default message class would
provide a framework for logging a simple message with additional metadata.
The user would be required to pass minimal parameter data transformed into
a XML log message including a wide variety of useful information derived
from the host , platform, logging preferences, and et cetera.  This
architecture could be broadened in the future to incorporate standards
activities such as the Distributed Management Task Force (DMTF).

PS

----------------------------------------------
Paul Slauenwhite
IBM Toronto Lab, Canada

Internet:   paules@xxxxxxxxxx
Phone:    (905) 413-3861
Tie Line:            969-3861
Fax:          (905) 413-4920
---------------------------------------------