[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-core-dev] Comments on RFC 0003: Log File Retrieval
|
Great points. I'll add a couple notes.
The ILog objects are not proxies for a file on disk. They are logical
logs. For example, the .log file we see today is actualy the output of an
ILogListener which is installed by the system. As a further example, the
log view provided by PDE installs a listener which gets the IStatus objects
and presents them in the view.
So when we talk about providing a mechanism to read "logs" we are actually
talking about reading the file output by the system's log listener. Going
beyond that (to arbitrary log listener output files) is not tenable.
The intention of the .log file was to give users some idea of why/how
something failed. It is reasonable to want to process this in some way but
it is not necessary that it be a complete serialization of the IStatus
objects. If someone wants that they can install a listener and output a
log in the appropriate format. The only real issue with the current
technology is that the messages logged before the system is up and this
additional log listener could be installed are only available in the .log
file. So, for example, PDE does not show these.
Summary: As Nick observed, publishing a DTD for the .log file is probably
the best bet here. We don't even have to add any API to read it. Xerces
is available to all. Also, the DTD need not go beyond what the
PlatformLogListener will write in the file.
Jeff
Nick_Edgar@xxxxxxx
Sent by: To: platform-core-dev@xxxxxxxxxxx
platform-core-dev-admin@e cc:
clipse.org Subject: Re: [platform-core-dev] Comments
on RFC 0003: Log File Retrieval
12/06/2001 10:10 PM
Please respond to
platform-core-dev
I have a few more questions / points:
There is extra API for contributing and listening to the log. See
org.eclipse.core.runtime.Plugin.getLog(), ILog, and ILogListener.
So in addition to the APIs on Platform (which duplicate 75% of ILog), there
is a log per plugin. Each can have its own listeners.
However, currently all logs contribute to the same .log file.
Any API for retrieving log entries would have to take the per-plugin
scenario into account. The proposal currently only lets you get at the
Platform log's contents.
If I ask a plugin's log for its entries, do I get just the entries for that
plugin, or all of them?
What should a UI present here, just the Platform log or individual logs per
plugin as well?
Also, simply serializing/deserializing the info available via IStatus is
not enough. For example, org.eclipse.core.resources defines
IResourceStatus/ResourceStatus which extends IStatus/Status with a path
attribute, in addition to defining its own status codes.
The current log format does not capture such extra attributes. This is
potentially valuable information which is getting lost.
In addition, it would be nice to have a human-readable representation of
the codes in any log UI (I don't believe this is guaranteed to be redundant
with the message).
If you want to save extra attributes and/or human-readable codes in the
log, the status object itself will have to get involved in its
serialization.
If you want to deserialize it as the same class, you will need to serialize
the class name and plugin name, and will run into plugin startup issues
(i.e. this is a non-starter).
As mentioned, you already run into some problems with deserializing
exceptions as strings rather than full objects, so you probably can't use
just IStatus as the result of reading the log.
It seems like a simple approach like publishing the XML DTD is looking more
and more tasty. You could add convenience APIs for getting the location
for the platform log (or arbitrary ILog), and for pulling out key
attributes. Having such APIs might make any UI (or other clients) more
resilient to any evolution of the DTD. They may just be a convenience
though, since any evolution of the DTD would have to be backwards
compatible if the DTD is published.
I would still recommend allowing status subclasses to include their extra
attributes and human-readable codes though.
Nick
|--------+----------------------------------->
| | John_Arthorne@xxxxxxx |
| | Sent by: |
| | platform-core-dev-admin@e|
| | clipse.org |
| | |
| | |
| | 12/06/01 06:45 PM |
| | Please respond to |
| | platform-core-dev |
| | |
|--------+----------------------------------->
>
-----------------------------------------------------------------------------------------------------------|
|
|
| To: platform-core-dev@xxxxxxxxxxx
|
| cc:
|
| Subject: Re: [platform-core-dev] Comments on RFC 0003: Log
File Retrieval |
>
-----------------------------------------------------------------------------------------------------------|
See my <JA></JA> comments below.
The log may be very long, especially considering the changes mentioned in
the plan to keep the log around longer than a single invocation.
It may be very memory-space intensive to read the whole thing in.
I recommend adding a parameter to retrieveLogContents specifying how many
items to retrieve (presumably starting from the end).
<JA>That's a good suggestion, thanks. "tail .log"...</JA>
It would be also be nice to be able to determine how many entries there
are, and retrieve an arbitrary range, but this would require more
information in the log file format to do this efficiently.
For example, imagine a view which lets you scroll or page through the log
without having to read the whole thing into memory at once.
This is probably less important than simply allowing a bounds on the
number of entries read.
<JA>I think there's a danger of trying to get too fancy with this. In the
end it's just a simple API to aid developers, and in the worst case the
developer can browse/grep the log file manually. With the richer XML
format, one could easily imagine wanting to do things like:
- return all statuses of a given severity
- return all errors that throw a given exception class
- return all log entries created within a given date range.
But honestly I think we've got more interesting features to work on. One
alternative is that we expose the log filename and DTD as API so third
parties can write whatever kind of fancy log reader they want...</JA>
Question: It looks like the log API only allows it to contain IStatus
objects. Is this any more restricted than the current support? I guess
not, but thought I'd ask.
<JA>Nope, this matches the converse API for writing to the log, which only
allows IStatus objects to be written.</JA>
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev
