Re: [platform-core-dev] RFC 0003 - Log File Retrieval

["Jeff McAffer/OTT/OTI" <Jeff_McAffer@xxxxxxx>]

Yes.  When you get an exceptoin which wrappers another exception, it may be good to have that output as well.  This would require the DTD to allow for the <exception> tag to have subexceptions.  When dumping IStatus objects and their contained exceptions the code could reasonably dump nested exceptions if any.  May have to use reflect to get this in a generic way but it performance is not a major issue as we are already logging so...

Jeff

John Arthorne 12/03/2001 10:55 AM

To:        Jeff McAffer/OTT/OTI@OTI         cc:                 Subject:        Re: [platform-core-dev] RFC 0003 - Log File RetrievalLink

Jeff, your naming/formating suggestions sound good.  I'm just wondering what you mean by logging nested exceptions?  Are you suggesting we add special code to handle wrapper exceptions such as InvocationTargetException?  Or are you just suggesting we add the possibility of nested exceptions to the DTD, to allow for future flexibility?

"Jeff McAffer/OTT/OTI" <Jeff_McAffer@xxxxxxx> Sent by: platform-core-dev-admin@xxxxxxxxxxx 12/01/2001 12:42 PM Please respond to platform-core-dev

To:        platform-core-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-core-dev] RFC 0003 - Log File Retrieval

I like the compact xml format. 

the contents/existence of the .log file is not api.  Removing it is in bad taste since, as you say, people already know where it is etc. but there is no particular need to keep the content the same.  People will figure it out when they go to look at it.  Does it matter if the file has a .xml extension? 

Suggest we have one file, called .log, containing compact XML. 

Side note:  We should admit the possibility of logging nested exceptions.

"John Arthorne/OTT/OTI" <John_Arthorne@xxxxxxx> Sent by: platform-core-dev-admin@xxxxxxxxxxx 11/30/2001 04:59 PM Please respond to platform-core-dev

To:        platform-core-dev@xxxxxxxxxxx        cc:                Subject:        Re: [platform-core-dev] RFC 0003 - Log File Retrieval

I have added a link to a sample log file in the RFC, so you can all judge
if it's more or less readable.  It wouldn't be ideal to write two files
with the same information in them, although there are pros and cons for
both formats.  For example, previously you'd get:

Log: Fri Nov 30 16:05:25 EST 2001
4 org.eclipse.xyz.SomePlugin 1 The Foo operation failed to complete.
Stack trace:
...

In XML you'd get:

<log-entry date="Fri Nov 30 16:05:25 EST 2001">
 <status
    plugin-id="org.eclipse.xyz.SomePlugin"
    severity="ERROR"
    message="The Foo operation failed to complete."
    code="1">
    <exception
        message="Failed to write because the disk has no more space."
        trace="
...
   </exception>
 </status>
</log-entry>

In the original, the second line has several pieces of information stuck
together; it doesn't tell you what the bits of information are,
particularly what "4" and "1" mean.  The XML also now includes the
exception message, which was previously missing.  The XML file is more
understandable, but much more verbose.  Perhaps the XML file could be cut
down a bit:

<log-entry date="Fri Nov 30 16:05:25 EST 2001">
 <status id="org.eclipse.xyz.SomePlugin" sev="ERROR" msg="The Foo
operation failed to complete." code="1">
    <exception msg="null" trace="
...
   </exception>
 </status>
</log-entry>

However, once this API has been added, it will be much easier to use a
UI-based log display, such as the one provided in PDE.  The log view would
have "clear" and "restore" buttons, and has a nice tabular display.  Most
importantly, it will also be able to show you log entries that occurred
before the view opened.  With a nice log view, it won't be so important to
have the file on disk in an easy to read format.

It's true that changing the log file name would cause initial confusion for
users.  Most people know to search for ".log" by now.  Maybe as a temporary
measure, the platform could automatically write a .log file that just says,
"The log is now in a file called log.xml", or something similar.




                                                                                                                   
                   "Rodrigo Peretti/OTT/OTI"                                                                       
                   <Rodrigo_Peretti@xxxxxxx>        To:     platform-core-dev@xxxxxxxxxxx                          
                   Sent by:                         cc:                                                            
                   platform-core-dev-admin@e        Subject:     Re: [platform-core-dev] RFC 0003 - Log File       
                   clipse.org                       Retrieval                                                      
                                                                                                                   
                                                                                                                   
                   11/30/2001 03:28 PM                                                                             
                   Please respond to                                                                               
                   platform-core-dev                                                                               
                                                                                                                   
                                                                                                                   



I really liked the idea of having the log file in XML format. Here are
some comments:

1) Instead of changing the format to XML, we should just have an
additional log.xml file as well as the current .log file. The current
format is much easier for humans to read (and currently helps a lot) than
if you add a bunch of XML tags to it.

2) Minor: I would prefer the names to be .log and log.xml. But I don't
really mind about changing it.

Rodrigo



_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev