Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #12296 > unrolled thread
| Started by | Novice <novice@example..com> |
|---|---|
| First post | 2012-02-24 20:10 +0000 |
| Last post | 2012-02-25 00:22 +0000 |
| Articles | 20 on this page of 167 — 14 participants |
Back to article view | Back to comp.lang.java.programmer
Aspect questions? Novice <novice@example..com> - 2012-02-24 20:10 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-24 13:05 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 05:47 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-24 23:40 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 17:02 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 12:08 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 22:12 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 14:27 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 23:29 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 18:33 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 14:38 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 10:49 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 10:53 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 18:17 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 16:01 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 17:22 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 12:25 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 21:08 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 18:33 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 17:05 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 20:18 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 21:29 -0800
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-27 05:44 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-27 21:37 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-28 00:04 -0800
Re: Aspect questions? Patricia Shanahan <pats@acm.org> - 2012-02-28 01:39 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 14:54 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-28 17:24 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 04:53 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:08 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 05:12 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 21:38 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 17:27 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-27 12:22 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 22:50 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-27 17:24 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:00 +0000
Re: Aspect questions? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-29 09:14 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-29 09:55 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 21:31 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-29 23:06 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 04:33 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-03-04 23:00 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-04 17:07 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-03-05 15:33 +0000
JavaDoc linking (Was: Aspect questions?) Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-05 08:38 -0800
Re: JavaDoc linking (Was: Aspect questions?) Novice <novice@example..com> - 2012-03-05 17:40 +0000
Re: JavaDoc linking (Was: Aspect questions?) Patricia Shanahan <pats@acm.org> - 2012-03-05 21:25 -0800
Re: JavaDoc linking (Was: Aspect questions?) Arne Vajhøj <arne@vajhoej.dk> - 2012-03-06 17:23 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-05 23:45 -0800
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-06 06:03 -0400
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-06 21:05 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:11 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:09 -0500
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-26 23:43 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 05:20 +0000
Re: Aspect questions? Patricia Shanahan <pats@acm.org> - 2012-02-26 21:32 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 17:36 +0000
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 13:18 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 14:05 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 14:33 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 14:53 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 15:16 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 17:57 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 22:59 +0000
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-28 05:50 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:03 +0000
Re: Aspect questions? Patricia Shanahan <pats@acm.org> - 2012-02-27 13:17 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 22:55 +0000
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-27 05:58 -0400
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 18:14 +0000
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-28 00:12 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-02-28 02:04 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-27 21:22 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:11 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:14 -0500
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-28 23:09 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:25 +0000
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-01 00:22 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-03-01 01:44 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-29 23:24 -0800
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-01 21:19 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 01:52 +0000
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-03 01:39 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-03-05 15:38 +0000
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-05 22:50 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-05 23:46 -0800
Re: Aspect questions? Patricia Shanahan <pats@acm.org> - 2012-03-06 08:14 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-06 21:23 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-08 20:10 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 01:49 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-01 22:38 -0800
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-02 06:05 -0400
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 14:25 +0000
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-02 18:10 -0400
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 14:12 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-02 08:57 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-03-05 15:57 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-05 23:48 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-03-07 20:33 +0000
Re: Aspect questions? Lew <lewbloch@gmail.com> - 2012-03-07 13:09 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:20 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-02 14:28 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:16 -0500
Re: Aspect questions? markspace <-@.> - 2012-02-26 10:10 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 20:52 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 13:48 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 13:47 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 18:40 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 18:36 -0500
Re: Aspect questions? markspace <-@.> - 2012-02-26 16:04 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 19:38 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 17:09 -0800
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-26 20:08 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 19:43 -0500
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-27 22:03 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-27 21:18 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 13:43 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 01:11 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 21:49 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 18:37 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-27 12:28 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-28 00:55 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-27 17:37 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:57 +0000
Re: Aspect questions? Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-02-28 03:21 -0600
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-28 09:19 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-27 21:12 -0500
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-28 05:59 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-28 17:27 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 16:07 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:26 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 18:22 -0500
Re: Aspect questions? markspace <-@.> - 2012-02-25 20:22 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 22:20 -0800
Re: Aspect questions? markspace <-@.> - 2012-02-26 00:04 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 00:21 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 00:33 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 10:43 -0500
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-26 11:18 +0000
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-26 11:04 -0400
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-26 10:22 -0400
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 21:04 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 14:01 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 18:46 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 09:50 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 10:38 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 20:49 +0000
Re: Aspect questions? jlp <jlp@jlp.com> - 2012-02-25 09:47 +0100
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 17:03 +0000
Re: Aspect questions? jlp <jlp@jlp.com> - 2012-02-25 20:02 +0100
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-25 10:20 -0400
Re: Aspect questions? markspace <-@.> - 2012-02-25 08:18 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 12:04 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 17:17 +0000
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-25 18:40 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 18:18 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 09:21 -0500
Re: Aspect questions? Roedy Green <see_website@mindprod.com.invalid> - 2012-02-25 14:35 -0800
Re: Aspect questions? markspace <-@.> - 2012-02-24 14:30 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-24 19:47 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-24 20:52 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 09:31 -0500
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-25 11:05 -0400
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 12:20 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-24 19:00 -0500
Re: Aspect questions? Tom Anderson <twic@urchin.earth.li> - 2012-02-25 00:22 +0000
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-27 18:37 +0000 |
| Message-ID | <XnsA0068BC4D36F6jpnasty@94.75.214.39> |
| In reply to | #12422 |
Lew <noone@lewscanon.com> wrote in news:jif5gv$ih$1@news.albasani.net:
> Novice wrote:
>> Assuming that project Foo has a single package, com.novice.foo and
>> three classes, hickory, dickory, and dock, class hickory's logger
>> would be "com.novice.foo.hickory", class dickory's logger would be
>> "com.novice.foo.dickory" and class dock's logger would be
>> "com.novice.foo.dock".
>>
>> Is that right now?
>
> Yes.
>
> Only do follow the naming conventions:
>
> com.novice.foo.Hickory
> com.novice.foo.Dickory
> com.novice.foo.Dock
>
> ...
>> ... Each class is going to be getting it's own logger with
>>
>> Logger logger Logger.getLogger(getClass().getName());
>>
> ...
>> Yes, every class is already in one or another named package and has
>> been for a long time. I'm still struggling a bit over which classes
>> belong in the SAME package and which should not.
>
> As Patricia said, just make a decision and refactor later if you
> decide to.
>
>> My thinking is that classes in the Common PROJECT should also be in
>> packages that are distinct from the packages used for Projects Foo or
>> Bar, which will have names like "com.novice.foo" and
>> "com.novice.bar".
>
> Usually. You have to think of the consequences and decide if they're
> the consequences you intend.
>
>> I'm using separate packages now so that
>> similar things are together. (That just feels like the right thing to
>> do but so far, most of my "feelings" have been wrong!)
>
> It's the right thing to do. Now find a rationale why - there is one,
> since it is the right thing to do. That way if pressed to explain your
> feeling you can.
>
>> Right. That is gradually sinking in, believe it or not! In fact, I'm
>> just about ready to replace all of the existing nonsense that I've
>> been doing with a
>>
>> Logger logger = Logger.getLogger(getClass().getName());
>>
>> in all my classes.
>
> That's pretty much the idea I'm promoting, save for concerns of
> appropriate scope as discussed upthread.
>
>> So I want to end up with all of my classes in all of my Projects
>> writing to a single log?
>
> No.
>
>> Hmm. Yes, I suppose that makes sense. I need to review the whole
>> "inherit" aspect of logging but I've been thinking of one logger
>> equating to one log and that's not right, is it? See, the penny is
>> dropping....
>
> A logger is an object that writes to a log. There's no essential
> reason the ratio should be one to one. Au contraire, just like
> everything else in Java it's reasonable to expect multiple pointers to
> point to one thing and multiple writers to write to one output.
>
> Let me ask you this. In your favorite windowing OS, don't you have
> many programs each of them writing to a screen? Don't they all write
> to the same screen? You don't have a separate monitor for each
> program, do you?
>
Of course not; all programs share the same monitor. (Or would share two
if I had a double-headed setup.)
Which is why I'm surprised to see you say "no" when I asked if all of my
classes in all of my projects should write to the same log. Your analogy
suggests that the loggers should all write to the same log. But I know
you wouldn't deliberately be that self-contradictory. So there's a subtle
distinction you're making that I'm not quite seeing....
>> Lots of loggers but only one log.... Yes, I need to get my head
>> around that and think of how that works. Maybe rereading that logging
>> overview will make that sink in....
>
> Or thinking about many arrows hitting one target.
>
That works too.
> ...
>> The only thing that REALLY bugs me still is that I can't find the
>> darned log records containing the weekdays that I mentioned elsewhere
>> in the thread. They're NOT at %h/java%u.log nor at the other place
>> suggested in the Tracing and Logging document. And THAT is really
>> driving me crazy. I can't think of anywhere else to look based on
>> anything I've seen in the references you and others have given me. I
>> _think_ the logging.properties file is ensuring that a physical log
>> file is being written but maybe it's messed up in some way to keep it
>> from writing at all. Or from righting INFO level records. But I don't
>> think that's it.
>>
>> If you have any insight into that, you'd really be helping me out.
>> It's hard to absorb the information you are giving me when my mind
>> keeps obsessing on where the darned log files are.
>
> When I can't find a log file I'm searching for (it follows the rules
> for finding resources via a classloader, btw), I do a variant of
>
> $ find / -name foo.log 2> /dev/null
>
> Have you not tried searching your hard drive?
>
I certainly have. But it didn't turn up the missing log. I posted at
another place to get some more people involved and the person who replied
suggested I execute:
System.out.println(getClass().getClassLoader().getResource
("logging.properties"));
in my sandbox class. And that revealed something that surprised me: the
println() wrote "null". Clearly, and much to my surprise, my class isn't
seeing logging.properties and therefore isn't following its instructions.
That explains a lot!
My best guess is that it is seeing a different logging.properties file
than the one I want it to use but maybe it simply isn't seeing any
logging.properties at all and just defaulting in its behavior.
Now I need to figure out how to make it see the logging.properties file.
I need to do some googling to figure that out now. Or maybe ask in the
Eclipse forums if googling doesn't reveal the answer. Of course, if you
already know the answer, I wouldn't be adverse to hearing it ;-)
But I'm sure you've got your own work to do and I've already been a major
pain so I don't want to ask too much....
--
Novice
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-27 12:28 -0800 |
| Message-ID | <jigp0l$ejo$1@news.albasani.net> |
| In reply to | #12440 |
On 02/27/2012 10:37 AM, Novice wrote: > Lew<noone@lewscanon.com> wrote in news:jif5gv$ih$1@news.albasani.net: > >> Novice wrote: >>> Assuming that project Foo has a single package, com.novice.foo and >>> three classes, hickory, dickory, and dock, class hickory's logger >>> would be "com.novice.foo.hickory", class dickory's logger would be >>> "com.novice.foo.dickory" and class dock's logger would be >>> "com.novice.foo.dock". >>> >>> Is that right now? >> >> Yes. >> >> Only do follow the naming conventions: >> >> com.novice.foo.Hickory >> com.novice.foo.Dickory >> com.novice.foo.Dock >> >> ... >>> ... Each class is going to be getting it's own logger with >>> >>> Logger logger Logger.getLogger(getClass().getName()); >>> >> ... >>> Yes, every class is already in one or another named package and has >>> been for a long time. I'm still struggling a bit over which classes >>> belong in the SAME package and which should not. >> >> As Patricia said, just make a decision and refactor later if you >> decide to. >> >>> My thinking is that classes in the Common PROJECT should also be in >>> packages that are distinct from the packages used for Projects Foo or >>> Bar, which will have names like "com.novice.foo" and >>> "com.novice.bar". >> >> Usually. You have to think of the consequences and decide if they're >> the consequences you intend. >> >>> I'm using separate packages now so that >>> similar things are together. (That just feels like the right thing to >>> do but so far, most of my "feelings" have been wrong!) >> >> It's the right thing to do. Now find a rationale why - there is one, >> since it is the right thing to do. That way if pressed to explain your >> feeling you can. >> >>> Right. That is gradually sinking in, believe it or not! In fact, I'm >>> just about ready to replace all of the existing nonsense that I've >>> been doing with a >>> >>> Logger logger = Logger.getLogger(getClass().getName()); >>> >>> in all my classes. >> >> That's pretty much the idea I'm promoting, save for concerns of >> appropriate scope as discussed upthread. >> >>> So I want to end up with all of my classes in all of my Projects >>> writing to a single log? >> >> No. >> >>> Hmm. Yes, I suppose that makes sense. I need to review the whole >>> "inherit" aspect of logging but I've been thinking of one logger >>> equating to one log and that's not right, is it? See, the penny is >>> dropping.... >> >> A logger is an object that writes to a log. There's no essential >> reason the ratio should be one to one. Au contraire, just like >> everything else in Java it's reasonable to expect multiple pointers to >> point to one thing and multiple writers to write to one output. >> >> Let me ask you this. In your favorite windowing OS, don't you have >> many programs each of them writing to a screen? Don't they all write >> to the same screen? You don't have a separate monitor for each >> program, do you? >> > Of course not; all programs share the same monitor. (Or would share two > if I had a double-headed setup.) > > Which is why I'm surprised to see you say "no" when I asked if all of my > classes in all of my projects should write to the same log. Your analogy All of your projects writing to the same log is like everyone's computer sharing one screen. Is there only one computer screen in the world that we all share for our projects? > suggests that the loggers should all write to the same log. But I know > you wouldn't deliberately be that self-contradictory. So there's a subtle > distinction you're making that I'm not quite seeing.... It's not subtle, that is, unless you consider a piano falling on your head subtle. >>> Lots of loggers but only one log.... Yes, I need to get my head >>> around that and think of how that works. Maybe rereading that logging >>> overview will make that sink in.... >> >> Or thinking about many arrows hitting one target. >> > That works too. Are there not many targets at the archery range? >> ... > in my sandbox class. And that revealed something that surprised me: the > println() wrote "null". Clearly, and much to my surprise, my class isn't > seeing logging.properties and therefore isn't following its instructions. > That explains a lot! > > My best guess is that it is seeing a different logging.properties file > than the one I want it to use but maybe it simply isn't seeing any > logging.properties at all and just defaulting in its behavior. > > Now I need to figure out how to make it see the logging.properties file. Put it in the place in the classpath that matches the location specified in the 'getResource()', use a "-D" parameter to the "java" command as suggested upthread, study the Javadocs for 'getResource[AsStream]()'. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-28 00:55 +0000 |
| Message-ID | <XnsA006CACD7F358jpnasty@94.75.214.39> |
| In reply to | #12447 |
Lew <noone@lewscanon.com> wrote in news:jigp0l$ejo$1@news.albasani.net: > On 02/27/2012 10:37 AM, Novice wrote: >> Lew<noone@lewscanon.com> wrote in >> news:jif5gv$ih$1@news.albasani.net: >> >>> Novice wrote: >>>> Assuming that project Foo has a single package, com.novice.foo and >>>> three classes, hickory, dickory, and dock, class hickory's logger >>>> would be "com.novice.foo.hickory", class dickory's logger would be >>>> "com.novice.foo.dickory" and class dock's logger would be >>>> "com.novice.foo.dock". >>>> >>>> Is that right now? >>> >>> Yes. >>> >>> Only do follow the naming conventions: >>> >>> com.novice.foo.Hickory >>> com.novice.foo.Dickory >>> com.novice.foo.Dock >>> >>> ... >>>> ... Each class is going to be getting it's own logger with >>>> >>>> Logger logger Logger.getLogger(getClass().getName()); >>>> >>> ... >>>> Yes, every class is already in one or another named package and has >>>> been for a long time. I'm still struggling a bit over which classes >>>> belong in the SAME package and which should not. >>> >>> As Patricia said, just make a decision and refactor later if you >>> decide to. >>> >>>> My thinking is that classes in the Common PROJECT should also be in >>>> packages that are distinct from the packages used for Projects Foo >>>> or Bar, which will have names like "com.novice.foo" and >>>> "com.novice.bar". >>> >>> Usually. You have to think of the consequences and decide if they're >>> the consequences you intend. >>> >>>> I'm using separate packages now so that >>>> similar things are together. (That just feels like the right thing >>>> to do but so far, most of my "feelings" have been wrong!) >>> >>> It's the right thing to do. Now find a rationale why - there is one, >>> since it is the right thing to do. That way if pressed to explain >>> your feeling you can. >>> >>>> Right. That is gradually sinking in, believe it or not! In fact, >>>> I'm just about ready to replace all of the existing nonsense that >>>> I've been doing with a >>>> >>>> Logger logger = Logger.getLogger(getClass().getName()); >>>> >>>> in all my classes. >>> >>> That's pretty much the idea I'm promoting, save for concerns of >>> appropriate scope as discussed upthread. >>> >>>> So I want to end up with all of my classes in all of my Projects >>>> writing to a single log? >>> >>> No. >>> >>>> Hmm. Yes, I suppose that makes sense. I need to review the whole >>>> "inherit" aspect of logging but I've been thinking of one logger >>>> equating to one log and that's not right, is it? See, the penny is >>>> dropping.... >>> >>> A logger is an object that writes to a log. There's no essential >>> reason the ratio should be one to one. Au contraire, just like >>> everything else in Java it's reasonable to expect multiple pointers >>> to point to one thing and multiple writers to write to one output. >>> >>> Let me ask you this. In your favorite windowing OS, don't you have >>> many programs each of them writing to a screen? Don't they all write >>> to the same screen? You don't have a separate monitor for each >>> program, do you? >>> >> Of course not; all programs share the same monitor. (Or would share >> two if I had a double-headed setup.) >> >> Which is why I'm surprised to see you say "no" when I asked if all of >> my classes in all of my projects should write to the same log. Your >> analogy > > All of your projects writing to the same log is like everyone's > computer sharing one screen. > > Is there only one computer screen in the world that we all share for > our projects? > Of course not. >> suggests that the loggers should all write to the same log. But I >> know you wouldn't deliberately be that self-contradictory. So there's >> a subtle distinction you're making that I'm not quite seeing.... > > It's not subtle, that is, unless you consider a piano falling on your > head subtle. > That's not subtle at all in my book ;-) But then assuming we're agreed that all of _my_ classes should NOT write to the same log - let alone every class in the world! - what is the proper scope of a log. I could be persuaded that each application should write its own distinct log, although I'm not sure we'd have the same definition of application in mind. A better scope for logs would probably be all the applications that belong to system X, where X might be the company's payroll system, consisting of many applications and hundreds of classes. What is your view of what the scope should be? >>>> Lots of loggers but only one log.... Yes, I need to get my head >>>> around that and think of how that works. Maybe rereading that >>>> logging overview will make that sink in.... >>> >>> Or thinking about many arrows hitting one target. >>> >> That works too. > > Are there not many targets at the archery range? > I'm not an archer but I seem to remember seeing archery ranges on TV shows that had several targets.... >>> ... > >> in my sandbox class. And that revealed something that surprised me: >> the println() wrote "null". Clearly, and much to my surprise, my >> class isn't seeing logging.properties and therefore isn't following >> its instructions. That explains a lot! >> >> My best guess is that it is seeing a different logging.properties >> file than the one I want it to use but maybe it simply isn't seeing >> any logging.properties at all and just defaulting in its behavior. >> >> Now I need to figure out how to make it see the logging.properties >> file. > > Put it in the place in the classpath that matches the location > specified in the 'getResource()', use a "-D" parameter to the "java" > command as suggested upthread, I just spent half an hour looking for that post and I cannot find it. I skimmed each and every post in the thread and did not find it. I located a find command in my news reader, whose scope is limited to a single post at a time, and used it in every post in the thread. Still nothing. I went into Google groups and searched it there with the browser's find command and still nothing. I know it was there because I remember seeing it but I can't find it now. Can you possibly remind me what I was supposed to do? > study the Javadocs for > 'getResource[AsStream]()'. > Do I actually need to open the logging.properties file and read it, as if it were a routine text file, to find the desired log path? That seems improbable.... For what it's worth, someone else told me to add it to the classpath for the project so I went into Run Configurations, chose the Classpath tab and added the folder containing logging.properties under "User Entries". I also deleted my old java%u.log files because I'm sick of looking at them and finding that no new java.log has joined them and none of the old ones has changed. I ran the sandbox program again and the println() displayed the path to the logging.properties file. The INFO, SEVERE, and WARNING messages got displayed on the console, just as they did before I made the logging.properties visible. But there is STILL NO LOG FILE in the %h directory! This is really getting annoying. I really want to play with logging now that I have a better grasp on it and I can't find the bloody thing for love or money.... -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-27 17:37 -0800 |
| Message-ID | <jihb5e$4o6$1@news.albasani.net> |
| In reply to | #12458 |
Novice wrote: > But then assuming we're agreed that all of _my_ classes should NOT write to > the same log - let alone every class in the world! - what is the proper > scope of a log. I could be persuaded that each application should write its > own distinct log, although I'm not sure we'd have the same definition of > application in mind. A better scope for logs would probably be all the > applications that belong to system X, where X might be the company's > payroll system, consisting of many applications and hundreds of classes. > What is your view of what the scope should be? You do ask very good questions. Each program should have its own log. I don't know what you mean when you say "project", but conventionally a project is tied to one specific program or application. >>>>> Lots of loggers but only one log.... Yes, I need to get my head >>>>> around that and think of how that works. Maybe rereading that >>>>> logging overview will make that sink in.... >>>> >>>> Or thinking about many arrows hitting one target. >>>> >>> That works too. >> >> Are there not many targets at the archery range? >> > I'm not an archer but I seem to remember seeing archery ranges on TV shows > that had several targets.... And as there is a different target for each archer, there should be a different log for each program. Really, I've already given you the advice you need to answer your own question. I told you to design logs to benefit people who need them to troubleshoot. How will it help an operations engineer or reliability engineer to have to sift through dozens of applications' output to find what they need? It's bad enough to sift through one application's log, especially the way most programmers fail to think through their logging output. >> Put it in the place in the classpath that matches the location >> specified in the 'getResource()', use a "-D" parameter to the "java" >> command as suggested upthread, > > I just spent half an hour looking for that post and I cannot find it. I > skimmed each and every post in the thread and did not find it. I located a > find command in my news reader, whose scope is limited to a single post at > a time, and used it in every post in the thread. Still nothing. I went into > Google groups and searched it there with the browser's find command and > still nothing. I know it was there because I remember seeing it but I can't > find it now. Can you possibly remind me what I was supposed to do? I must have remembered this wrong. I coulda sworn someone suggested to use the "-D" option per <http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview.html> which in the section entitled "Configuration File" <http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview.html#a1.8> points you to "See the LogManager API Specification for details." <http://docs.oracle.com/javase/7/docs/api/java/util/logging/LogManager.html> where it tells you «In addition, the LogManager uses two optional system properties that allow more control over reading the initial configuration: "java.util.logging.config.class" "java.util.logging.config.file" These two properties may be set via the Preferences API, or as command line property definitions to the "java" command, or as system property definitions passed to JNI_CreateJavaVM.» I don't have these link chains memorized, dude. I'm literally reading the documentation on your behalf and reporting what I discover. There's only so far you can get as a programmer asking others to read the documentation for you. >> study the Javadocs for >> 'getResource[AsStream]()'. >> > > Do I actually need to open the logging.properties file and read it, as if > it were a routine text file, to find the desired log path? That seems > improbable.... I'm only suggesting you study those Javadocs to understand how the system searches for resources. > For what it's worth, someone else told me to add it to the classpath for > the project so I went into Run Configurations, chose the Classpath tab and > added the folder containing logging.properties under "User Entries". I also Umm - cargo cult. > deleted my old java%u.log files because I'm sick of looking at them and > finding that no new java.log has joined them and none of the old ones has > changed. I ran the sandbox program again and the println() displayed the > path to the logging.properties file. The INFO, SEVERE, and WARNING messages > got displayed on the console, just as they did before I made the > logging.properties visible. But there is STILL NO LOG FILE in the > %h directory! > > This is really getting annoying. I really want to play with logging now > that I have a better grasp on it and I can't find the bloody thing for love > or money.... Didn't someone already ask you to share your logging.properties file with us? Have you done so? Regardless, you are asking questions now that the documentation answers. I have read the documentation for you and reported what I found, to a degree. So will your next post be another request to read the documentation for you? -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-29 15:57 +0000 |
| Message-ID | <XnsA0086F97F5801jpnasty@94.75.214.39> |
| In reply to | #12461 |
Lew <noone@lewscanon.com> wrote in news:jihb5e$4o6$1@news.albasani.net: > Novice wrote: >> But then assuming we're agreed that all of _my_ classes should NOT >> write to the same log - let alone every class in the world! - what is >> the proper scope of a log. I could be persuaded that each application >> should write its own distinct log, although I'm not sure we'd have >> the same definition of application in mind. A better scope for logs >> would probably be all the applications that belong to system X, where >> X might be the company's payroll system, consisting of many >> applications and hundreds of classes. What is your view of what the >> scope should be? > > You do ask very good questions. > > Each program should have its own log. I don't know what you mean when > you say "project", but conventionally a project is tied to one > specific program or application. > >>>>>> Lots of loggers but only one log.... Yes, I need to get my head >>>>>> around that and think of how that works. Maybe rereading that >>>>>> logging overview will make that sink in.... >>>>> >>>>> Or thinking about many arrows hitting one target. >>>>> >>>> That works too. >>> >>> Are there not many targets at the archery range? >>> >> I'm not an archer but I seem to remember seeing archery ranges on TV >> shows that had several targets.... > > And as there is a different target for each archer, there should be a > different log for each program. > > Really, I've already given you the advice you need to answer your own > question. I told you to design logs to benefit people who need them to > troubleshoot. > > How will it help an operations engineer or reliability engineer to > have to sift through dozens of applications' output to find what they > need? It's bad enough to sift through one application's log, > especially the way most programmers fail to think through their > logging output. > I'm 100% in agreement with you. I would certainly lean toward fewer logs than more logs. I would embrace One Big Log long before I would choose to have a separate log for each class! >>> Put it in the place in the classpath that matches the location >>> specified in the 'getResource()', use a "-D" parameter to the "java" >>> command as suggested upthread, >> >> I just spent half an hour looking for that post and I cannot find it. >> I skimmed each and every post in the thread and did not find it. I >> located a find command in my news reader, whose scope is limited to a >> single post at a time, and used it in every post in the thread. Still >> nothing. I went into Google groups and searched it there with the >> browser's find command and still nothing. I know it was there because >> I remember seeing it but I can't find it now. Can you possibly remind >> me what I was supposed to do? > > I must have remembered this wrong. I coulda sworn someone suggested to > use the "-D" option per > <http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview > .html> which in the section entitled "Configuration File" > <http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview > .html#a1.8> points you to "See the LogManager API Specification for > details." > <http://docs.oracle.com/javase/7/docs/api/java/util/logging/LogManager. > html> where it tells you > As I said, I remember seeing something about a -D option too. But I tried REALLY hard to find it again and couldn't. I still don't know where that post went. So thanks for repeating the information. > «In addition, the LogManager uses two optional system properties that > allow more control over reading the initial configuration: > > "java.util.logging.config.class" > "java.util.logging.config.file" > These two properties may be set via the Preferences API, or as command > line property definitions to the "java" command, or as system property > definitions passed to JNI_CreateJavaVM.» > > I don't have these link chains memorized, dude. I'm literally reading > the documentation on your behalf and reporting what I discover. > > There's only so far you can get as a programmer asking others to read > the documentation for you. > Sorry, I do get a bit lazy on occasion. Just say no if you sense that happening. But I really couldn't find those links and I spent at least a half hour looking. >>> study the Javadocs for >>> 'getResource[AsStream]()'. >>> >> >> Do I actually need to open the logging.properties file and read it, >> as if it were a routine text file, to find the desired log path? That >> seems improbable.... > > I'm only suggesting you study those Javadocs to understand how the > system searches for resources. > >> For what it's worth, someone else told me to add it to the classpath >> for the project so I went into Run Configurations, chose the >> Classpath tab and added the folder containing logging.properties >> under "User Entries". I also > > Umm - cargo cult. > In retrospect, yes, you're right. If I had found those links again or tried a different google search, I might have found that pesky - Djava.util.logging.config.file parameter and realized it was the linchpin. But I was going crazy trying to find that darned log file so that I could actually TRY some of the things people have been suggesting. >> deleted my old java%u.log files because I'm sick of looking at them >> and finding that no new java.log has joined them and none of the old >> ones has changed. I ran the sandbox program again and the println() >> displayed the path to the logging.properties file. The INFO, SEVERE, >> and WARNING messages got displayed on the console, just as they did >> before I made the logging.properties visible. But there is STILL NO >> LOG FILE in the %h directory! >> >> This is really getting annoying. I really want to play with logging >> now that I have a better grasp on it and I can't find the bloody >> thing for love or money.... > > Didn't someone already ask you to share your logging.properties file > with us? Have you done so? > Yes, I did. But this thread is so unwieldy now that it's hard to find things again. I'm having to click on a great many of the posts in the thread just to find things. I'm in mid-conversation with several people at the same time but I can't find any way to bookmark individual posts in this newsreader.... > Regardless, you are asking questions now that the documentation > answers. I have read the documentation for you and reported what I > found, to a degree. > > So will your next post be another request to read the documentation > for you? > No, that will not be necessary. You didn't hear from me yesterday and that's because I had a great day yesterday. I finally put that -Djava.util.logging.config.file parameter in my VM arguments and pointed it to my logging.properties file. I can finally see the bleeping log that I'm writing!!! And that let me get a great deal of useful work done. I reworked my Foo and Common projects so that no loggers or locales are passed between classes. In each class that needs to do logging - and no others, I do a Logger logger = Logger.getLogger(getClass().getName()); In classes where only one or two methods do logging, logger is a local variable. In classes where lots of methods do logging, I make it an instance variable and instantiate it in the constructor. I've become very fond of logging.properties because I figured out how to assign my desired custom formatter there rather than having to do it programmatically. I was very surprised to find that I was getting log records from various java.awt.*, java.swing.*, and sun.* classes but I keep all but the WARNING and SEVERE ones out of the log via the appropriate lines in the logging.properties file. In short, I am a lot closer to doing logging the way it is supposed to be done rather than the messed-up way I was doing it before. I still need to work with it a bit to fine-tune my approach to what should be logged and what the exact level and content of each log record should be but that is going to be an ongoing thing. I even understand that advice in the article which Arved recommended where the author said not to put the class name in the log record. Now that I've got the actual class name as the Logger value in the record, I can see that I don't need it again elsewhere in the same log record. I know that some people do really well by just hearing principles and concepts; with that under their belts, they can do exactly what needs to be done with minimal hesitation. But I tend to need to see things actually working with my own two eyes for concepts and principles to gel properly. Before that, I'm not sure if I'm really envisioning things accurately. That's why I was getting so antsy about seeing that log. Now that I can see and try things and see real log records, things are starting to solidify for me. So thank you (everyone who contributed to this thread but especially Lew) VERY MUCH for your patience. I'll go try finishing up any dangling conversations within this thread now and then get on to my next issue ;-) -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Leif Roar Moldskred <leifm@dimnakorr.com> |
|---|---|
| Date | 2012-02-28 03:21 -0600 |
| Message-ID | <VKqdnaX1N7kKAdHSnZ2dnUVZ7sydnZ2d@giganews.com> |
| In reply to | #12447 |
Lew <noone@lewscanon.com> wrote: > All of your projects writing to the same log is like everyone's computer > sharing one screen. To be fair, both Unix and Windows have master logs that are shared by several different processes (syslog and windows event log) without that appearing to cause much in the way of headaches. -- Leif Roar Moldskred
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-28 09:19 -0800 |
| Message-ID | <jij2b5$ih0$1@news.albasani.net> |
| In reply to | #12481 |
Leif Roar Moldskred wrote: > Lew wrote: > >> All of your projects writing to the same log is like everyone's computer >> sharing one screen. > > To be fair, both Unix and Windows have master logs that are shared by > several different processes (syslog and windows event log) without > that appearing to cause much in the way of headaches. A syslog is conceptually for a single app, the OS. Also each app may have its own log besides the syslog. It's true, furthermore, that not every project or app on Windows or *nix writes to the syslog or event log. It's also true that Windows apps don't write to *nix syslogs as a rule, nor vice versa. As before, every "rule" I present may have exceptions. In the context of the OP's question, it was important to distinguish that in general different apps have different logs. At no point did I suggest the ratio had to be one to one. I also did not say that it did not have to be one to one. Your post is very useful for making that point. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-27 21:12 -0500 |
| Message-ID | <4f4c3828$0$292$14726298@news.sunsite.dk> |
| In reply to | #12440 |
On 2/27/2012 1:37 PM, Novice wrote: > Lew<noone@lewscanon.com> wrote in news:jif5gv$ih$1@news.albasani.net: >> Novice wrote: >>> Hmm. Yes, I suppose that makes sense. I need to review the whole >>> "inherit" aspect of logging but I've been thinking of one logger >>> equating to one log and that's not right, is it? See, the penny is >>> dropping.... >> >> A logger is an object that writes to a log. There's no essential >> reason the ratio should be one to one. Au contraire, just like >> everything else in Java it's reasonable to expect multiple pointers to >> point to one thing and multiple writers to write to one output. >> >> Let me ask you this. In your favorite windowing OS, don't you have >> many programs each of them writing to a screen? Don't they all write >> to the same screen? You don't have a separate monitor for each >> program, do you? >> > Of course not; all programs share the same monitor. (Or would share two > if I had a double-headed setup.) > > Which is why I'm surprised to see you say "no" when I asked if all of my > classes in all of my projects should write to the same log. Your analogy > suggests that the loggers should all write to the same log. But I know > you wouldn't deliberately be that self-contradictory. So there's a subtle > distinction you're making that I'm not quite seeing.... Typical: - one logger instance per class - one log file per app Note that configuration of log files and other destinations for logging should not be in the code but in the log config file. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Date | 2012-02-28 05:59 -0400 |
| Message-ID | <oA13r.12334$I%6.743@newsfe16.iad> |
| In reply to | #12471 |
On 12-02-27 10:12 PM, Arne Vajhøj wrote: > On 2/27/2012 1:37 PM, Novice wrote: >> Lew<noone@lewscanon.com> wrote in news:jif5gv$ih$1@news.albasani.net: >>> Novice wrote: >>>> Hmm. Yes, I suppose that makes sense. I need to review the whole >>>> "inherit" aspect of logging but I've been thinking of one logger >>>> equating to one log and that's not right, is it? See, the penny is >>>> dropping.... >>> >>> A logger is an object that writes to a log. There's no essential >>> reason the ratio should be one to one. Au contraire, just like >>> everything else in Java it's reasonable to expect multiple pointers to >>> point to one thing and multiple writers to write to one output. >>> >>> Let me ask you this. In your favorite windowing OS, don't you have >>> many programs each of them writing to a screen? Don't they all write >>> to the same screen? You don't have a separate monitor for each >>> program, do you? >>> >> Of course not; all programs share the same monitor. (Or would share two >> if I had a double-headed setup.) >> >> Which is why I'm surprised to see you say "no" when I asked if all of my >> classes in all of my projects should write to the same log. Your analogy >> suggests that the loggers should all write to the same log. But I know >> you wouldn't deliberately be that self-contradictory. So there's a subtle >> distinction you're making that I'm not quite seeing.... > > Typical: > - one logger instance per class > - one log file per app > > Note that configuration of log files and other destinations for > logging should not be in the code but in the log config file. > > Arne Also typical: _several_ log files per app. The subsystems that comprise an application may have such different audiences, log levels, log volume, and log file treatment (rollover policies, compression etc), among other things, that it simply makes sense to configure logging for multiple output files. sed/grep/Splunk filtering and so forth only goes so far; it's sensible to use the logging framework itself to do some of the heavy lifting too. Some cautions with respect to that: it's easier to filter than it is to combine. And logs are most effective when all of the entries, at all levels, that pertain to something are in the same place (file, console, whatever) in chronological order. So if log output does get split the different sets of entries should be quite independent. AHS -- -- Gaiety is the most outstanding feature of the Soviet Union. Josef Stalin, November 1935
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-28 17:27 -0500 |
| Message-ID | <4f4d54d8$0$294$14726298@news.sunsite.dk> |
| In reply to | #12483 |
On 2/28/2012 4:59 AM, Arved Sandstrom wrote: > On 12-02-27 10:12 PM, Arne Vajhøj wrote: >> On 2/27/2012 1:37 PM, Novice wrote: >>> Lew<noone@lewscanon.com> wrote in news:jif5gv$ih$1@news.albasani.net: >>>> Novice wrote: >>>>> Hmm. Yes, I suppose that makes sense. I need to review the whole >>>>> "inherit" aspect of logging but I've been thinking of one logger >>>>> equating to one log and that's not right, is it? See, the penny is >>>>> dropping.... >>>> >>>> A logger is an object that writes to a log. There's no essential >>>> reason the ratio should be one to one. Au contraire, just like >>>> everything else in Java it's reasonable to expect multiple pointers to >>>> point to one thing and multiple writers to write to one output. >>>> >>>> Let me ask you this. In your favorite windowing OS, don't you have >>>> many programs each of them writing to a screen? Don't they all write >>>> to the same screen? You don't have a separate monitor for each >>>> program, do you? >>>> >>> Of course not; all programs share the same monitor. (Or would share two >>> if I had a double-headed setup.) >>> >>> Which is why I'm surprised to see you say "no" when I asked if all of my >>> classes in all of my projects should write to the same log. Your analogy >>> suggests that the loggers should all write to the same log. But I know >>> you wouldn't deliberately be that self-contradictory. So there's a subtle >>> distinction you're making that I'm not quite seeing.... >> >> Typical: >> - one logger instance per class >> - one log file per app >> >> Note that configuration of log files and other destinations for >> logging should not be in the code but in the log config file. > > Also typical: _several_ log files per app. The subsystems that comprise > an application may have such different audiences, log levels, log > volume, and log file treatment (rollover policies, compression etc), > among other things, that it simply makes sense to configure logging for > multiple output files. sed/grep/Splunk filtering and so forth only goes > so far; it's sensible to use the logging framework itself to do some of > the heavy lifting too. I have not seen different log files for different audiences much. I have seen log file for everything and some other destination for the higher levels rather frequently. Arne
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-29 16:07 +0000 |
| Message-ID | <XnsA00871387A69Fjpnasty@94.75.214.39> |
| In reply to | #12471 |
Arne Vajhøj <arne@vajhoej.dk> wrote in news:4f4c3828$0$292$14726298@news.sunsite.dk: > On 2/27/2012 1:37 PM, Novice wrote: >> Lew<noone@lewscanon.com> wrote in >> news:jif5gv$ih$1@news.albasani.net: >>> Novice wrote: >>>> Hmm. Yes, I suppose that makes sense. I need to review the whole >>>> "inherit" aspect of logging but I've been thinking of one logger >>>> equating to one log and that's not right, is it? See, the penny is >>>> dropping.... >>> >>> A logger is an object that writes to a log. There's no essential >>> reason the ratio should be one to one. Au contraire, just like >>> everything else in Java it's reasonable to expect multiple pointers >>> to point to one thing and multiple writers to write to one output. >>> >>> Let me ask you this. In your favorite windowing OS, don't you have >>> many programs each of them writing to a screen? Don't they all write >>> to the same screen? You don't have a separate monitor for each >>> program, do you? >>> >> Of course not; all programs share the same monitor. (Or would share >> two if I had a double-headed setup.) >> >> Which is why I'm surprised to see you say "no" when I asked if all of >> my classes in all of my projects should write to the same log. Your >> analogy suggests that the loggers should all write to the same log. >> But I know you wouldn't deliberately be that self-contradictory. So >> there's a subtle distinction you're making that I'm not quite >> seeing.... > > Typical: > - one logger instance per class > - one log file per app > That's exactly the kind of generalization I was looking for elsewhere in the thread. > Note that configuration of log files and other destinations for > logging should not be in the code but in the log config file. > Now that I've found my own log files and worked with them a bit, this all makes sense. The log config file is becoming my new best friend. Your comment is very helpful here because I was still inclined to assume that I should have a single logging.properties file for my entire system. But it follows from what you've said that I should have a different logging.properties for each app. Therefore, my Foo project, which is essentially a single app - it's a tiny menu with the choice of two programs, a main one and a supporting one - is going to have its own logging.properties. Projects Bar and Baz are each going to have their own distinct logging.properties as well. Each logging.properties file will independently manage the level of logging of the classes/packages used by the code invoked by that project. This logging stuff is FINALLY coming together for me. Thanks a lot to everyone for their help with this! -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-03-02 17:26 -0500 |
| Message-ID | <4f514935$0$282$14726298@news.sunsite.dk> |
| In reply to | #12533 |
On 2/29/2012 11:07 AM, Novice wrote: > Arne Vajhøj<arne@vajhoej.dk> wrote in > news:4f4c3828$0$292$14726298@news.sunsite.dk: > >> On 2/27/2012 1:37 PM, Novice wrote: >>> Lew<noone@lewscanon.com> wrote in >>> news:jif5gv$ih$1@news.albasani.net: >>>> Novice wrote: >>>>> Hmm. Yes, I suppose that makes sense. I need to review the whole >>>>> "inherit" aspect of logging but I've been thinking of one logger >>>>> equating to one log and that's not right, is it? See, the penny is >>>>> dropping.... >>>> >>>> A logger is an object that writes to a log. There's no essential >>>> reason the ratio should be one to one. Au contraire, just like >>>> everything else in Java it's reasonable to expect multiple pointers >>>> to point to one thing and multiple writers to write to one output. >>>> >>>> Let me ask you this. In your favorite windowing OS, don't you have >>>> many programs each of them writing to a screen? Don't they all write >>>> to the same screen? You don't have a separate monitor for each >>>> program, do you? >>>> >>> Of course not; all programs share the same monitor. (Or would share >>> two if I had a double-headed setup.) >>> >>> Which is why I'm surprised to see you say "no" when I asked if all of >>> my classes in all of my projects should write to the same log. Your >>> analogy suggests that the loggers should all write to the same log. >>> But I know you wouldn't deliberately be that self-contradictory. So >>> there's a subtle distinction you're making that I'm not quite >>> seeing.... >> >> Typical: >> - one logger instance per class >> - one log file per app >> > That's exactly the kind of generalization I was looking for elsewhere in > the thread. Note that typical varies - it has been pointed out that in some cases multiple log files per app can make sense. But starting with one should work for some time. >> Note that configuration of log files and other destinations for >> logging should not be in the code but in the log config file. >> > > Now that I've found my own log files and worked with them a bit, this all > makes sense. The log config file is becoming my new best friend. Your > comment is very helpful here because I was still inclined to assume that > I should have a single logging.properties file for my entire system. But > it follows from what you've said that I should have a different > logging.properties for each app. Correct. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-25 18:22 -0500 |
| Message-ID | <4f496d47$0$289$14726298@news.sunsite.dk> |
| In reply to | #12332 |
On 2/25/2012 5:12 PM, Novice wrote:
> Lew<noone@lewscanon.com> wrote in news:jibf3u$ee9$1@news.albasani.net:
>
>> Novice wrote:
>>> Lew wrote:
>>>> Logging is a great use case for aspects. However, there are
>>>> alternatives to lessening logging's overhead, too. You have to weigh
>>>> costs and benefits.
>>>>
>>> What are other good ways to do logging?
>>
>> log4j is my favorite.
>>
>>> Right now, the two main programs in my current project each create
>>> their own logger and then pass it to the classes they call in their
>>> parameters.
>>
>> I don't think that's a good pattern. Which logging library are you
>> using?
>>
> I'm using Java Logging. Does that answer your question or are you asking
> something else?
>
>> I have each class create its own logger (log4j style shown:
>>
>> package eegee;
>> import org.apache.log4j.Logger;
>> import static org.apache.log4j.Logger.getLogger;
>> public class Foo
>> {
>> final Logger logger = getLogger(getClass());
>>
>> public void foo()
>> {
>> logger.debug("");
>> // do the fooey stuff
>> try
>> {
>> // do the trying stuff
>> }
>> catch (FooException exc)
>> {
>> String msg = "trying stuff failed. "+
>> exc.getLocalizedMessage(); logger.error(msg, exc);
>> throw new IllegalStateException(msg, exc);
>> }
>> }
>> }
>>
>> This boilerplate is what aspects aim to remove from the code and I
>> espouse retaining.
>>
> My code is not terribly different than that.
>
> Here's the actual code minus the Javadoc comment:
>
> ================================================================
> public static Logger configureLogger(String className, String
> logFilePath, String logFileName, Locale locale, Formatter formatter,
> Level loggingLevel) {
>
> String METHOD_NAME = "configureLogger()"; //$NON-NLS-1$
>
> /* Ensure that the mandatory parameters have all been specified. */
> if (className == null) {
> throw new IllegalArgumentException("The name of the class must
> be provided."); //$NON-NLS-1$
> }
>
> if (logFilePath == null) {
> throw new IllegalArgumentException("The log file path must be
> provided."); //$NON-NLS-1$
> }
>
> if (logFileName == null) {
> throw new IllegalArgumentException("The log file name must be
> provided."); //$NON-NLS-1$
> }
>
> if (locale == null) {
> throw new IllegalArgumentException("The locale must be
> provided."); //$NON-NLS-1$
> }
>
>
> /* Create the logger. */
> Logger logger = Logger.getLogger(className);
>
> /* Create path identified by logFilePath if it does not exist. */
> File path = new File(logFilePath);
> if (!path.exists()) {
> path.mkdir();
> }
>
> /* If the invoking class has specified a logging level, use it.
> Otherwise, set a default level. */
> if (loggingLevel != null) {
> logger.setLevel(loggingLevel);
> }
> else {
> logger.setLevel(Level.INFO);
> }
>
> /* Create a file handler for the logger. The log file name does NOT
> need to exist prior to the execution of this method. */
> String logFile = logFilePath + File.separator + logFileName;
> Handler logFileHandler = null;
> try {
> logFileHandler = new FileHandler(logFile);
> }
> catch (IOException io_excp) {
> String msg = CLASS_NAME + "." + METHOD_NAME + " - Couldn't
> create FileHandler using file " + logFile + ".\n Details: " + io_excp +
> ". The stackTrace from this event has been written to the console."; //
> $NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$ //$NON-NLS-4$
> io_excp.printStackTrace();
> JOptionPane.showMessageDialog(null, msg, CLASS_NAME,
> JOptionPane.ERROR_MESSAGE);
> return logger;
> }
>
> logger.addHandler(logFileHandler);
>
> /* If the invoking class has specified a formatter, use it.
> Otherwise, don't add a formatter. */
> if (formatter != null) {
> Handler[] handlers = logger.getHandlers();
> for (Handler oneHandler : handlers) {
> if (oneHandler.getClass().getName().equals
> ("java.util.logging.FileHandler")) { //$NON-NLS-1$
> oneHandler.setFormatter(formatter);
> }
> }
> }
>
>
> return logger;
> }
> ================================================================
>
> I put that in a utility class in my Common project. Then any program that
> wants a logger just executes this one method passing the appropriate
> parameters.
????
That looks as if you are almost building your own logging framework
on top of a logging framework.
That does not make much sense to me.
Arne
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2012-02-25 20:22 -0800 |
| Message-ID | <jicc1d$er6$1@dont-email.me> |
| In reply to | #12339 |
On 2/25/2012 3:22 PM, Arne Vajhøj wrote:
> That looks as if you are almost building your own logging framework
> on top of a logging framework.
>
> That does not make much sense to me.
I can think of a use case for it though. Let's say you haven't decided
which logging framework to use, or you want to be flexible as to which
one to use. (Different customers of yours prefer different loggers.)
(Not syntax checked or tested.)
abstract class MyLogger {
public static MyLogger getLogger( String name ) {
MyLogger logger = Class.forName(
System.getProperty("me.mystuff.MyLogger.logImpl",
"me.mystuff.MyDefaultLogger" ).newInstance());
return logger;
}
public abstract void logStuff(Object...);
}
So the idea is that you wrap the logging framework in your own, and then
you're free to provide an implementation that matches whatever logging
framework you choose to use in the future. Maybe this is not for
everyone, but I could see its advantages. Some folks might like
java.util.Logger, some folks like log4j. And some might like things
that I don't know about yet.
A couple of other things.
Lew wrote:
public class Foo
{
final Logger logger = getLogger(getClass());
[...]
}
This requires that a logger is instantiated for each object as it is
created. Potentially this is a lot of work, and each logger may not be
used. (Even declaring the logger to be static still requires a logger
per class loaded.)
Whereas this:
...
try {
... some stuff...
} catch (Exception ex) {
getLogger(getClass()).log( ... );
}
creates the logger lazily and therefore doesn't spend any resources if
logging happens to be never required.
Lastly, I don't know about log4j, but I don't think the
java.util.logging package uses threads when logging. Any IO operations
the logger makes will block the calling thread. I've heard this is
undesirable in most cases. So rolling your own framework also gives you
control over threading issues too, which again might be important for
some customers.
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-25 22:20 -0800 |
| Message-ID | <jiciuf$458$1@news.albasani.net> |
| In reply to | #12351 |
markspace wrote:
> Arne Vajhøj wrote:
>
>> That looks as if you are almost building your own logging framework
>> on top of a logging framework.
>>
>> That does not make much sense to me.
>
>
> I can think of a use case for it though. Let's say you haven't decided which
> logging framework to use, or you want to be flexible as to which one to use.
> (Different customers of yours prefer different loggers.)
That's what Apache Commons logging is for.
> (Not syntax checked or tested.)
>
> abstract class MyLogger {
>
> public static MyLogger getLogger( String name ) {
> MyLogger logger = Class.forName(
> System.getProperty("me.mystuff.MyLogger.logImpl",
> "me.mystuff.MyDefaultLogger" ).newInstance());
> return logger;
> }
>
> public abstract void logStuff(Object...);
> }
It's actually common for libraries to use either ju.logging or log4j without
regard for your preference, with the result that both frameworks wind up in
the same program.
> So the idea is that you wrap the logging framework in your own, and then
> you're free to provide an implementation that matches whatever logging
> framework you choose to use in the future. Maybe this is not for everyone, but
> I could see its advantages. Some folks might like java.util.Logger, some folks
> like log4j. And some might like things that I don't know about yet.
I think in Java those two pretty much have it sewn up.
In any event, there's already
> A couple of other things.
>
> Lew wrote:
>
> public class Foo
> {
> final Logger logger = getLogger(getClass());
> [...]
> }
>
> This requires that a logger is instantiated for each object as it is created.
No, it doesn't.
It only creates one per class.
> Potentially this is a lot of work, and each logger may not be used. (Even
> declaring the logger to be static still requires a logger per class loaded.)
That's not important overhead at all. It's a feature, not a bug.
The logger being tied to the class (or its name) gives you class-level control
over the logger behavior at deployment time by adjustment of the logging
properties (or XML) configuration file. This is desirable.
The logging object size pays for itself in spades with its functionality.
> Whereas this:
>
> ...
> try {
> ... some stuff...
> } catch (Exception ex) {
> getLogger(getClass()).log( ... );
> }
>
> creates the logger lazily and therefore doesn't spend any resources if logging
> happens to be never required.
Lazy initialization is waaay overrated.
First prove you have an optimization problem before you present an
optimization solution.
> Lastly, I don't know about log4j, but I don't think the java.util.logging
> package uses threads when logging. Any IO operations the logger makes will
> block the calling thread. I've heard this is undesirable in most cases. So
Loggers are designed to be very fast unless used. So calls below the logging
threshold add very, very little overhead.
Calls above the threshold are usually warning or error logging, so the
overhead there is masked by the exception mechanism and the fact that things
are crashing.
First prove you have an optimization problem before you present an
optimization solution.
> rolling your own framework also gives you control over threading issues too,
> which again might be important for some customers.
Unlikely, but remotely possible.
That doesn't apply to the OP's situation, of course.
But your analysis ignores the care that goes into those two logging frameworks
to minimize the overhead of logging calls, and the substantial functionality
that you either sacrifice or spend a fortune recreating in a roll-your-own. It
also ignores the difficulty of beating their performance. You'd be
hard-pressed to exceed the efficiency of these frameworks.
Think long and hard before deciding to forego these two logging frameworks,
then stick with them anyway.
If you really, really, really, really, really, really need to spawn a thread
to make logging faster, which you don't, you can do that over a regular
ju.logging or log4j call. You don't have to throw out the baby with the bath
water.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2012-02-26 00:04 -0800 |
| Message-ID | <jicp1u$qos$1@dont-email.me> |
| In reply to | #12352 |
On 2/25/2012 10:20 PM, Lew wrote: > markspace wrote: >> (Different customers of yours prefer different loggers.) > That's what Apache Commons logging is for. Back when I was playing with applets, I discovered by default that the jul logger creates a log file in your home directory. (There's a default logging.properties file created with every Java desktop installation and that's what it does). With unsigned applets, this means even trying to instantiate any part of the jul logging system will throw an exception, because the applet has no permissions for creating files. There might be ways around that, but it spooked me and I decided that since I didn't have direct control over a user's system, I couldn't rely on any defaults in the JRE installation. So I made a shell logging system that wrapped the jul logger and allowed me control, in case I had to use something besides jul entirely. BTW, I wasn't aware that Apache Commons logging was different than JULI/log4j. Thanks for pointing that out. >> >> This requires that a logger is instantiated for each object as it is >> created. > No, it doesn't. > > It only creates one per class. OK, assuming loggers are cached and reused, fair point. > Lazy initialization is waaay overrated. > > First prove you have an optimization problem before you present an > optimization solution. Well, that "optimization" is code that my IDE writes by default. It costs me nothing, so I'd rather prove that it's a problem before messing with it. > If you really, really, really, really, really, really need to spawn a > thread to make logging faster, which you don't, you can do that over a > regular ju.logging or log4j call. You don't have to throw out the baby > with the bath water. I've never had to spawn threads for logging, and the idea was something I've only seen presented once, so I'm not sure how useful the concept is. However, I keep it in mind as something that might have to happen someday.
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-26 00:21 -0800 |
| Message-ID | <jicq2k$ifr$1@news.albasani.net> |
| In reply to | #12355 |
On 02/26/2012 12:04 AM, markspace wrote: > On 2/25/2012 10:20 PM, Lew wrote: > >> markspace wrote: >>> (Different customers of yours prefer different loggers.) > >> That's what Apache Commons logging is for. > > > Back when I was playing with applets, I discovered by default that the jul > logger creates a log file in your home directory. (There's a default > logging.properties file created with every Java desktop installation and > that's what it does). With unsigned applets, this means even trying to > instantiate any part of the jul logging system will throw an exception, > because the applet has no permissions for creating files. > > There might be ways around that, but it spooked me and I decided that since I > didn't have direct control over a user's system, I couldn't rely on any > defaults in the JRE installation. So I made a shell logging system that > wrapped the jul logger and allowed me control, in case I had to use something > besides jul entirely. > > BTW, I wasn't aware that Apache Commons logging was different than JULI/log4j. > Thanks for pointing that out. > > >>> >>> This requires that a logger is instantiated for each object as it is >>> created. > >> No, it doesn't. >> >> It only creates one per class. > > > OK, assuming loggers are cached and reused, fair point. It's not really a cache. The logger factory method is simply guaranteed to return the same instance of the same-identified logger, just as say 'Integer.valueOf(5)' is guaranteed to return the same 'Integer' instance each time within the program. <http://docs.oracle.com/javase/7/docs/api/java/util/logging/Logger.html#getLogger(java.lang.String)> "Find or create a logger for a named subsystem. If a logger has already been created with the given name it is returned. Otherwise a new logger is created." <http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Logger.html#getLogger(java.lang.String)> "Retrieve a logger named according to the value of the name parameter. If the named logger already exists, then the existing instance will be returned. Otherwise, a new instance is created." It's important to know what the system promises, and the Javadocs tell you. The logging frameworks are foundational and should be part of the early education of the Java programmer, along with the collections framework. Knowledge of things like that all same-named loggers point to the same logger instance is useful. >> Lazy initialization is waaay overrated. >> >> First prove you have an optimization problem before you present an >> optimization solution. > > > Well, that "optimization" is code that my IDE writes by default. It costs me > nothing, so I'd rather prove that it's a problem before messing with it. You mean the IDE generates lazy instantiation for you? It's a problem in that it is additional code that resists best-practice idioms without benefit. The fact that you have accepted someone else's default doesn't make it a great idea. Your lazy acceptance of a lazy initialization idiom is not good for the code, however much it may appear to you to save you the minute to change your IDE's default to a saner approach. I'm sensitive to habits, especially ones that lead to trouble. Maybe your classes by default aren't meant for concurrent programs, for example, but I never assume my classes won't be used that way. I also believe that if you practice safe idioms you don't accidentally forget to use one when you need it. Lazy instantiation has proven dangers and it causes things to be initialized in an unpredictable way and out of the normal class sequence for eagerly initialized items. Whether those dangers apply in this case or that case, it costs nothing to do things the safe way and not have to shift gears when you suspect danger. >> If you really, really, really, really, really, really need to spawn a >> thread to make logging faster, which you don't, you can do that over a >> regular ju.logging or log4j call. You don't have to throw out the baby >> with the bath water. > > > I've never had to spawn threads for logging, and the idea was something I've > only seen presented once, so I'm not sure how useful the concept is. However, > I keep it in mind as something that might have to happen someday. It was the idea you suggested, though. I was just responding with a way to follow your suggestion, with which I disagree BTW, that didn't involve having to reinvent the whole logging framework thing. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-26 00:33 -0800 |
| Message-ID | <jicqo6$ju7$1@news.albasani.net> |
| In reply to | #12356 |
Lew wrote:
> markspace wrote:
>> Lew wrote:
>>> Lazy initialization is waaay overrated.
>>>
>>> First prove you have an optimization problem before you present an
>>> optimization solution.
>>
>> Well, that "optimization" is code that my IDE writes by default. It costs me
>> nothing, so I'd rather prove that it's a problem before messing with it.
>
> You mean the IDE generates lazy instantiation for you? It's a problem in that
> it is additional code that resists best-practice idioms without benefit. The
> fact that you have accepted someone else's default doesn't make it a great idea.
>
> Your lazy acceptance of a lazy initialization idiom is not good for the code,
> however much it may appear to you to save you the minute to change your IDE's
> default to a saner approach.
>
> I'm sensitive to habits, especially ones that lead to trouble. Maybe your
> classes by default aren't meant for concurrent programs, for example, but I
> never assume my classes won't be used that way. I also believe that if you
> practice safe idioms you don't accidentally forget to use one when you need it.
>
> Lazy instantiation has proven dangers and it causes things to be initialized
> in an unpredictable way and out of the normal class sequence for eagerly
> initialized items. Whether those dangers apply in this case or that case, it
> costs nothing to do things the safe way and not have to shift gears when you
> suspect danger.
That said, the logging frameworks themselves do lazy instantiation.
Also, my comments here were meant to be very, very broad. Regular readers of
my posts know that I usually point out that programming rules are not
religions and there are times when they do or do not apply.
For loggers, I instantiate according to scope needed, pure and simple, without
regard for whether instantiation is lazy or eager. Since I use loggers
heavily, typically with 'logger.debug("");' at the head of every method, it
makes sense to have a 'private transient final Logger logger' class member
most of the time.
If I have a logger used only inside a particular block, it's instantiated
inside that block the way you showed.
This is in line with the best practice of minimizing variable scope.
I don't just accept the IDE authors' default blindly, though.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-26 10:43 -0500 |
| Message-ID | <4f4a5316$0$285$14726298@news.sunsite.dk> |
| In reply to | #12355 |
On 2/26/2012 3:04 AM, markspace wrote: > On 2/25/2012 10:20 PM, Lew wrote: >> markspace wrote: >>> (Different customers of yours prefer different loggers.) > >> That's what Apache Commons logging is for. > > Back when I was playing with applets, I discovered by default that the > jul logger creates a log file in your home directory. (There's a default > logging.properties file created with every Java desktop installation and > that's what it does). With unsigned applets, this means even trying to > instantiate any part of the jul logging system will throw an exception, > because the applet has no permissions for creating files. > > There might be ways around that, but it spooked me and I decided that > since I didn't have direct control over a user's system, I couldn't rely > on any defaults in the JRE installation. So I made a shell logging > system that wrapped the jul logger and allowed me control, in case I had > to use something besides jul entirely. I seem to recall that log4j is a bit more applet friendly than jul. Note that the applet should send log info back to the site it came from. Arne
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2012-02-26 11:18 +0000 |
| Message-ID | <jid4eu$v9t$1@localhost.localdomain> |
| In reply to | #12352 |
On Sat, 25 Feb 2012 22:20:03 -0800, Lew wrote: > The logger being tied to the class (or its name) gives you class-level > control over the logger behavior at deployment time by adjustment of the > logging properties (or XML) configuration file. This is desirable. > That's an interesting approach, though not one that I use. I tend to prefer a single logger per process with an associated level attribute, and to sprinkle classes with logger calls specifying different levels so I can vary the logged detail depending on what I need to see. The minimal level may correspond to nothing more than reporting overall run statistics. Next level will log method exits and show call arguments plus return value. The level above that shows method entry and beyond that anything that might be relevant in the method internals: both of these are omitted unless the method is complex enough to require them. > The logging object size pays for itself in spades with its > functionality. > Agreed. I recently added the ability to cache logger messages in a circular buffer to mine: if enabled, anything that's not an error is merely added to the buffer, which is dumped ahead of outputting an error message. This can be a big help if you need to diagnose a rarely occurring problem in a long-running process - it beats scanning through a multi-megabyte log hands down. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web