Logging Question

N

Novice

I have a question about the standard Java logging.

I am using the Java classes to create an XML log. Is there any way that I
can insert an extra line in the XML generated by the logging classes
programmatically? That extra line is NOT a log record, it is an
<xsl:stylesheet> tag. I have a specific XSL file that I'd like to format
the XML with and it would be rather convenient to have the program insert
that line in the XML file.

I've poked around the API and the documentation on logging but don't see
anything like this. It seems like a simple enough thing that I'd like to
believe this kind of thing was provided for....
 
J

Jeff Higgins

I have a question about the standard Java logging.

I am using the Java classes to create an XML log. Is there any way that I
can insert an extra line in the XML generated by the logging classes
programmatically? That extra line is NOT a log record, it is an
<xsl:stylesheet> tag. I have a specific XSL file that I'd like to format
the XML with and it would be rather convenient to have the program insert
that line in the XML file.

I've poked around the API and the documentation on logging but don't see
anything like this. It seems like a simple enough thing that I'd like to
believe this kind of thing was provided for....
This fellow uses java.util.logging.Formatter.getHead(Handler h).
<http://forward.com.au/javaProgramming/javaGuiTips/javaLogging.html>
 
L

Lew

Novice said:
I have a question about the standard Java logging.

I am using the Java classes to create an XML log. Is there any way that I
can insert an extra line in the XML generated by the logging classes
programmatically? That extra line is NOT a log record, it is an
<xsl:stylesheet> tag. I have a specific XSL file that I'd like to format
the XML with and it would be rather convenient to have the program insert
that line in the XML file.

Why do you want to format the XML?
I've poked around the API and the documentation on logging but don't see
anything like this. It seems like a simple enough thing that I'd like to
believe this kind of thing was provided for....

Simple doesn't mean that a class is designed for it. Otherwise there'd only be
one class in all of Java that did all simple things. So obviously the
reasoning that it's "simple enough ... that I'd like to believe this kind of
thing was provided for.... [sic]" is fallacious. (So is the premise that it's
a simple thing, but that fallacy is irrelevant because even if it were simple
it wouldn't matter.)

In fact I've never heard of such a thing being built in to j.u.logging and it
would surprise the hell out of me if it were. Anyhow I, too, was unable to
find anything like that built in to j.u.logging, probably because it really
isn't there.

OTOH, perhaps you can take the log file output and post-process it. That would
depend on the transformation you intend to perform and its use case. If those
support the approach, you can use Java's standard XML tools to do the
transformation. Or you can use XSLT to post-process the file.
 
N

Novice

Why do you want to format the XML?
Because it's much easier to read that way :)
I've poked around the API and the documentation on logging but don't
see anything like this. It seems like a simple enough thing that I'd
like to believe this kind of thing was provided for....

Simple doesn't mean that a class is designed for it. Otherwise
there'd only be one class in all of Java that did all simple things.
So obviously the reasoning that it's "simple enough ... that I'd like
to believe this kind of thing was provided for.... [sic]" is
fallacious. (So is the premise that it's a simple thing, but that
fallacy is irrelevant because even if it were simple it wouldn't
matter.)
Given that the logging classes have the ability to write XML and given
that XML may be substantially easier to read if formatted, it seemed
reasonable to think that the logging classes might include the capability
to specify the stylesheet that might be applied to that XML. I didn't say
that they MUST have that capability, just that it seems like the kind of
thing that MIGHT be there.
In fact I've never heard of such a thing being built in to j.u.logging
and it would surprise the hell out of me if it were. Anyhow I, too,
was unable to find anything like that built in to j.u.logging,
probably because it really isn't there.
I could get the effect what I wanted by adding a single line to the
getHead method of XMLFormatter. But I'm not sure how to subclass a class
that I never invoke directly myself. Where would I put my
"CustomizedXMLFormatter" class? In the same package as the rest of the
program that uses it?
OTOH, perhaps you can take the log file output and post-process it.
That would depend on the transformation you intend to perform and its
use case. If those support the approach, you can use Java's standard
XML tools to do the transformation.

Which tools are you thinking of? I haven't done much XML stuff in Java.
Or you can use XSLT to
post-process the file.
That would actually be my preference. I have a decent XSLT file that
formats my log records just the way I want to see them. I'm just trying
to avoid manually adding in that xsl:spreadsheet line in each log file
after it is written. That's just tedious.

