SimpleFormatter Question

I'm experimenting with java.util.logging.SimpleFormatter and I've run
into a problem.

The API
(http://docs.oracle.com/javase/7/docs.../SimpleFormatt
er.html) says that you can control the format of a simple log via the
java.util.logging.SimpleFormatter.format property; a bunch of variables
are available as the value of the property. I put this value, copied
right out of the API, in my logging.properties:

java.util.logging.SimpleFormatter.format="%4$s: %5$s [%1$tc]%n"

This is supposed to yield a message that looks like this:

WARNING: warning message [Tue Mar 22 13:11:31 PDT 2011]

When I run my program though, the output looks like this:

9-Mar-2012 6:09:32 PM com.novice.common.LocalizationUtils getResources
SEVERE: The base name cannot be null.

In other words, the format I've specified is completely ignored.

What's the trick to make the program use the format I've specified? I'm
confident that the logging.properties file I've specified in my VM
argument is being used because it is naming my log file correctly. I'm
having trouble thinking of any other reason why this isn't working. Here
is my config file with all the comments stripped out.

================================================== ======================
handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
..level= ALL
java.util.logging.FileHandler.pattern = %h/Foo%u.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter =
java.util.logging.SimpleFormatter
java.util.logging.SimpleFormatter.format = "%4$s: %5$s [%1$tc]%n"
java.util.logging.FileHandler.level = ALL

java.util.logging.ConsoleHandler.level = INFO
java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter

com.novice.foo.level = ALL
java.level = WARNING
sun.level = WARNING
javax.level = WARNING
================================================== ======================

I can't see anything in the API that explains this and Google may be my
friend but it isn't helping me sort this out.

--
Novice

On 3/9/2012 8:40 PM, Novice wrote:
> I'm experimenting with java.util.logging.SimpleFormatter and I've run
> into a problem.
>
> The API
> (http://docs.oracle.com/javase/7/docs.../SimpleFormatt
> er.html) says that you can control the format of a simple log via the
> java.util.logging.SimpleFormatter.format property; a bunch of variables
> are available as the value of the property. I put this value, copied
> right out of the API, in my logging.properties:
>
> java.util.logging.SimpleFormatter.format="%4$s: %5$s [%1$tc]%n"
>
> This is supposed to yield a message that looks like this:
>
> WARNING: warning message [Tue Mar 22 13:11:31 PDT 2011]
>
> When I run my program though, the output looks like this:
>
> 9-Mar-2012 6:09:32 PM com.novice.common.LocalizationUtils getResources
> SEVERE: The base name cannot be null.
>
> In other words, the format I've specified is completely ignored.
>
> What's the trick to make the program use the format I've specified? I'm
> confident that the logging.properties file I've specified in my VM
> argument is being used because it is naming my log file correctly. I'm
> having trouble thinking of any other reason why this isn't working. Here
> is my config file with all the comments stripped out.
>
> ================================================== ======================
> handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
> .level= ALL
> java.util.logging.FileHandler.pattern = %h/Foo%u.log
> java.util.logging.FileHandler.limit = 50000
> java.util.logging.FileHandler.count = 1
> java.util.logging.FileHandler.formatter =
> java.util.logging.SimpleFormatter
> java.util.logging.SimpleFormatter.format = "%4$s: %5$s [%1$tc]%n"
> java.util.logging.FileHandler.level = ALL
>
> java.util.logging.ConsoleHandler.level = INFO
> java.util.logging.ConsoleHandler.formatter =
> java.util.logging.SimpleFormatter
>
> com.novice.foo.level = ALL
> java.level = WARNING
> sun.level = WARNING
> javax.level = WARNING
> ================================================== ======================
>
> I can't see anything in the API that explains this and Google may be my
> friend but it isn't helping me sort this out.

Are you using Java 7?

The docs are for Java 7 and that property does not seem to
work for Java 6.

Arne

Arne Vajhøj <arne@vajhoej.dk> wrote in
news:4f5ab90d$0$289$14726298@news.sunsite.dk:

