Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11043 > unrolled thread

Logging Question

Back to article view | Back to comp.lang.java.programmer

Contents

  Logging Question Novice <novice@example..com> - 2011-12-31 21:27 +0000
    Re: Logging Question Jeff Higgins <jeff@invalid.invalid> - 2011-12-31 17:25 -0500
      Re: Logging Question Novice <novice@example..com> - 2012-01-01 01:46 +0000
    Re: Logging Question Lew <lewbloch@gmail.com> - 2011-12-31 14:53 -0800
      Re: Logging Question Novice <novice@example..com> - 2012-01-01 01:59 +0000
        Re: Logging Question Jeff Higgins <jeff@invalid.invalid> - 2011-12-31 22:14 -0500
          Re: Logging Question Novice <novice@example..com> - 2012-01-01 05:44 +0000
            Re: Logging Question Jeff Higgins <jeff@invalid.invalid> - 2012-01-01 07:59 -0500
              Re: Logging Question Jeff Higgins <jeff@invalid.invalid> - 2012-01-01 08:14 -0500
              Re: Logging Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-01 19:06 -0400
                Re: Logging Question Jeff Higgins <jeff@invalid.invalid> - 2012-01-01 18:24 -0500
                Re: Logging Question Tom Anderson <twic@urchin.earth.li> - 2012-01-03 15:33 +0000
                  Re: Logging Question Jeff Higgins <jeff@invalid.invalid> - 2012-01-03 11:21 -0500
                    Re: Logging Question Jeff Higgins <jeff@invalid.invalid> - 2012-01-03 11:35 -0500
                    Re: Logging Question Tom Anderson <twic@urchin.earth.li> - 2012-01-04 14:42 +0000
                      Re: Logging Question Jeff Higgins <jeff@invalid.invalid> - 2012-01-04 11:43 -0500
                  Re: Logging Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-04 20:28 -0400
                    Re: Logging Question Donkey Hottie <donkey@fredriksson.dy.fi> - 2012-01-05 11:28 +0200
                    Re: Logging Question Tom Anderson <twic@urchin.earth.li> - 2012-01-08 14:08 +0000
                      Re: Logging Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-09 19:47 -0400

#11043 — Logging Question

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....

-- 
Novice

[toc] | [next] | [standalone]

#11044

On 12/31/2011 04:27 PM, 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.
>
> 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>

[toc] | [prev] | [next] | [standalone]

#11046

Jeff Higgins <jeff@invalid.invalid> wrote in
news:jdo1qq$7mb$1@dont-email.me: 

> On 12/31/2011 04:27 PM, 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.
>>
>> 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>


Interesting. I'll have to look at his source code and see how he does what 
he's talking about....
 

-- 
Novice

[toc] | [prev] | [next] | [standalone]

#11045

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?

> 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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#11047

Lew <lewbloch@gmail.com> wrote in
news:9102298.933.1325372035497.JavaMail.geo-discussion-forums@prj1: 

> 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?
 
> 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.

-- 
Novice

[toc] | [prev] | [next] | [standalone]

#11048

On 12/31/2011 08:59 PM, Novice wrote:
> Lew<lewbloch@gmail.com>  wrote in
> news:9102298.933.1325372035497.JavaMail.geo-discussion-forums@prj1:
>
>> 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"

>
>> 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.

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

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.
>

[toc] | [prev] | [next] | [standalone]

#11049

Jeff Higgins <jeff@invalid.invalid> wrote in
news:jdoiob$phd$1@dont-email.me: 

> On 12/31/2011 08:59 PM, Novice wrote:
>> Lew<lewbloch@gmail.com>  wrote in
>> news:9102298.933.1325372035497.JavaMail.geo-discussion-forums@prj1:
>>
>>> 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.
-- 
Novice

[toc] | [prev] | [next] | [standalone]

#11051

On 01/01/2012 06:33 AM, Stefan Ram wrote:
> Novice<novice@example..com>  writes:
>> 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?
>
Only that there are no guarantees.
<http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview.html#a1.12>

[toc] | [prev] | [next] | [standalone]

#11052

On 01/01/2012 07:59 AM, Jeff Higgins wrote:
> On 01/01/2012 06:33 AM, Stefan Ram wrote:
>> Novice<novice@example..com> writes:
>>> 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?
>>
> Only that there are no guarantees.
> <http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview.html#a1.12>
>
>
Security section is also worth a read.
<http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview.html#a1.14>

[toc] | [prev] | [next] | [standalone]

#11054

On 12-01-01 08:59 AM, Jeff Higgins wrote:
> On 01/01/2012 06:33 AM, Stefan Ram wrote:
>> Novice<novice@example..com>  writes:
>>> 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?
>>
> Only that there are no guarantees.
> <http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview.html#a1.12>
> 
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
-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

[toc] | [prev] | [next] | [standalone]

#11055