But post-processing is certainly an option. I could always write an Ant
script to insert that xsl:spreadsheet line in the existing file. I'd have
to run the Ant script each time which would actually be more work than
pasting the extra line in manually.... That's the way it goes sometimes:
the amount of work you have to do to do something elegantly is
substantially more than if you just did something manually like pasting
in a single line.
 
J

Jeff Higgins

Why do you want to format the XML?
Because it's much easier to read that way :)
I've poked around the API and the documentation on logging but don't
see anything like this. It seems like a simple enough thing that I'd
like to believe this kind of thing was provided for....

Simple doesn't mean that a class is designed for it. Otherwise
there'd only be one class in all of Java that did all simple things.
So obviously the reasoning that it's "simple enough ... that I'd like
to believe this kind of thing was provided for.... [sic]" is
fallacious. (So is the premise that it's a simple thing, but that
fallacy is irrelevant because even if it were simple it wouldn't
matter.)
Given that the logging classes have the ability to write XML and given
that XML may be substantially easier to read if formatted, it seemed
reasonable to think that the logging classes might include the capability
to specify the stylesheet that might be applied to that XML. I didn't say
that they MUST have that capability, just that it seems like the kind of
thing that MIGHT be there.
In fact I've never heard of such a thing being built in to j.u.logging
and it would surprise the hell out of me if it were. Anyhow I, too,
was unable to find anything like that built in to j.u.logging,
probably because it really isn't there.
I could get the effect what I wanted by adding a single line to the
getHead method of XMLFormatter. But I'm not sure how to subclass a class
that I never invoke directly myself. Where would I put my
"CustomizedXMLFormatter" class? In the same package as the rest of the
program that uses it?

Anywhere you care to I suppose. See Handler.setFormatter method and
property. See "java+logging+configuration"
Which tools are you thinking of? I haven't done much XML stuff in Java.

That would actually be my preference. I have a decent XSLT file that
formats my log records just the way I want to see them. I'm just trying
to avoid manually adding in that xsl:spreadsheet line in each log file
after it is written. That's just tedious.

But post-processing is certainly an option. I could always write an Ant
script to insert that xsl:spreadsheet line in the existing file.

That would be fairly ironic, seein's how Ant uses their own custom
Formatter for (styled)XML output.

I'd have
 
N

Novice

Novice wrote:
I have a question about the standard Java logging.

I am using the Java classes to create an XML log. Is there any way
that I can insert an extra line in the XML generated by the logging
classes programmatically? That extra line is NOT a log record, it
is an<xsl:stylesheet> tag. I have a specific XSL file that I'd
like to format the XML with and it would be rather convenient to
have the program insert that line in the XML file.

Why do you want to format the XML?
Because it's much easier to read that way :)
I've poked around the API and the documentation on logging but
don't see anything like this. It seems like a simple enough thing
that I'd like to believe this kind of thing was provided for....

Simple doesn't mean that a class is designed for it. Otherwise
there'd only be one class in all of Java that did all simple things.
So obviously the reasoning that it's "simple enough ... that I'd
like to believe this kind of thing was provided for.... [sic]" is
fallacious. (So is the premise that it's a simple thing, but that
fallacy is irrelevant because even if it were simple it wouldn't
matter.)
Given that the logging classes have the ability to write XML and
given that XML may be substantially easier to read if formatted, it
seemed reasonable to think that the logging classes might include the
capability to specify the stylesheet that might be applied to that
XML. I didn't say that they MUST have that capability, just that it
seems like the kind of thing that MIGHT be there.
In fact I've never heard of such a thing being built in to
j.u.logging and it would surprise the hell out of me if it were.
Anyhow I, too, was unable to find anything like that built in to
j.u.logging, probably because it really isn't there.
I could get the effect what I wanted by adding a single line to the
getHead method of XMLFormatter. But I'm not sure how to subclass a
class that I never invoke directly myself. Where would I put my
"CustomizedXMLFormatter" class? In the same package as the rest of
the program that uses it?

Anywhere you care to I suppose. See Handler.setFormatter method and
property. See "java+logging+configuration"
Yes! I simply copied XMLFormatter from the Java source file, added one
line to setHead() to make it add the xsl:stylesheet line, and put the new
class in the same package as my program. Then I looked up the handler for
the logger that I had assigned, which was FileHandler, and set its
formatter to new StyledXMLFormatter(). I ran the program and the log file
had the desired stylesheet info in it, exactly as I wanted.