> On 3/9/2012 8:40 PM, Novice wrote:
>> I'm experimenting with java.util.logging.SimpleFormatter and I've run
>> into a problem.
>>
>> The API
>> (http://docs.oracle.com/javase/7/docs...ing/SimpleForm
>> att er.html) says that you can control the format of a simple log via
>> the java.util.logging.SimpleFormatter.format property; a bunch of
>> variables are available as the value of the property. I put this
>> value, copied right out of the API, in my logging.properties:
>>
>> java.util.logging.SimpleFormatter.format="%4$s: %5$s [%1$tc]%n"
>>
>> This is supposed to yield a message that looks like this:
>>
>> WARNING: warning message [Tue Mar 22 13:11:31 PDT 2011]
>>
>> When I run my program though, the output looks like this:
>>
>> 9-Mar-2012 6:09:32 PM com.novice.common.LocalizationUtils
>> getResources SEVERE: The base name cannot be null.
>>
>> In other words, the format I've specified is completely ignored.
>>
>> What's the trick to make the program use the format I've specified?
>> I'm confident that the logging.properties file I've specified in my
>> VM argument is being used because it is naming my log file correctly.
>> I'm having trouble thinking of any other reason why this isn't
>> working. Here is my config file with all the comments stripped out.
>>
>> ================================================== ====================
>> == handlers= java.util.logging.FileHandler,
>> java.util.logging.ConsoleHandler .level= ALL
>> java.util.logging.FileHandler.pattern = %h/Foo%u.log
>> java.util.logging.FileHandler.limit = 50000
>> java.util.logging.FileHandler.count = 1
>> java.util.logging.FileHandler.formatter =
>> java.util.logging.SimpleFormatter
>> java.util.logging.SimpleFormatter.format = "%4$s: %5$s [%1$tc]%n"
>> java.util.logging.FileHandler.level = ALL
>>
>> java.util.logging.ConsoleHandler.level = INFO
>> java.util.logging.ConsoleHandler.formatter =
>> java.util.logging.SimpleFormatter
>>
>> com.novice.foo.level = ALL
>> java.level = WARNING
>> sun.level = WARNING
>> javax.level = WARNING
>> ================================================== ====================
>> ==
>>
>> I can't see anything in the API that explains this and Google may be
>> my friend but it isn't helping me sort this out.
>
> Are you using Java 7?
>
> The docs are for Java 7 and that property does not seem to
> work for Java 6.
>
I think you've solved it!

I have both Java 6 and 7 in Eclipse but this particular project is using
Java 6. I've just started using the Java 7 API though. I just assumed
that what I was seeing in the Java 7 API had been there for the last few
versions of Java but I didn't verify that. It seems I've stumbled on a
feature new to Java 7....

In that case, my problem is easily solved: just point the project to the
Java 7 compiler.

Thanks Arne! I don't think I would have found that problem on my own any
time soon!


--
Novice

Novice <novice@example..com> wrote in news:XnsA011F1BB1A949jpnasty@
94.75.214.39:

> Arne Vajhøj <arne@vajhoej.dk> wrote in
> news:4f5ab90d$0$289$14726298@news.sunsite.dk:
>
>> On 3/9/2012 8:40 PM, Novice wrote:
>>> I'm experimenting with java.util.logging.SimpleFormatter and I've run
>>> into a problem.
>>>
>>> The API
>>>
(http://docs.oracle.com/javase/7/docs...ing/SimpleForm
>>> att er.html) says that you can control the format of a simple log via
>>> the java.util.logging.SimpleFormatter.format property; a bunch of
>>> variables are available as the value of the property. I put this
>>> value, copied right out of the API, in my logging.properties:
>>>
>>> java.util.logging.SimpleFormatter.format="%4$s: %5$s [%1$tc]%n"
>>>
>>> This is supposed to yield a message that looks like this:
>>>
>>> WARNING: warning message [Tue Mar 22 13:11:31 PDT 2011]
>>>
>>> When I run my program though, the output looks like this:
>>>
>>> 9-Mar-2012 6:09:32 PM com.novice.common.LocalizationUtils
>>> getResources SEVERE: The base name cannot be null.
>>>
>>> In other words, the format I've specified is completely ignored.
>>>
>>> What's the trick to make the program use the format I've specified?
>>> I'm confident that the logging.properties file I've specified in my
>>> VM argument is being used because it is naming my log file correctly.
>>> I'm having trouble thinking of any other reason why this isn't
>>> working. Here is my config file with all the comments stripped out.
>>>
>>>
================================================== ====================
>>> == handlers= java.util.logging.FileHandler,
>>> java.util.logging.ConsoleHandler .level= ALL
>>> java.util.logging.FileHandler.pattern = %h/Foo%u.log
>>> java.util.logging.FileHandler.limit = 50000
>>> java.util.logging.FileHandler.count = 1
>>> java.util.logging.FileHandler.formatter =
>>> java.util.logging.SimpleFormatter
>>> java.util.logging.SimpleFormatter.format = "%4$s: %5$s [%1$tc]%n"
>>> java.util.logging.FileHandler.level = ALL
>>>
>>> java.util.logging.ConsoleHandler.level = INFO
>>> java.util.logging.ConsoleHandler.formatter =
>>> java.util.logging.SimpleFormatter
>>>
>>> com.novice.foo.level = ALL
>>> java.level = WARNING
>>> sun.level = WARNING
>>> javax.level = WARNING
>>>
================================================== ====================
>>> ==
>>>
>>> I can't see anything in the API that explains this and Google may be
>>> my friend but it isn't helping me sort this out.
>>
>> Are you using Java 7?
>>
>> The docs are for Java 7 and that property does not seem to
>> work for Java 6.
>>
> I think you've solved it!
>
> I have both Java 6 and 7 in Eclipse but this particular project is
using
> Java 6. I've just started using the Java 7 API though. I just assumed
> that what I was seeing in the Java 7 API had been there for the last
few
> versions of Java but I didn't verify that. It seems I've stumbled on a
> feature new to Java 7....
>
> In that case, my problem is easily solved: just point the project to
the
> Java 7 compiler.
>
> Thanks Arne! I don't think I would have found that problem on my own
any
> time soon!
>
>