On 01/01/2012 06:06 PM, Arved Sandstrom wrote:
> On 12-01-01 08:59 AM, Jeff Higgins wrote:
>> On 01/01/2012 06:33 AM, Stefan Ram wrote:
>>> Novice<novice@example..com>   writes:
>>>> 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?
>>>
>> Only that there are no guarantees.
>> <http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview.html#a1.12>
>>
> 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.

[toc] | [prev] | [next] | [standalone]

#11060

On Sun, 1 Jan 2012, Arved Sandstrom wrote:

> On 12-01-01 08:59 AM, Jeff Higgins wrote:
>> On 01/01/2012 06:33 AM, Stefan Ram wrote:
>>> Novice<novice@example..com>  writes:
>>>> 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?
>>
>> Only that there are no guarantees.
>> <http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview.html#a1.12>
>
> 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

-- 
I heard this from two different reliable sources on newsgroups. --
Peter Olcott

[toc] | [prev] | [next] | [standalone]

#11062

On 01/03/2012 10:33 AM, Tom Anderson wrote:
> On Sun, 1 Jan 2012, Arved Sandstrom wrote:
>
>> On 12-01-01 08:59 AM, Jeff Higgins wrote:
>>> On 01/01/2012 06:33 AM, Stefan Ram wrote:
>>>> Novice<novice@example..com> writes:
>>>>> 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?
>>>
>>> Only that there are no guarantees.
>>> <http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview.html#a1.12>
>>>
>>
>> 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.

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.

>
>> 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
>

[toc] | [prev] | [next] | [standalone]

#11063

On 01/03/2012 11:21 AM, Jeff Higgins wrote:
> On 01/03/2012 10:33 AM, Tom Anderson wrote:
>> On Sun, 1 Jan 2012, Arved Sandstrom wrote:
>>
>>> On 12-01-01 08:59 AM, Jeff Higgins wrote:
>>>> On 01/01/2012 06:33 AM, Stefan Ram wrote:
>>>>> Novice<novice@example..com> writes:

>
> 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.

[toc] | [prev] | [next] | [standalone]

#11067

On Tue, 3 Jan 2012, Jeff Higgins wrote:

> On 01/03/2012 10:33 AM, Tom Anderson wrote:
>> On Sun, 1 Jan 2012, Arved Sandstrom wrote:
>> 
>>>> On 01/01/2012 06:33 AM, Stefan Ram wrote:
>>>>
>>>>> 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.
>>> 
>>> 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.
>
> 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

-- 
Passersby were amazed by the unusually large amounts of blood.

[toc] | [prev] | [next] | [standalone]

#11068

On 01/04/2012 09:42 AM, Tom Anderson wrote:
> On Tue, 3 Jan 2012, Jeff Higgins wrote:
>
>> On 01/03/2012 10:33 AM, Tom Anderson wrote:
>>> On Sun, 1 Jan 2012, Arved Sandstrom wrote:
>>>
>>>>> On 01/01/2012 06:33 AM, Stefan Ram wrote:
>>>>>
>>>>>> 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.
>>>>
>>>> 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.
>>
>> 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?
>
Yep. Shrugs.

[toc] | [prev] | [next] | [standalone]

#11073

On 12-01-03 11:33 AM, Tom Anderson wrote:
> On Sun, 1 Jan 2012, Arved Sandstrom wrote:
> 
>> On 12-01-01 08:59 AM, Jeff Higgins wrote:
>>> On 01/01/2012 06:33 AM, Stefan Ram wrote:
>>>> Novice<novice@example..com>  writes:
>>>>> 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?
>>>
>>> Only that there are no guarantees.
>>> <http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview.html#a1.12>
>>>
>>
>> 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.

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.
> 
>> 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
> 
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

-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

[toc] | [prev] | [next] | [standalone]

#11076

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.

-- 

Increased knowledge will help you now.  Have mate's phone bugged.

[toc] | [prev] | [next] | [standalone]

#11104

On Wed, 4 Jan 2012, Arved Sandstrom wrote:

> On 12-01-03 11:33 AM, Tom Anderson wrote:
>> On Sun, 1 Jan 2012, Arved Sandstrom wrote:
>>
>>> 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? 
>> 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".

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

-- 
music is a interesting thing, DUN COMPARE AND PUT IT TO BLAR BLAR GENRE,
THIS IS A STUPID ACT......MUSIC IS SAME TO EVERYONE -- sihamze

[toc] | [prev] | [next] | [standalone]

#11149

On 12-01-08 10:08 AM, Tom Anderson wrote:
> On Wed, 4 Jan 2012, Arved Sandstrom wrote:
[ SNIP ]

>> 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)).

No perhaps about it! Thanks for reminding me of that method. I need to
make time to review core APIs every so often.

>> 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
> 
In the formal sense I'm not sure I see the point of them either.
Apparently neither does W3C.

AHS
-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web