I _knew_ I should just be able to subclass XMLFormatter and use a
modified version of that one method but it seemed harder than that for
some reason.

Thanks to you - and Lew - for helping me clarify my thoughts.
 
S

Stefan Ram

Novice said:
Yes! I simply copied XMLFormatter from the Java source file, added one

A log file should remain usable even when the process was terminated
abnormally. But an XML file needs to have one single root element
that has an end tag at its end. A process that is being terminated
abnormally might not write such an end tag. So, one has no guarantee
that the log output is well-formed XML. Or did I miss something?
 
J

Jeff Higgins

A

Arved Sandstrom

And let's face it, the <log> document element in this case is useless.
It conveys zero information. It would better to regard each record as a
separate well-formed XML document, and the file is merely physical
storage for a bunch of log records.

This kind of XML "wrapper" element, as in <log> in this case, happens
when folks think that 1 XML document == 1 physical file. An XML document
entity is a logical, not a physical storage, concept.

AHS
 
J

Jeff Higgins

And let's face it, the<log> document element in this case is useless.
It conveys zero information. It would better to regard each record as a
separate well-formed XML document, and the file is merely physical
storage for a bunch of log records.

This kind of XML "wrapper" element, as in<log> in this case, happens
when folks think that 1 XML document == 1 physical file. An XML document
entity is a logical, not a physical storage, concept.
Rodger. That brings up the interesting possibility of an Berkeley DB
(XML) Logger.
 
T

Tom Anderson

And let's face it, the <log> document element in this case is useless.
It conveys zero information. It would better to regard each record as a
separate well-formed XML document, and the file is merely physical
storage for a bunch of log records.

What happens if you throw such a file into a normal XML parser?

I would imagine that if you're using StAX, you can stop parsing when you
hit the end of a root element, and then either carry on to the next one,
or perhaps wrap a fresh parser round the underlying input stream.

I have no idea what a SAX parser would do; i don't know how much
well-formedness checking they do.

What would a DOM parser do?

You might need to interpolate a layer between the parser and the
FileInputStream to notionally split the file into substreams, one per
document. That would require some sort of framing format for the file, i
think.
This kind of XML "wrapper" element, as in <log> in this case, happens
when folks think that 1 XML document == 1 physical file. An XML document
entity is a logical, not a physical storage, concept.

Well, it is physical (quoth the spec: "Each XML document has both a
logical and a physical structure."), but it's a physical thing distinct
from a file, and doesn't have to map directly on to it. The spec says "A
data object is an XML document if ..." and "A textual object is a
well-formed XML document if ...", but never gets any more specific than
that.

tom
 
J

Jeff Higgins

What happens if you throw such a file into a normal XML parser?

I would imagine that if you're using StAX, you can stop parsing when you
hit the end of a root element, and then either carry on to the next one,
or perhaps wrap a fresh parser round the underlying input stream.

I have no idea what a SAX parser would do; i don't know how much
well-formedness checking they do.

What would a DOM parser do?

You might need to interpolate a layer between the parser and the
FileInputStream to notionally split the file into substreams, one per
document. That would require some sort of framing format for the file, i
think.

The java.util.logging.XMLFormatter follows the DTD described in the
Appendix.* You are free to write a formatter that follows your own DTD.

*I've dropped the link, but it is upthread somewhere.
 
J

Jeff Higgins

The java.util.logging.XMLFormatter follows the DTD described in the
Appendix.* You are free to write a formatter that follows your own DTD.
Just as the abstract java.util.logging.Handler is available for you to
write to the persistent container of your choice. Well, they call it
export in the javadoc.
 
T

Tom Anderson

The java.util.logging.XMLFormatter follows the DTD described in the
Appendix.* You are free to write a formatter that follows your own DTD.

No, i was talking about Arved's idea of putting multiple XML documents in
a single file. Did you read and understand Arved's post?

tom
 
A

Arved Sandstrom

What happens if you throw such a file into a normal XML parser?

I would imagine that if you're using StAX, you can stop parsing when you
hit the end of a root element, and then either carry on to the next one,
or perhaps wrap a fresh parser round the underlying input stream.
I have no idea what a SAX parser would do; i don't know how much
well-formedness checking they do.

One thing that works with stream parsing is to fool the parser with a
fake starting document element tag...like <log>. :) Given that, SAX or
StAX will parse forever, or until end of file/stream anyway.