One followup question. When I tried this in my logging.properties:

java.util.logging.SimpleFormatter.format = "%4$s: %5$s [%1$tc]%n"

The log messages included quotes that weren't found in the result
predicted by the SimpleFormatter documentation. When I removed the quotes
from the line I've just quoted, the messages came out the way they were
supposed to.

In other words, it appears that the quotes shown in the Javadoc don't
belong there. Should I be filing a Bugzilla for that so that Oracle can
fix the documentation? Or is there a different procedure to follow?

Of course, someone may have already filed a report for this small error;
I haven't checked yet. And maybe this error is so small and obvious that
anyone would figure it out as quickly as I did.

--
Novice

On 12-03-10 12:57 AM, Novice wrote:
[ SNIP ]
>
> One followup question. When I tried this in my logging.properties:
>
> java.util.logging.SimpleFormatter.format = "%4$s: %5$s [%1$tc]%n"
>
> The log messages included quotes that weren't found in the result
> predicted by the SimpleFormatter documentation. When I removed the quotes
> from the line I've just quoted, the messages came out the way they were
> supposed to.
>
> In other words, it appears that the quotes shown in the Javadoc don't
> belong there. Should I be filing a Bugzilla for that so that Oracle can
> fix the documentation? Or is there a different procedure to follow?
>
> Of course, someone may have already filed a report for this small error;
> I haven't checked yet. And maybe this error is so small and obvious that
> anyone would figure it out as quickly as I did.
>
Read up on Properties, especially
http://docs.oracle.com/javase/6/docs...java.io.Reader).

Quotes aren't special as far as Properties is concerned. How special
they are depends on what does the "load" and eventually uses the values
(RHS of the key=value pair). More often than not a quote does have
special meaning there, and you might end up either double-quoting in the
properties file or doing some more quoting in the client code. But if a
quote isn't special to a particular user, then it'll just be another
character.

It's not small and obvious, no. This kind of documentation error
presumably has frustrated a fair few people. I don't know why the
SimpleFormatter documentors made that mistake; they likely didn't
understand Properties either.

You could *check* Bugzilla to see if it's already noted.

Lesson learned: supposedly authoritative documentation has its fair
share of errors, some much worse than what you just encountered.

AHS

--
Last week I helped my friend stay put. It's a lot easier'n helpin' 'em
move. I just went over to his house and made sure that he did not start
to load shit into a truck.
-- Mitch Hedberg

