SimpleFormatter Question

Discussion in 'Java' started by Novice, Mar 10, 2012.

  1. Novice

    Novice Guest

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

    The API
    (http://docs.oracle.com/javase/7/docs/api/java/util/logging/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
    Novice, Mar 10, 2012
    #1
    1. Advertising

  2. Novice

    Arne Vajhøj Guest

    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/api/java/util/logging/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, Mar 10, 2012
    #2
    1. Advertising

  3. Novice

    Novice Guest

    Arne Vajhøj <> wrote in
    news:4f5ab90d$0$289$:

    > 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/api/java/util/logging/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, Mar 10, 2012
    #3
  4. Novice

    Novice Guest

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

    > Arne Vajhøj <> wrote in
    > news:4f5ab90d$0$289$:
    >
    >> 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/api/java/util/logging/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
    Novice, Mar 10, 2012
    #4
  5. 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/api/java/util/Properties.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.

    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
    Arved Sandstrom, Mar 10, 2012
    #5
  6. Novice

    Arne Vajhøj Guest

    On 3/9/2012 11:57 PM, Novice wrote:
    > Novice<novice@example..com> wrote in news:XnsA011F1BB1A949jpnasty@
    > 94.75.214.39:
    >
    >> Arne Vajhøj<> wrote in
    >> news:4f5ab90d$0$289$:
    >>
    >>> 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/api/java/util/logging/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
    Arne Vajhøj, Mar 10, 2012
    #6
  7. Novice

    Novice Guest

    Arved Sandstrom <> wrote in
    news:YDI6r.12585$:

    > 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/api/java/util/Properties.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, Mar 10, 2012
    #7
  8. Novice

    Novice Guest

    Lew <> wrote in news:jjg6ej$uug$:

    > 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
    Novice, Mar 10, 2012
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sean
    Replies:
    1
    Views:
    589
    Cowboy \(Gregory A. Beamer\)
    Oct 20, 2003
  2. =?Utf-8?B?UnlhbiBTbWl0aA==?=

    Quick Question - Newby Question

    =?Utf-8?B?UnlhbiBTbWl0aA==?=, Feb 14, 2005, in forum: ASP .Net
    Replies:
    4
    Views:
    644
    Iain Norman
    Feb 16, 2005
  3. =?Utf-8?B?YW5kcmV3MDA3?=

    question row filter (more of sql query question)

    =?Utf-8?B?YW5kcmV3MDA3?=, Oct 5, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    939
    Scott Allen
    Oct 6, 2005
  4. Philip Meyer
    Replies:
    0
    Views:
    414
    Philip Meyer
    Nov 30, 2003
  5. nico
    Replies:
    3
    Views:
    441
    Arne Vajhøj
    Jan 19, 2008
Loading...

Share This Page