If you didn't fake out the parser it would choke with a well-formedness
error after the first "record".

You can get quite innovative (read hackish) by doing stuff like:

final ByteArrayInputStream bsBegin =
new ByteArrayInputStream("<wrapper>".getBytes());
URL fileUrl = new URL(...);
final InputStream in = fileUrl.openStream();
final ByteArrayInputStream bsEnd =
new ByteArrayInputStream("</wrapper>".getBytes());

SequenceInputStream sis = new SequenceInputStream(new Enumeration() {

int index = 0;
InputStream streams[] = new InputStream[] {bsBegin, in, bsEnd};

@Override
public boolean hasMoreElements() {
return index < streams.length;
}

@Override
public Object nextElement() {
return streams[index++];
}

});

XMLInputFactory factory = XMLInputFactory.newInstance();
XMLStreamReader parser = factory.createXMLStreamReader(sis);

**********
The point here being is that the "real" input wasn't well-formed at all,
but by the time the parser sees it, it's fine.

Any of your ideas would be cool, too. After all we are just trying to
get a job done.
What would a DOM parser do?

It fails when the underlying stream parsing fails, I would think.
You might need to interpolate a layer between the parser and the
FileInputStream to notionally split the file into substreams, one per
document. That would require some sort of framing format for the file, i
think.


Well, it is physical (quoth the spec: "Each XML document has both a
logical and a physical structure."), but it's a physical thing distinct
from a file, and doesn't have to map directly on to it. The spec says "A
data object is an XML document if ..." and "A textual object is a
well-formed XML document if ...", but never gets any more specific than
that.

tom
Completely different approach, and it might even be the most "valid"
approach, would be to consider each log "record" to be an XML fragment.
But I wouldn't actually contemplate doing things that way, I'd
pre-process somehow, using the ideas we've already brought out.

AHS
 
D

Donkey Hottie

5.1.2012 2:28, Arved Sandstrom kirjoitti:
One thing that works with stream parsing is to fool the parser with a
fake starting document element tag...like <log>. :) Given that, SAX or
StAX will parse forever, or until end of file/stream anyway.

The Stream can be a StringStream. I once implemented a logging system,
which did read the data from file into individual Strings and passed
those to SAX. The implementation wrote the log files with out a root
element, and once a day it "logrotated", and added the root element to
the daily log for completeness.
 
T

Tom Anderson

One thing that works with stream parsing is to fool the parser with a
fake starting document element tag...like <log>. :) Given that, SAX or
StAX will parse forever, or until end of file/stream anyway.

If you didn't fake out the parser it would choke with a well-formedness
error after the first "record".
Okay.

You can get quite innovative (read hackish) by doing stuff like:

final ByteArrayInputStream bsBegin =
new ByteArrayInputStream("<wrapper>".getBytes());
URL fileUrl = new URL(...);
final InputStream in = fileUrl.openStream();
final ByteArrayInputStream bsEnd =
new ByteArrayInputStream("</wrapper>".getBytes());

SequenceInputStream sis = new SequenceInputStream(

Always good to see SequenceInputStream!
new Enumeration() {

int index = 0;
InputStream streams[] = new InputStream[] {bsBegin, in, bsEnd};

@Override
public boolean hasMoreElements() {
return index < streams.length;
}

@Override
public Object nextElement() {
return streams[index++];
}

});

Perhaps easier to do Collections.enumeration(Arrays.asList(bsBegin, in, bsEnd)).
The point here being is that the "real" input wasn't well-formed at all,
but by the time the parser sees it, it's fine.

Yes, good trick. As a general pattern (topping and tailing some stream of
items with start-container and end-container markers), it's useful in all
sorts of places. Admittedly most when dealing with XML.
Completely different approach, and it might even be the most "valid"
approach, would be to consider each log "record" to be an XML fragment.

Is there any support for getting parsers to parse multiple fragments from
a single stream? If not, we're back to needing to frame the stream in some
way, and then we might as well parse it as a sequence of documents. I'm
pretty hazy on what the point of document fragments is, really.

tom
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Logging 0
Logging problem 32
Additional logging questions 17
Java Logging Question 24
Making a logging handler that produces context. 0
Logging - Best Practices 4
python logging module:a quick question 0
Logging 9

Members online

No members online now.

Forum statistics

Threads
473,770
Messages
2,569,583
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top