On 3/9/2012 11:57 PM, Novice wrote:
> Novice<novice@example..com> wrote in news:XnsA011F1BB1A949jpnasty@
> 94.75.214.39:
>
>> Arne Vajhøj<arne@vajhoej.dk> wrote in
>> news:4f5ab90d$0$289$14726298@news.sunsite.dk:
>>
>>> On 3/9/2012 8:40 PM, Novice wrote:
>>>> I'm experimenting with java.util.logging.SimpleFormatter and I've run
>>>> into a problem.
>>>>
>>>> The API
>>>>
> (http://docs.oracle.com/javase/7/docs...ing/SimpleForm
>>>> att er.html) says that you can control the format of a simple log via
>>>> the java.util.logging.SimpleFormatter.format property; a bunch of
>>>> variables are available as the value of the property. I put this
>>>> value, copied right out of the API, in my logging.properties:
>>>>
>>>> java.util.logging.SimpleFormatter.format="%4$s: %5$s [%1$tc]%n"
>>>>
>>>> This is supposed to yield a message that looks like this:
>>>>
>>>> WARNING: warning message [Tue Mar 22 13:11:31 PDT 2011]
>>>>
>>>> When I run my program though, the output looks like this:
>>>>
>>>> 9-Mar-2012 6:09:32 PM com.novice.common.LocalizationUtils
>>>> getResources SEVERE: The base name cannot be null.
>>>>
>>>> In other words, the format I've specified is completely ignored.
>>>>
>>>> What's the trick to make the program use the format I've specified?
>>>> I'm confident that the logging.properties file I've specified in my
>>>> VM argument is being used because it is naming my log file correctly.
>>>> I'm having trouble thinking of any other reason why this isn't
>>>> working. Here is my config file with all the comments stripped out.
>>>>
>>>>
> ================================================== ====================
>>>> == handlers= java.util.logging.FileHandler,
>>>> java.util.logging.ConsoleHandler .level= ALL
>>>> java.util.logging.FileHandler.pattern = %h/Foo%u.log
>>>> java.util.logging.FileHandler.limit = 50000
>>>> java.util.logging.FileHandler.count = 1
>>>> java.util.logging.FileHandler.formatter =
>>>> java.util.logging.SimpleFormatter
>>>> java.util.logging.SimpleFormatter.format = "%4$s: %5$s [%1$tc]%n"
>>>> java.util.logging.FileHandler.level = ALL
>>>>
>>>> java.util.logging.ConsoleHandler.level = INFO
>>>> java.util.logging.ConsoleHandler.formatter =
>>>> java.util.logging.SimpleFormatter
>>>>
>>>> com.novice.foo.level = ALL
>>>> java.level = WARNING
>>>> sun.level = WARNING
>>>> javax.level = WARNING
>>>>
> ================================================== ====================
>>>> ==
>>>>
>>>> I can't see anything in the API that explains this and Google may be
>>>> my friend but it isn't helping me sort this out.
>>>
>>> Are you using Java 7?
>>>
>>> The docs are for Java 7 and that property does not seem to
>>> work for Java 6.
>>>
>> I think you've solved it!
>>
>> I have both Java 6 and 7 in Eclipse but this particular project is
> using
>> Java 6. I've just started using the Java 7 API though. I just assumed
>> that what I was seeing in the Java 7 API had been there for the last
> few
>> versions of Java but I didn't verify that. It seems I've stumbled on a
>> feature new to Java 7....
>>
>> In that case, my problem is easily solved: just point the project to
> the
>> Java 7 compiler.
>>
>> Thanks Arne! I don't think I would have found that problem on my own
> any
>> time soon!
>>
>
> One followup question. When I tried this in my logging.properties:
>
> java.util.logging.SimpleFormatter.format = "%4$s: %5$s [%1$tc]%n"
>
> The log messages included quotes that weren't found in the result
> predicted by the SimpleFormatter documentation. When I removed the quotes
> from the line I've just quoted, the messages came out the way they were
> supposed to.

AH - I also fixed that before I tried with Java 7.

But as it did not make a difference in itself, then I did
not think it was necessary.

> In other words, it appears that the quotes shown in the Javadoc don't
> belong there. Should I be filing a Bugzilla for that so that Oracle can
> fix the documentation? Or is there a different procedure to follow?
>
> Of course, someone may have already filed a report for this small error;
> I haven't checked yet. And maybe this error is so small and obvious that
> anyone would figure it out as quickly as I did.

If it comes so far then I think a Java developer should become
suspicious about the quotes and try without them.

But the docs should obviously be correct.

Just file a bug and let Oracle look for duplicates.

Arne

Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote in
news:YDI6r.12585$wf.1272@newsfe09.iad:

> On 12-03-10 12:57 AM, Novice wrote:
> [ SNIP ]
>>
>> One followup question. When I tried this in my logging.properties:
>>
>> java.util.logging.SimpleFormatter.format = "%4$s: %5$s [%1$tc]%n"
>>
>> The log messages included quotes that weren't found in the result
>> predicted by the SimpleFormatter documentation. When I removed the
>> quotes from the line I've just quoted, the messages came out the way
>> they were supposed to.
>>
>> In other words, it appears that the quotes shown in the Javadoc don't
>> belong there. Should I be filing a Bugzilla for that so that Oracle
>> can fix the documentation? Or is there a different procedure to
>> follow?
>>
>> Of course, someone may have already filed a report for this small
>> error; I haven't checked yet. And maybe this error is so small and
>> obvious that anyone would figure it out as quickly as I did.
>>
> Read up on Properties, especially
> http://docs.oracle.com/javase/6/docs...ties.html#load
> (java.io.Reader).
>
> Quotes aren't special as far as Properties is concerned. How special
> they are depends on what does the "load" and eventually uses the
> values (RHS of the key=value pair). More often than not a quote does
> have special meaning there, and you might end up either double-quoting
> in the properties file or doing some more quoting in the client code.
> But if a quote isn't special to a particular user, then it'll just be
> another character.
>
> It's not small and obvious, no. This kind of documentation error
> presumably has frustrated a fair few people. I don't know why the
> SimpleFormatter documentors made that mistake; they likely didn't
> understand Properties either.
>
As errors go, this one wasn't very frustrating. The use of quotes seemed
a bit dubious from the first moment but I gave the Javadoc the benefit of
the doubt and coded with the quotes. But when I got superfluous quotes in
the output, I simply tried again with the quotes omitted and got the
result I'd expected to see.

> You could *check* Bugzilla to see if it's already noted.
>
I just checked and there's no previous report of this error. I expect
most people who encountered it figured it out in about 30 seconds and
couldn't be bothered to go through the rigamarole of reporting it ;-)

I'll put it on my "To Do" list as something to do when I get a bit more
time.

> Lesson learned: supposedly authoritative documentation has its fair
> share of errors, some much worse than what you just encountered.
>

I'm sure this error is small potatoes compared to some that have occurred
over the years ;-)

I just wanted to get a sense of whether this was too trivial to even
bother reporting. I'm getting the impression that my basic philosophy
should be that no error is too trivial to report.....

--
Novice

Novice wrote:
> I'm sure this error is small potatoes compared to some that have occurred
> over the years ;-)
>
> I just wanted to get a sense of whether this was too trivial to even
> bother reporting. I'm getting the impression that my basic philosophy
> should be that no error is too trivial to report.....

The only error that's "too trivial" to report is one that is correct behavior
of the program, i.e., not an error at all.

Allowing the question at all whether errors have a threshold of importance
even to bother reporting is a "camel's nose under the tent" strategy. What's
not reported cannot garner action. Where's the advantage?

And what constitutes "trivial" vs. "important"? The very definitions of those
terms applied to bugs are suspect at best, controversial for certain. A heart
attack might seem more important than a broken leg, unless you're the person
with the broken leg, or the heart attack is the criminal's and the broken leg
the victim's affliction.

Whether something is a bug is objective and inarguable. Either the behavior is
as intended or not.

How you should respond to a bug is a matter of triage. Regardless of whether
the heart attack is somehow more or less "important" than the broken leg, you
still have to choose one to handle first. The rules to do so can be pretty
clear without messy philosophical or political debate.

The most important management rule in triage scenarios, or any battle
situation, is support the operator on the ground. It's good leadership to
reward a proper action even if it fails. (We assume no actual dereliction
here.) Of course, the best reward is to give that person the job to write the
report on what happened, what failed, and how maybe to do better in future.
Just make sure you smile at them and thank them for their true commitment as
you give them the assignment.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg

Lew <noone@lewscanon.com> wrote in news:jjg6ej$uug$1@news.albasani.net:

> Novice wrote:
>> I'm sure this error is small potatoes compared to some that have
>> occurred over the years ;-)
>>
>> I just wanted to get a sense of whether this was too trivial to even
>> bother reporting. I'm getting the impression that my basic philosophy
>> should be that no error is too trivial to report.....
>
> The only error that's "too trivial" to report is one that is correct
> behavior of the program, i.e., not an error at all.
>
> Allowing the question at all whether errors have a threshold of
> importance even to bother reporting is a "camel's nose under the tent"
> strategy. What's not reported cannot garner action. Where's the
> advantage?
>
> And what constitutes "trivial" vs. "important"? The very definitions
> of those terms applied to bugs are suspect at best, controversial for
> certain. A heart attack might seem more important than a broken leg,
> unless you're the person with the broken leg, or the heart attack is
> the criminal's and the broken leg the victim's affliction.
>
> Whether something is a bug is objective and inarguable. Either the
> behavior is as intended or not.
>
> How you should respond to a bug is a matter of triage. Regardless of
> whether the heart attack is somehow more or less "important" than the
> broken leg, you still have to choose one to handle first. The rules to
> do so can be pretty clear without messy philosophical or political
> debate.
>
> The most important management rule in triage scenarios, or any battle
> situation, is support the operator on the ground. It's good leadership
> to reward a proper action even if it fails. (We assume no actual
> dereliction here.) Of course, the best reward is to give that person
> the job to write the report on what happened, what failed, and how
> maybe to do better in future. Just make sure you smile at them and
> thank them for their true commitment as you give them the assignment.
>

We're in agreement then. I was inclined to report it but I'm a bit anal
that way. I just wanted to make sure that you veterans didn't think it
too minor a problem to bother with the effort of reporting it.



--
Novice