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 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-24 20:10 +0000 |
| Subject | Aspect questions? |
| Message-ID | <XnsA0039B9FFFA32jpnasty@94.75.214.39> |
Is this a reasonable place to ask questions about AspectJ? I'm just getting started with it and it's not going really well so far. I'm imitating simple examples from the manual and they just don't work. I'm not sure what I'm messing up.... I don't recall ever seeing anyone ask aspect-oriented questions but I certainly don't read every thread or even every subject line so I could have missed some.... -- Novice
[toc] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-24 13:05 -0800 |
| Message-ID | <ji8u23$f6m$1@news.albasani.net> |
| In reply to | #12296 |
Novice wrote: > Is this a reasonable place to ask questions about AspectJ? Isn't that one right there? Does it seem reasonable to you? > I'm just getting started with it and it's not going really well so far. I'm > imitating simple examples from the manual and they just don't work. I'm not > sure what I'm messing up.... > > I don't recall ever seeing anyone ask aspect-oriented questions but I > certainly don't read every thread or even every subject line so I could > have missed some.... Since this is a newsgroup devoted to the Java programmer and AspectJ is a Java programming tool, yes, of course this is the right forum. Aspect programming is an advanced, hairy and special-purpose discipline. Are you just learning it for the sake of learning it, or are you contemplating a project use for it? "Doctor, I have a problem," is a very limited request. We aren't sure what you're messing up either. There are some areas of Java programming that are almost never needed at the application level, but are quite useful for framework development. They include advance JavaBeans stuff like BeanInfo properties descriptors, reflection beyond 'instanceof' and 'Class.newInstance()', class loader magic and aspect programming. Given your handle in this group, you might want to learn other things in Java first before tacking aspect programming. What is your use case for aspect programming? -- 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-25 05:47 +0000 |
| Message-ID | <XnsA00493ECED98jpnasty@94.75.214.39> |
| In reply to | #12298 |
Lew <noone@lewscanon.com> wrote in news:ji8u23$f6m$1@news.albasani.net: > Novice wrote: >> Is this a reasonable place to ask questions about AspectJ? > > Isn't that one right there? > > Does it seem reasonable to you? > >> I'm just getting started with it and it's not going really well so >> far. I'm imitating simple examples from the manual and they just >> don't work. I'm not sure what I'm messing up.... >> >> I don't recall ever seeing anyone ask aspect-oriented questions but I >> certainly don't read every thread or even every subject line so I >> could have missed some.... > > Since this is a newsgroup devoted to the Java programmer and AspectJ > is a Java programming tool, yes, of course this is the right forum. > > Aspect programming is an advanced, hairy and special-purpose > discipline. Are you just learning it for the sake of learning it, or > are you contemplating a project use for it? > Hey, I'm just making sure this is an appropriate place to ask before I take the time to lay out my problem. This seems like a reasonable place to ask but the rest of the group may not agree.... > "Doctor, I have a problem," is a very limited request. We aren't sure > what you're messing up either. > Obviously. I haven't asked a specific question yet. I wanted to be sure there was no major objection before laying out the issue. > There are some areas of Java programming that are almost never needed > at the application level, but are quite useful for framework > development. They include advance JavaBeans stuff like BeanInfo > properties descriptors, reflection beyond 'instanceof' and > 'Class.newInstance()', class loader magic and aspect programming. > > Given your handle in this group, you might want to learn other things > in Java first before tacking aspect programming. > There are dozens of things I'd like to learn about Java and I probably need to learn several of them first. > What is your use case for aspect programming? > Based on other answers to my question, maybe I _don't_ want to learn AspectJ! I saw a seminar about aspects a couple of years back and thought it sounded quite intriguing. It struck me that aspects might be a very good way to handle what I am currently trying to do. But maybe there are better ways. So let me lay out what I'm trying to accomplish and maybe you can suggest a better approach. I'd like to make both localization and logging a part of every class that I write. The localization would allow each class to display text in any (supported) language that the user requests and I'm also thinking of localizing the messages in exceptions that get displayed or written to logs. It seems like logging is the standard way to go for writing and/or displaying messages to the user and to logs. Now, I could go and add very similar code to lots and lots of classes to accomplish those things but maybe writing aspects would enable me to write a few lines of code that apply to EVERY class I've written. One aspect could verify that a Locale had been passed to the class (assuming it is invoked from another class) or throw an exception if it hadn't. Another aspect could do something similar for the logger. This is still just half-baked in my head but maybe it's clear enough that you get the gist of it. I'd be interested in the advice of the group on this issue. By the way, I found another place to ask AspectJ questions and the issues I had when I first posted here are now resolved. But the bigger issue remains: are aspects a good approach for what I want to do? If not, what would be a better strategy? -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-24 23:40 -0800 |
| Message-ID | <jia398$bho$1@news.albasani.net> |
| In reply to | #12310 |
On 02/24/2012 09:47 PM, Novice wrote:
> Lew<noone@lewscanon.com> wrote in news:ji8u23$f6m$1@news.albasani.net:
>
>> Novice wrote:
>>> Is this a reasonable place to ask questions about AspectJ?
>>
>> Isn't that one right there?
>>
>> Does it seem reasonable to you?
>>
>>> I'm just getting started with it and it's not going really well so
>>> far. I'm imitating simple examples from the manual and they just
>>> don't work. I'm not sure what I'm messing up....
>>>
>>> I don't recall ever seeing anyone ask aspect-oriented questions but I
>>> certainly don't read every thread or even every subject line so I
>>> could have missed some....
>>
>> Since this is a newsgroup devoted to the Java programmer and AspectJ
>> is a Java programming tool, yes, of course this is the right forum.
>>
>> Aspect programming is an advanced, hairy and special-purpose
>> discipline. Are you just learning it for the sake of learning it, or
>> are you contemplating a project use for it?
>>
> Hey, I'm just making sure this is an appropriate place to ask before I
> take the time to lay out my problem. This seems like a reasonable place
> to ask but the rest of the group may not agree....
>
>
>> "Doctor, I have a problem," is a very limited request. We aren't sure
>> what you're messing up either.
>>
> Obviously. I haven't asked a specific question yet. I wanted to be sure
> there was no major objection before laying out the issue.
>
>> There are some areas of Java programming that are almost never needed
>> at the application level, but are quite useful for framework
>> development. They include advance JavaBeans stuff like BeanInfo
>> properties descriptors, reflection beyond 'instanceof' and
>> 'Class.newInstance()', class loader magic and aspect programming.
>>
>> Given your handle in this group, you might want to learn other things
>> in Java first before tacking aspect programming.
>>
> There are dozens of things I'd like to learn about Java and I probably
> need to learn several of them first.
>
>> What is your use case for aspect programming?
>>
> Based on other answers to my question, maybe I _don't_ want to learn
> AspectJ!
I wouldn't advise against learning it.
I do advise laying a good foundation. Certain advanced topics are
foundational, and you don't need to be linear and do nothing interesting.
For example, every Java programmer should understand serialization and have a
basic grasp of non-trivial reflection. More importantly, understand where the
various topics apply so you don't deploy them where they don't serve well.
> I saw a seminar about aspects a couple of years back and thought it
> sounded quite intriguing. It struck me that aspects might be a very good
They are and would be.
> way to handle what I am currently trying to do. But maybe there are
> better ways. So let me lay out what I'm trying to accomplish and maybe
> you can suggest a better approach.
Very wise and balanced approach, that.
> I'd like to make both localization and logging a part of every class that
> I write. The localization would allow each class to display text in any
> (supported) language that the user requests and I'm also thinking of
> localizing the messages in exceptions that get displayed or written to
> logs. It seems like logging is the standard way to go for writing and/or
> displaying messages to the user and to logs.
The widespread practice for l10n (because you omit ten characters from
"localization") are
<http://docs.oracle.com/javase/7/docs/api/java/util/ResourceBundle.html>
<http://docs.oracle.com/javase/7/docs/api/java/util/Properties.html>
> [snip]
> By the way, I found another place to ask AspectJ questions and the issues
> I had when I first posted here are now resolved. But the bigger issue
> remains: are aspects a good approach for what I want to do? If not, what
> would be a better strategy?
You ask great questions.
I18n ("i[nternationalizatio]n") and l10n are most likely best handled with
resource bundles and properties. There is a lot of lore around that approach,
and it's just as flexible as aspects.
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.
It's not just in the code you weigh. Frameworks have a deployment cost. It's
harder to deploy than to write code. Framework bloat is a major problem in the
real world. Aspects also reduce visibility into areas, sometimes a good thing
and others not.
Locale management is best done in plain sight, IMO. You still have single code
points that translate automagically, so that's OK.
Aspects are to hide things from the code. Great, if you don't mind hunting for
them when you need them. XML configuration files can suffer this problem, too.
Too much externalization is bad just like too little.
I use code templates to handle logging. My editor autoinserts logging stuff
into new source files. That's enough for my laziness. Besides, the logging
statements help document the code, done right.
So where /should/ you use aspects? Hmm.
Like I say, you ask great questions.
--
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-25 17:02 +0000 |
| Message-ID | <XnsA0047B96E59BFjpnasty@94.75.214.39> |
| In reply to | #12312 |
Lew <noone@lewscanon.com> wrote in news:jia398$bho$1@news.albasani.net:
> On 02/24/2012 09:47 PM, Novice wrote:
>> Lew<noone@lewscanon.com> wrote in
>> news:ji8u23$f6m$1@news.albasani.net:
>>
>>> Novice wrote:
>>>> Is this a reasonable place to ask questions about AspectJ?
>>>
>>> Isn't that one right there?
>>>
>>> Does it seem reasonable to you?
>>>
>>>> I'm just getting started with it and it's not going really well so
>>>> far. I'm imitating simple examples from the manual and they just
>>>> don't work. I'm not sure what I'm messing up....
>>>>
>>>> I don't recall ever seeing anyone ask aspect-oriented questions but
>>>> I certainly don't read every thread or even every subject line so I
>>>> could have missed some....
>>>
>>> Since this is a newsgroup devoted to the Java programmer and AspectJ
>>> is a Java programming tool, yes, of course this is the right forum.
>>>
>>> Aspect programming is an advanced, hairy and special-purpose
>>> discipline. Are you just learning it for the sake of learning it, or
>>> are you contemplating a project use for it?
>>>
>> Hey, I'm just making sure this is an appropriate place to ask before
>> I take the time to lay out my problem. This seems like a reasonable
>> place to ask but the rest of the group may not agree....
>>
>>
>>> "Doctor, I have a problem," is a very limited request. We aren't
>>> sure what you're messing up either.
>>>
>> Obviously. I haven't asked a specific question yet. I wanted to be
>> sure there was no major objection before laying out the issue.
>>
>>> There are some areas of Java programming that are almost never
>>> needed at the application level, but are quite useful for framework
>>> development. They include advance JavaBeans stuff like BeanInfo
>>> properties descriptors, reflection beyond 'instanceof' and
>>> 'Class.newInstance()', class loader magic and aspect programming.
>>>
>>> Given your handle in this group, you might want to learn other
>>> things in Java first before tacking aspect programming.
>>>
>> There are dozens of things I'd like to learn about Java and I
>> probably need to learn several of them first.
>>
>>> What is your use case for aspect programming?
>>>
>> Based on other answers to my question, maybe I _don't_ want to learn
>> AspectJ!
>
> I wouldn't advise against learning it.
>
> I do advise laying a good foundation. Certain advanced topics are
> foundational, and you don't need to be linear and do nothing
> interesting.
>
> For example, every Java programmer should understand serialization and
> have a basic grasp of non-trivial reflection. More importantly,
> understand where the various topics apply so you don't deploy them
> where they don't serve well.
>
One of these days, I'm going to have to get a comprehensive list of the
things I should know and then take a systematic approach to learning all
of them. But I don't think that's going to be today. Right now, I want to
focus on my logging and l10n....
>> I saw a seminar about aspects a couple of years back and thought it
>> sounded quite intriguing. It struck me that aspects might be a very
>> good
>
> They are and would be.
>
>> way to handle what I am currently trying to do. But maybe there are
>> better ways. So let me lay out what I'm trying to accomplish and
>> maybe you can suggest a better approach.
>
> Very wise and balanced approach, that.
>
Thank you.
>> I'd like to make both localization and logging a part of every class
>> that I write. The localization would allow each class to display text
>> in any (supported) language that the user requests and I'm also
>> thinking of localizing the messages in exceptions that get displayed
>> or written to logs. It seems like logging is the standard way to go
>> for writing and/or displaying messages to the user and to logs.
>
> The widespread practice for l10n (because you omit ten characters from
> "localization") are
>
> <http://docs.oracle.com/javase/7/docs/api/java/util/ResourceBundle.html
> > <http://docs.oracle.com/javase/7/docs/api/java/util/Properties.html>
>
I've already got that covered. I've been writing and using resource
bundles for some time. I'm just not sure I'm using them the best possible
way.
>> [snip]
>> By the way, I found another place to ask AspectJ questions and the
>> issues I had when I first posted here are now resolved. But the
>> bigger issue remains: are aspects a good approach for what I want to
>> do? If not, what would be a better strategy?
>
> You ask great questions.
>
> I18n ("i[nternationalizatio]n") and l10n are most likely best handled
> with resource bundles and properties. There is a lot of lore around
> that approach, and it's just as flexible as aspects.
>
As mentioned above, I already take advantage of resource bundles in
several projects, including the one that concerns me today.
> 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?
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.
The called classes write their messages to that logger. I've created a
method that does the logger creation and put it in a utility class in my
Common project so that my programs only need to execute that method
(passing in a few parameters of course) and get an appropriate logger
back. Each of the classes instantiated by the main programs gets a logger
passed among their parameters. The newly instantiated class then verifies
that the logger is not null and throws an IllegalArgumentException if it
is. Each class writes to the log when it seems appropriate. Sometimes,
that is to log an Exception. Other times, I log things that are more
diagnostic in nature. If a method isn't 100% right yet, I will log
calculations that it is doing, such as calculating the width of a column
in a JTable or whatever.
This works okay but it seems to me that it might be more elegant to put
the logging in aspects, especially the diagnostic stuff that I am using
to verify that the suspect methods are doing their jobs correctly.
I'm not sure yet if all the logging code, including the creation of the
log itself, should go into aspects though. It probably makes more sense
to create the logger the way I am doing it and continue to do the actual
writes to the logs in my existing classes when it involves Exception
handling. The diagnostic logging, though, seems like a prime candidate
for the aspects. I could write pointcuts that specify the methods that
are a little dubious and log them in as much detail as I need. Methods
that are already working to my satisfaction could be left alone with only
their Exception logging.
But if there is a better way to do things, I'm all ears.
I'm a one-man shop and if there are other Java programmers in this area,
I haven't found them yet. That makes newsgroups and forums my primary way
of finding out how the pros do things.
> It's not just in the code you weigh. Frameworks have a deployment
> cost. It's harder to deploy than to write code. Framework bloat is a
> major problem in the real world. Aspects also reduce visibility into
> areas, sometimes a good thing and others not.
>
What do you mean when you say "framework"? That term puts me in mind of
things like Spring - which I know of but have never used - but I'm not
using any formal frameworks like that and know very little about them.
I'm getting the impression that you are thinking of my work as being sort
of a homegrown framework. Maybe it is; I really don't know.
> Locale management is best done in plain sight, IMO. You still have
> single code points that translate automagically, so that's OK.
>
My code basically uses Locale.getDefault() to get the Locale implied by
the user.country and user.language JVM parameters (which can of course be
overridden within my projects JVM settings). I write ResourceBundles for
English and two other languages using Google Translate to the
translations. Not professional grade translations by any means but
sufficient for my purposes.
> Aspects are to hide things from the code. Great, if you don't mind
> hunting for them when you need them. XML configuration files can
> suffer this problem, too. Too much externalization is bad just like
> too little.
>
It shouldn't be very hard to find the aspects provided I name them well
and put them in the same package as the code it is monitoring. Aspects
that monitor every class I have are a bit more challenging but I'd put
them in my Common project in an appropriate package, assuming that's
possible. I haven't gotten far enough into the manual to find out how to
do an aspect that covers a lot of projects and classes but I'm assuming
it's possible given what I've already seen.
> I use code templates to handle logging. My editor autoinserts logging
> stuff into new source files. That's enough for my laziness. Besides,
> the logging statements help document the code, done right.
>
So you use the code templates feature in Eclipse (or something equivalent
in a different IDE)?
I can't say I've done much with those. I mostly just copy and paste from
whatever project I most recently did that has the relevant code. And
every time I do that, I think seriously about making that code fragment a
method in a utility class. I even do it more often than not ;-)
> So where /should/ you use aspects? Hmm.
>
> Like I say, you ask great questions.
>
Thanks!
--
Novice
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-25 12:08 -0800 |
| Message-ID | <jibf3u$ee9$1@news.albasani.net> |
| In reply to | #12322 |
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 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.
Either way the logger should be tied to the actual class emitting log
messages, not some common class.
> The called classes write their messages to that logger. I've created a
> method that does the logger creation and put it in a utility class in my
> Common project so that my programs only need to execute that method
> (passing in a few parameters of course) and get an appropriate logger
> back. Each of the classes instantiated by the main programs gets a logger
> passed among their parameters. The newly instantiated class then verifies
> that the logger is not null and throws an IllegalArgumentException if it
> is. Each class writes to the log when it seems appropriate. Sometimes,
> that is to log an Exception. Other times, I log things that are more
> diagnostic in nature. If a method isn't 100% right yet, I will log
> calculations that it is doing, such as calculating the width of a column
> in a JTable or whatever.
Did you reinvent the logging wheel? If so, does your logging framework feature
log levels, infinitely flexible log formats, logging to screen or (rolling)
file logs, virtual elimination of logging overhead at levels finer than
configured, automatic if slow retrieval of class and method and line where the
logging happens, XML configuration, portability, a large body of online
literature describing its use, standardization, widespread adoption, and a
body of top developers contributing to the project?
> This works okay but it seems to me that it might be more elegant to put
> the logging in aspects, especially the diagnostic stuff that I am using
> to verify that the suspect methods are doing their jobs correctly.
What is "elegant"?
Personally I promote "useful" as the useful metric.
> I'm not sure yet if all the logging code, including the creation of the
> log itself, should go into aspects though. It probably makes more sense
> to create the logger the way I am doing it and continue to do the actual
Not from your description of it.
> writes to the logs in my existing classes when it involves Exception
> handling. The diagnostic logging, though, seems like a prime candidate
> for the aspects. I could write pointcuts that specify the methods that
> are a little dubious and log them in as much detail as I need. Methods
> that are already working to my satisfaction could be left alone with only
> their Exception logging.
Logging is logging is logging, to misquote Gertrude Stein. Suddenly now you've
created two logging aspects. That's not elegant.
Logging shouldn't be added to and removed from code. That's not the purpose of
logging. Logging is to remain in the code forever.
Logging is not for the developer. That's an all-too-common misconception.
Logging is for the sysop.
Have you ever tried to suss out a production issue from the logs?
The sort of dynamic granularity you describe is built in to the logging
framework. You use levels - DEBUG for debug purposes (or FINE if you're using
java.util.logging), WARNING for warnings, ERROR (SEVERE) for errors, and so
forth.
By removing logging to AspectJ, you eliminate the flexibility, visibility and
granularity of control logging should support.
>> It's not just in the code you weigh. Frameworks have a deployment
>> cost. It's harder to deploy than to write code. Framework bloat is a
>> major problem in the real world. Aspects also reduce visibility into
>> areas, sometimes a good thing and others not.
>>
> What do you mean when you say "framework"? That term puts me in mind of
> things like Spring - which I know of but have never used - but I'm not
> using any formal frameworks like that and know very little about them.
> I'm getting the impression that you are thinking of my work as being sort
> of a homegrown framework. Maybe it is; I really don't know.
A deployment or code base that handles some part of the project under the hood
for you, and gives you a public interface for control of its behavior. In your
case I'm referring to the AspectJ framework. Logging is also a framework, one
apparently you are not using.
Use log4j or java.util.logging (or both). Those are (both) foundational and
you should learn (both of) them very early in your Java career.
Remember - logging is meant to be there in production, for benefit of sysops
and system reliability engineers. Code is not the be-all and end-all of
programming.
--
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-25 22:12 +0000 |
| Message-ID | <XnsA004B034AE631jpnasty@94.75.214.39> |
| In reply to | #12329 |
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.
> Either way the logger should be tied to the actual class emitting log
> messages, not some common class.
>
I'm not sure what you mean. The main program creates the logger and
passes a reference to it to each class that it instantiates (well, not
all of them but I am gradually retrofitting the classes so that all of
them get an instance of the logger as a parameter).
Is that not the right thing to do?
I realize that I could have each class create its own logger and log but
would seem to guarantee a proliferation of logs that would be a pain to
find. It seems reasonable to me that if I have a bunch of programs,
including Foo and Bar, and any of them could call one of my common date
routines or my AboutDialog, that any log messages arising from those
classes should be in the log for Foo or Bar, not in separate logs for
each class. Then I'd end up having to look in the AboutDialog log for
messages from that class, a DateUtils log for messages from that class,
etc. etc.
>> The called classes write their messages to that logger. I've created
>> a method that does the logger creation and put it in a utility class
>> in my Common project so that my programs only need to execute that
>> method (passing in a few parameters of course) and get an appropriate
>> logger back. Each of the classes instantiated by the main programs
>> gets a logger passed among their parameters. The newly instantiated
>> class then verifies that the logger is not null and throws an
>> IllegalArgumentException if it is. Each class writes to the log when
>> it seems appropriate. Sometimes, that is to log an Exception. Other
>> times, I log things that are more diagnostic in nature. If a method
>> isn't 100% right yet, I will log calculations that it is doing, such
>> as calculating the width of a column in a JTable or whatever.
>
> Did you reinvent the logging wheel? If so, does your logging framework
> feature log levels, infinitely flexible log formats, logging to screen
> or (rolling) file logs, virtual elimination of logging overhead at
> levels finer than configured, automatic if slow retrieval of class and
> method and line where the logging happens, XML configuration,
> portability, a large body of online literature describing its use,
> standardization, widespread adoption, and a body of top developers
> contributing to the project?
>
Goodness no! I am using the Java Logging classes to do my logging. Sorry
if that wasn't clear.
>> This works okay but it seems to me that it might be more elegant to
>> put the logging in aspects, especially the diagnostic stuff that I am
>> using to verify that the suspect methods are doing their jobs
>> correctly.
>
> What is "elegant"?
>
> Personally I promote "useful" as the useful metric.
>
Fair enough. I have a great deal of respect for useful and would
certainly put it above elegant! But I'm the kind of guy who likes to have
his cake and eat it too. If I can make it useful AND elegant, that trumps
just useful in my book ;-)
>> I'm not sure yet if all the logging code, including the creation of
>> the log itself, should go into aspects though. It probably makes more
>> sense to create the logger the way I am doing it and continue to do
>> the actual
>
> Not from your description of it.
>
>> writes to the logs in my existing classes when it involves Exception
>> handling. The diagnostic logging, though, seems like a prime
>> candidate for the aspects. I could write pointcuts that specify the
>> methods that are a little dubious and log them in as much detail as I
>> need. Methods that are already working to my satisfaction could be
>> left alone with only their Exception logging.
>
> Logging is logging is logging, to misquote Gertrude Stein. Suddenly
> now you've created two logging aspects. That's not elegant.
>
> Logging shouldn't be added to and removed from code. That's not the
> purpose of logging. Logging is to remain in the code forever.
>
I think it depends on what kind of logging you're doing. I agree that
logging of Exceptions should probably be in the classes themselves as
long as the Exception can occur. (Mind you, from what I'm seeing in the
AspectJ manual, it seems as if aspects are designed to handle that too.)
But aspects seem more likely to be beneficial in tracking down wonky code
at development time. It's not that unusual for me to write a method that
does something and find that it works pretty well for most cases but then
do odd or unexpected things in some cases. For example, the method that
calculates column widths might do a reasonable job in most cases but
sometimes calculate widths that are noticeably too large or too small.
For something like that, I can see aspects being useful for digging out
what is actually going on in the method without having to recode the
method itself. And once the problem is found, if the debugging is
happening in an aspect, I just delete it from the aspect and leave my
original method nice and tidy rather than having to yank out the
statements I added.
Of course, the Eclipse debugger can make a lot of the logging unnecessary
in the first place so that you don't have to add code to either the
method or an aspect. I don't want to start writing reams of
System.out.println() statements when the debugger can often tell me
what's going on much better.
> Logging is not for the developer. That's an all-too-common
> misconception. Logging is for the sysop.
>
I agree. Mind you, I still tend to use them regularly to help with
debugging wonky code but the ultimate user of the log is the sysop.
> Have you ever tried to suss out a production issue from the logs?
>
Frankly, no. I aspire to write very useful messages that would be helpful
in that regard but I won't know how useful they really are until I have
some major systems in production.
> The sort of dynamic granularity you describe is built in to the
> logging framework. You use levels - DEBUG for debug purposes (or FINE
> if you're using java.util.logging), WARNING for warnings, ERROR
> (SEVERE) for errors, and so forth.
>
Yes, I'm using those levels.
> By removing logging to AspectJ, you eliminate the flexibility,
> visibility and granularity of control logging should support.
>
>>> It's not just in the code you weigh. Frameworks have a deployment
>>> cost. It's harder to deploy than to write code. Framework bloat is a
>>> major problem in the real world. Aspects also reduce visibility into
>>> areas, sometimes a good thing and others not.
>>>
>> What do you mean when you say "framework"? That term puts me in mind
>> of things like Spring - which I know of but have never used - but I'm
>> not using any formal frameworks like that and know very little about
>> them. I'm getting the impression that you are thinking of my work as
>> being sort of a homegrown framework. Maybe it is; I really don't
>> know.
>
> A deployment or code base that handles some part of the project under
> the hood for you, and gives you a public interface for control of its
> behavior. In your case I'm referring to the AspectJ framework. Logging
> is also a framework, one apparently you are not using.
>
Not true, as mentioned above. But it's my fault; I apparently wasn't
clear enough about what I am doing.
> Use log4j or java.util.logging (or both). Those are (both)
> foundational and you should learn (both of) them very early in your
> Java career.
>
Both would seem like overkill ;-) But I am indeed using
java.util.logging.
> Remember - logging is meant to be there in production, for benefit of
> sysops and system reliability engineers. Code is not the be-all and
> end-all of programming.
>
Agreed.
--
Novice
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-25 14:27 -0800 |
| Message-ID | <jibn8n$17s$1@news.albasani.net> |
| In reply to | #12332 |
On 02/25/2012 02: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.
Actually, what you do is different and some of that difference is terrible.
Why aren't you logging the exceptions?
And what you are doing here is radically different from what I proposed,
hardly at all similar in any respect. I don't understand why you think it's
similar.
> 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) {
My goodness, don't use TABs! Especially not in Usenet posts!
This use of a separate logger factory that takes over what the logging
framework already does is, well, curious.
> String METHOD_NAME = "configureLogger()"; //$NON-NLS-1$
You don't need this, and if you did it should be 'final' and named according
to the Java coding conventions.
> /* 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$
You didn't log this!
And those "$NON-NLS-1$" comments are highly distracting.
> }
>
> 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);
Really?
I can't go on. It's too painful.
> 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.
But, splutter, but, ... that's what the existing 'Logger.getLogger()' method
does!
You're doing everything by hand that the framework does for you!
> I realize that I could have each class create its own logger and log but
Huh?
No!
> would seem to guarantee a proliferation of logs that would be a pain to
> find. It seems reasonable to me that if I have a bunch of programs,
No, no, no, no.
You don't create multiple log files, one per class. Where did you get that notion?
You set up the logging in the configuration file. Done. Simple.
You are re-inventing the logging wheel. You said,
> Goodness no! I am using the Java Logging classes to do my logging. Sorry
> if that wasn't clear.
but you aren't using it correctly. What you are doing is defeating the
built-in features and reinventing everything. Don't do that.
And when I said you should know both ju.logging and log4j, somehow you
inferred that to mean that you should use both in the same program. Such leaps
you make! Settle back and stick with inferences that actually follow from what
I say.
--
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-25 23:29 +0000 |
| Message-ID | <XnsA004BD220634Ejpnasty@94.75.214.39> |
| In reply to | #12333 |
Lew <noone@lewscanon.com> wrote in news:jibn8n$17s$1@news.albasani.net:
> On 02/25/2012 02: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.
>
> Actually, what you do is different and some of that difference is
> terrible.
>
> Why aren't you logging the exceptions?
>
Because this is the code that creates the logger. If it fails to create
the logger, where would you like me to log the exception?
> And what you are doing here is radically different from what I
> proposed, hardly at all similar in any respect. I don't understand why
> you think it's similar.
>
Okay, maybe it's completely different then. I thought it was the same
spirit.
>> 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) {
>
> My goodness, don't use TABs! Especially not in Usenet posts!
>
Sorry.
> This use of a separate logger factory that takes over what the logging
> framework already does is, well, curious.
>
>> String METHOD_NAME = "configureLogger()"; //$NON-NLS-1$
>
> You don't need this, and if you did it should be 'final' and named
> according to the Java coding conventions.
>
I thought final was irrelevant in a method and only made a difference for
instance variables?
You're right about the case of the name. That should be methodName for a
method variable....
>> /* 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$
>
> You didn't log this!
>
Where would you like me to log this?
> And those "$NON-NLS-1$" comments are highly distracting.
>
Sorry, I should have stripped them and the tabs out of the code first.
>> }
>>
>> 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);
>
> Really?
>
> I can't go on. It's too painful.
>
Why? Telling me it's awful without saying why doesn't teach me anything.
>> 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.
>
> But, splutter, but, ... that's what the existing 'Logger.getLogger()'
> method does!
>
> You're doing everything by hand that the framework does for you!
>
So I just execute Logger.getLogger() and a logger will be magically
created that is exactly where I want it to be with exactly the file name
I want to ensure that it is in the right format, XML in my case and with
exactly the right logging level and handlers? I thought I had to do SOME
of the work to ensure I got what I wanted.
>> I realize that I could have each class create its own logger and log
>> but
>
> Huh?
>
> No!
>
>> would seem to guarantee a proliferation of logs that would be a pain
>> to find. It seems reasonable to me that if I have a bunch of
>> programs,
>
> No, no, no, no.
>
> You don't create multiple log files, one per class. Where did you get
> that notion?
>
Huh? You seem to be contradicting yourself. Are you saying I should
create one logging file per class or not? And why have a separate logging
file for each class? Isn't it more logical to have all the messages that
come from one program, say Foo, appear in the same log? Isn't the poor
Sysop going to be excessively busy if he has to check a separate log for
each and every one of the - hundreds? thousands? - of classes in the
system? Wouldn't it be more logical to group logs on the basis of which
application is invoking the class? Therefore, if method
getCurrentWeekdayName had problems while executing program Foo, the Foo
log would contain the information? Wouldn't the person running Foo be the
one that's notifying the SysOp that something screwy just happened while
running Foo? Then the name of the application would be a huge head start
in finding the problem: just look in the Foo log and all will be
revealed. Or at least enough to get started.
> You set up the logging in the configuration file. Done. Simple.
>
What configuration file? I'm not sure what you mean. First, I'm not sure
what you mean by a configuration file. Second, are you saying that all
applications will normally have a configuration file? I don't remember
coming across those in the Java Tutorial, for example, or even seeing
them mentioned in this newsgroup.
If this is some routine thing that professional developers do, great. I
obviously need to know about it. Can you point me to a tutorial or
whatever that will explain what they are and how to create them?
> You are re-inventing the logging wheel. You said,
>> Goodness no! I am using the Java Logging classes to do my logging.
>> Sorry if that wasn't clear.
>
> but you aren't using it correctly. What you are doing is defeating the
> built-in features and reinventing everything. Don't do that.
>
That was not my intention. I'm off to look at the logging classes again
and see how I can avoid reinventing the wheel. I'm really not seeing why
you say that yet. I'm using the standard Java Logging classes. I've
tweaked the properties file that governs logging a little bit to get the
effect that I wanted and I created my own variant on the XMLFormatter
that is only very slightly different. Aside from that, I'm using the
vanilla logging classes. I'm not sure how that constitutes reinventing
the framework. But, as I said, I'm going to review the logging classes
now and see if I'm overcomplicating the creation of the logger as you
say. Perhaps I am....
> And when I said you should know both ju.logging and log4j, somehow you
> inferred that to mean that you should use both in the same program.
> Such leaps you make! Settle back and stick with inferences that
> actually follow from what I say.
>
Well, here's the exact quote:
"Use log4j or java.util.logging (OR BOTH)". [emphasis added]
I don't think it's completely unreasonable to take that as a suggestion
to use both within a single program. Which is why I asked you about it.
Hey, I'm just trying to learn and I'm prepared to hear things that
surprise me. There might be some case to be made for logging redundantly
to two separate loggers that I hadn't considered. It seems farfetched to
me but it seemed like what you were saying.
Did you ever hear that old saying, attributed to various ancient
personages?
“He who knows not and knows not he knows not: he is a fool - shun him. He
who knows not and knows he knows not: he is simple - teach him. He who
knows and knows not he knows: he is asleep - wake him. He who knows and
knows he knows: he is wise - follow him.”
In that context, I consider myself "simple": I know that there are a
bunch of things I don't know. I'm looking at the people in this newsgroup
as being in the 'wise' category and am trying to learn from you.
As I've said, I'm a one man Java shop in a town that doesn't seem to do
much Java. I don't work in a professional Java shop so I have no
professional Java code to look at or peers to learn from. So I'm
floundering. That's why this newsgroup is important to me. I _AM_ trying
to get better at this....
--
Novice
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-25 18:33 -0500 |
| Message-ID | <4f496fe1$0$281$14726298@news.sunsite.dk> |
| In reply to | #12340 |
On 2/25/2012 6:29 PM, Novice wrote: > Did you ever hear that old saying, attributed to various ancient > personages? > > “He who knows not and knows not he knows not: he is a fool - shun him. He > who knows not and knows he knows not: he is simple - teach him. He who > knows and knows not he knows: he is asleep - wake him. He who knows and > knows he knows: he is wise - follow him.” Wise words. > In that context, I consider myself "simple": I know that there are a > bunch of things I don't know. I'm looking at the people in this newsgroup > as being in the 'wise' category and am trying to learn from you. > > As I've said, I'm a one man Java shop in a town that doesn't seem to do > much Java. I don't work in a professional Java shop so I have no > professional Java code to look at or peers to learn from. So I'm > floundering. That's why this newsgroup is important to me. I _AM_ trying > to get better at this.... You may be able to download and look at some open source code that uses logging. Arne
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-26 14:38 +0000 |
| Message-ID | <XnsA005633CF83E2jpnasty@94.75.214.39> |
| In reply to | #12341 |
Arne Vajhøj <arne@vajhoej.dk> wrote in news:4f496fe1$0$281$14726298@news.sunsite.dk: > On 2/25/2012 6:29 PM, Novice wrote: >> Did you ever hear that old saying, attributed to various ancient >> personages? >> >> “He who knows not and knows not he knows not: he is a fool - shun >> him. He who knows not and knows he knows not: he is simple - teach >> him. He who knows and knows not he knows: he is asleep - wake him. He >> who knows and knows he knows: he is wise - follow him.” > > Wise words. > >> In that context, I consider myself "simple": I know that there are a >> bunch of things I don't know. I'm looking at the people in this >> newsgroup as being in the 'wise' category and am trying to learn from >> you. >> >> As I've said, I'm a one man Java shop in a town that doesn't seem to >> do much Java. I don't work in a professional Java shop so I have no >> professional Java code to look at or peers to learn from. So I'm >> floundering. That's why this newsgroup is important to me. I _AM_ >> trying to get better at this.... > > You may be able to download and look at some open source code that > uses logging. > Can you suggest any specific projects/products that you think are particularly well-written? I had thought of looking at such code before but I'm not sure I'd necessarily recognize well-written code if I found it. It might look strange to me but actually be brilliant or viceversa. If I start looking at code that is written by someone who knows less than I do, I'll go backwards, not forwards, in my learning. -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-26 10:49 -0500 |
| Message-ID | <4f4a54a6$0$285$14726298@news.sunsite.dk> |
| In reply to | #12361 |
On 2/26/2012 9:38 AM, Novice wrote: > Arne Vajhøj<arne@vajhoej.dk> wrote in > news:4f496fe1$0$281$14726298@news.sunsite.dk: >> On 2/25/2012 6:29 PM, Novice wrote: >>> As I've said, I'm a one man Java shop in a town that doesn't seem to >>> do much Java. I don't work in a professional Java shop so I have no >>> professional Java code to look at or peers to learn from. So I'm >>> floundering. That's why this newsgroup is important to me. I _AM_ >>> trying to get better at this.... >> >> You may be able to download and look at some open source code that >> uses logging. > > Can you suggest any specific projects/products that you think are > particularly well-written? I had thought of looking at such code before > but I'm not sure I'd necessarily recognize well-written code if I found > it. It might look strange to me but actually be brilliant or viceversa. Most widely used open source Java server products would be fine. My immediate ideas would be products like Apache ActiveMQ and JBoss AS. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-26 10:53 -0500 |
| Message-ID | <4f4a5571$0$285$14726298@news.sunsite.dk> |
| In reply to | #12367 |
On 2/26/2012 10:49 AM, Arne Vajhøj wrote: > On 2/26/2012 9:38 AM, Novice wrote: >> Arne Vajhøj<arne@vajhoej.dk> wrote in >> news:4f496fe1$0$281$14726298@news.sunsite.dk: >>> On 2/25/2012 6:29 PM, Novice wrote: >>>> As I've said, I'm a one man Java shop in a town that doesn't seem to >>>> do much Java. I don't work in a professional Java shop so I have no >>>> professional Java code to look at or peers to learn from. So I'm >>>> floundering. That's why this newsgroup is important to me. I _AM_ >>>> trying to get better at this.... >>> >>> You may be able to download and look at some open source code that >>> uses logging. >> >> Can you suggest any specific projects/products that you think are >> particularly well-written? I had thought of looking at such code before >> but I'm not sure I'd necessarily recognize well-written code if I found >> it. It might look strange to me but actually be brilliant or viceversa. > > Most widely used open source Java server products would be fine. > > My immediate ideas would be products like Apache ActiveMQ and > JBoss AS. For something practically not used and of somewhat more questionable quality you could try: http://www.vajhoej.dk/arne/opensource/record/ Arne
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-26 18:17 +0000 |
| Message-ID | <XnsA00588732EC81jpnasty@94.75.214.39> |
| In reply to | #12367 |
Arne Vajhøj <arne@vajhoej.dk> wrote in news:4f4a54a6$0$285$14726298 @news.sunsite.dk: > On 2/26/2012 9:38 AM, Novice wrote: >> Arne Vajhøj<arne@vajhoej.dk> wrote in >> news:4f496fe1$0$281$14726298@news.sunsite.dk: >>> On 2/25/2012 6:29 PM, Novice wrote: >>>> As I've said, I'm a one man Java shop in a town that doesn't seem to >>>> do much Java. I don't work in a professional Java shop so I have no >>>> professional Java code to look at or peers to learn from. So I'm >>>> floundering. That's why this newsgroup is important to me. I _AM_ >>>> trying to get better at this.... >>> >>> You may be able to download and look at some open source code that >>> uses logging. >> >> Can you suggest any specific projects/products that you think are >> particularly well-written? I had thought of looking at such code before >> but I'm not sure I'd necessarily recognize well-written code if I found >> it. It might look strange to me but actually be brilliant or viceversa. > > Most widely used open source Java server products would be fine. > > My immediate ideas would be products like Apache ActiveMQ and > JBoss AS. > Thanks for the suggestions, Arne. I'll see what I can learn from that code! -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-25 16:01 -0800 |
| Message-ID | <jibso4$bv2$1@news.albasani.net> |
| In reply to | #12340 |
Novice wrote:
> Lew wrote:
>> Novice wrote:
>>> Lew wrote:
>>>> 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.
>>
>> Actually, what you do is different and some of that difference is
>> terrible.
>>
>> Why aren't you logging the exceptions?
>>
> Because this is the code that creates the logger. If it fails to create
> the logger, where would you like me to log the exception?
Yeah, I figured that out after the fact. You were doing a weird thing by
creating a factory method to call the factory method to create the logger.
>> And what you are doing here is radically different from what I
>> proposed, hardly at all similar in any respect. I don't understand why
>> you think it's similar.
>>
> Okay, maybe it's completely different then. I thought it was the same
> spirit.
No. The difference is that I put the logger code in each class, and don't have
a centralized factory factory. That's because the logging framework already
provides a factory and a way to configure it, so I don't try to reinvent that
entire mechanism.
>>> 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) {
>>
>> My goodness, don't use TABs! Especially not in Usenet posts!
>>
> Sorry.
>
>> This use of a separate logger factory that takes over what the logging
>> framework already does is, well, curious.
>>
>>> String METHOD_NAME = "configureLogger()"; //$NON-NLS-1$
>>
>> You don't need this, and if you did it should be 'final' and named
>> according to the Java coding conventions.
>>
> I thought final was irrelevant in a method and only made a difference for
> instance variables?
It's not irrelevant, depending on what you think is relevant. It prevents
reassignment of the reference, and as a comment lets maintainers know the
intent is to have an immutable reference.
But you are correct that is actually wasn't so necessary here.
> You're right about the case of the name. That should be methodName for a
> method variable....
>
>>> /* 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$
>>
>> You didn't log this!
>>
> Where would you like me to log this?
'logger.severe()' right at the point, just before the throw.
>> And those "$NON-NLS-1$" comments are highly distracting.
>>
> Sorry, I should have stripped them and the tabs out of the code first.
Actually, you should indent with spaces not TABs routinely. And strip out the
superfluous comments in your own code, too - that is, if they're actually
superfluous.
>>> }
>>>
>>> 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);
>>
>> Really?
>>
>> I can't go on. It's too painful.
>>
> Why? Telling me it's awful without saying why doesn't teach me anything.
I didn't stop there. I did say why.
>>> 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.
You don't need that. You just call 'Logger.getLogger()'. The utility class is
a whole lot of weird complication that you don't need.
>> But, splutter, but, ... that's what the existing 'Logger.getLogger()'
>> method does!
>>
>> You're doing everything by hand that the framework does for you!
>>
> So I just execute Logger.getLogger() and a logger will be magically
> created that is exactly where I want it to be with exactly the file name
> I want to ensure that it is in the right format, XML in my case and with
> exactly the right logging level and handlers? I thought I had to do SOME
> of the work to ensure I got what I wanted.
Yes, that is correct.
>>> I realize that I could have each class create its own logger and log
>>> but
>>
>> Huh?
>>
>> No!
>>
>>> would seem to guarantee a proliferation of logs that would be a pain
>>> to find. It seems reasonable to me that if I have a bunch of
>>> programs,
>>
>> No, no, no, no.
>>
>> You don't create multiple log files, one per class. Where did you get
>> that notion?
>>
> Huh? You seem to be contradicting yourself. Are you saying I should
> create one logging file per class or not? And why have a separate logging
No. I never said nor implied that you should have one logging file per class.
That one's on you, brother.
> file for each class? Isn't it more logical to have all the messages that
> come from one program, say Foo, appear in the same log? Isn't the poor
Yes, but why are you arguing a point not in dispute?
> Sysop going to be excessively busy if he has to check a separate log for
> each and every one of the - hundreds? thousands? - of classes in the
> system? Wouldn't it be more logical to group logs on the basis of which
> application is invoking the class? Therefore, if method
> getCurrentWeekdayName had problems while executing program Foo, the Foo
> log would contain the information? Wouldn't the person running Foo be the
> one that's notifying the SysOp that something screwy just happened while
> running Foo? Then the name of the application would be a huge head start
> in finding the problem: just look in the Foo log and all will be
> revealed. Or at least enough to get started.
How you do go on.
No one is suggesting anything like that scenario. so cool your jets, Cadet!
Wow.
>> You set up the logging in the configuration file. Done. Simple.
>>
> What configuration file? I'm not sure what you mean. First, I'm not sure
> what you mean by a configuration file. Second, are you saying that all
> applications will normally have a configuration file? I don't remember
> coming across those in the Java Tutorial, for example, or even seeing
> them mentioned in this newsgroup.
A configuration file is a file that contains configuration information.
As far as what you don't remember, if you follow the link from the API docs
for java.util.logging:
<http://docs.oracle.com/javase/7/docs/api/java/util/logging/package-summary.html>
You come across a recommendation to read the introduction to Java logging,
which I sure hope you followed:
"Related Documentation
For an overview of control flow, please refer to the Java Logging Overview."
which links you to
<http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview.html>
wherein you would have read, had you read it,
<http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview.html#a1.15>
"The APIs are structured so that an initial set of configuration information
is read as properties from a configuration file."
As for the tutorials, you have
<http://lmgtfy.com/?q=Java+logging+tutorial>
which among other links will find you
<http://forward.com.au/javaProgramming/javaGuiTips/javaLogging.html>
that covers a little about the "logging.properties" file.
> If this is some routine thing that professional developers do, great. I
> obviously need to know about it. Can you point me to a tutorial or
> whatever that will explain what they are and how to create them?
GIYF, dude.
>> You are re-inventing the logging wheel. You said,
>>> Goodness no! I am using the Java Logging classes to do my logging.
>>> Sorry if that wasn't clear.
>>
>> but you aren't using it correctly. What you are doing is defeating the
>> built-in features and reinventing everything. Don't do that.
>>
> That was not my intention. I'm off to look at the logging classes again
> and see how I can avoid reinventing the wheel. I'm really not seeing why
> you say that yet. I'm using the standard Java Logging classes. I've
Abusing
> tweaked the properties file that governs logging a little bit to get the
Huh. That's the configuration file, dude.
> effect that I wanted and I created my own variant on the XMLFormatter
> that is only very slightly different. Aside from that, I'm using the
> vanilla logging classes. I'm not sure how that constitutes reinventing
> the framework. But, as I said, I'm going to review the logging classes
> now and see if I'm overcomplicating the creation of the logger as you
> say. Perhaps I am....
The properties file specifies the log file, the log level (by type if you so
choose), the output format, whether you report the class and method being
logged - all the things you did manually in your utility class.
>> And when I said you should know both ju.logging and log4j, somehow you
>> inferred that to mean that you should use both in the same program.
>> Such leaps you make! Settle back and stick with inferences that
>> actually follow from what I say.
>>
> Well, here's the exact quote:
>
> "Use log4j or java.util.logging (OR BOTH)". [emphasis added]
Not in the same code! Yeesh.
...
> As I've said, I'm a one man Java shop in a town that doesn't seem to do
> much Java. I don't work in a professional Java shop so I have no
> professional Java code to look at or peers to learn from. So I'm
> floundering. That's why this newsgroup is important to me. I _AM_ trying
> to get better at this....
Of course, hence the detailed feedback.
--
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-26 17:22 +0000 |
| Message-ID | <XnsA0057F0ABEC37jpnasty@94.75.214.39> |
| In reply to | #12342 |
Lew <noone@lewscanon.com> wrote in news:jibso4$bv2$1@news.albasani.net:
> Novice wrote:
>> Lew wrote:
>>> Novice wrote:
>>>> Lew wrote:
>>>>> 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.
>>>
>>> Actually, what you do is different and some of that difference is
>>> terrible.
>>>
>>> Why aren't you logging the exceptions?
>>>
>> Because this is the code that creates the logger. If it fails to
>> create the logger, where would you like me to log the exception?
>
> Yeah, I figured that out after the fact. You were doing a weird thing
> by creating a factory method to call the factory method to create the
> logger.
>
>>> And what you are doing here is radically different from what I
>>> proposed, hardly at all similar in any respect. I don't understand
>>> why you think it's similar.
>>>
>> Okay, maybe it's completely different then. I thought it was the same
>> spirit.
>
> No. The difference is that I put the logger code in each class, and
> don't have a centralized factory factory. That's because the logging
> framework already provides a factory and a way to configure it, so I
> don't try to reinvent that entire mechanism.
>
>>>> 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) {
>>>
>>> My goodness, don't use TABs! Especially not in Usenet posts!
>>>
>> Sorry.
>>
>>> This use of a separate logger factory that takes over what the
>>> logging framework already does is, well, curious.
>>>
>>>> String METHOD_NAME = "configureLogger()"; //$NON-NLS-1$
>>>
>>> You don't need this, and if you did it should be 'final' and named
>>> according to the Java coding conventions.
>>>
>> I thought final was irrelevant in a method and only made a difference
>> for instance variables?
>
> It's not irrelevant, depending on what you think is relevant. It
> prevents reassignment of the reference, and as a comment lets
> maintainers know the intent is to have an immutable reference.
>
> But you are correct that is actually wasn't so necessary here.
>
Relevant was probably not the right word to use there but it was the
closest I could think of at the time. Some time ago, I saw a post where
someone had a local variable defined as final and someone remarked that
it wasn't necessary or appropriate or whatever to put final on a local
variable. That's all I meant to say. I'm happy to put final on my local
variables or leave it out, whichever is appropriate.
>> You're right about the case of the name. That should be methodName
>> for a method variable....
>>
>>>> /* 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$
>>>
>>> You didn't log this!
>>>
>> Where would you like me to log this?
>
> 'logger.severe()' right at the point, just before the throw.
>
>>> And those "$NON-NLS-1$" comments are highly distracting.
>>>
>> Sorry, I should have stripped them and the tabs out of the code
>> first.
>
> Actually, you should indent with spaces not TABs routinely.
Fair enough. I've gone into Eclipse, nosed around until I found where the
tabs are created (in "Formatter") and created a new profile that uses
spaces instead of tabs.
> And strip
> out the superfluous comments in your own code, too - that is, if
> they're actually superfluous.
>
When I write code, I typically write a comment first to express the
intent of what I want the next line or lines to do. Then I write the code
and leave the comment there due to the brainwashing I got in my early
days about always commenting everything. I try very hard to choose very
clear names for things like variables, methods, and classes and I'd like
to think the code is nearly self-explanatory most of the time without the
need for comments. I'm sometimes tempted to erase all or most of the
comments but then it occurs to me that what is obvious to me may not be
so obvious to a total beginner and maybe it's a good thing to leave the
comments there for their sake. In short, I agree that the comments in the
method I posted don't really need to be there for my sake but, as long as
I keep them accurate - and I usually do - they might conceivably help
someone else.
>>>> }
>>>>
>>>> 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);
>>>
>>> Really?
>>>
>>> I can't go on. It's too painful.
>>>
>> Why? Telling me it's awful without saying why doesn't teach me
>> anything.
>
> I didn't stop there. I did say why.
>
I hadn't got that far yet ;-)
>>>> 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.
>
> You don't need that. You just call 'Logger.getLogger()'. The utility
> class is a whole lot of weird complication that you don't need.
>
>>> But, splutter, but, ... that's what the existing
>>> 'Logger.getLogger()' method does!
>>>
>>> You're doing everything by hand that the framework does for you!
>>>
>> So I just execute Logger.getLogger() and a logger will be magically
>> created that is exactly where I want it to be with exactly the file
>> name I want to ensure that it is in the right format, XML in my case
>> and with exactly the right logging level and handlers? I thought I
>> had to do SOME of the work to ensure I got what I wanted.
>
> Yes, that is correct.
>
I gave your suggestion a try in my sandbox, where I'm playing with
Aspects. I wrote this little class:
=========================================================
package test;
import java.util.logging.Level;
import java.util.logging.Logger;
public class TestLogging {
public static void main(String[] args) {
@SuppressWarnings("unused")
TestLogging test = new TestLogging();
}
public TestLogging() {
Logger logger = Logger.getLogger("test");
logger.logp(Level.INFO, "myClass", "myMethod", "Monday");
logger.logp(Level.INFO, "myClass", "myMethod", "Tuesday");
logger.logp(Level.INFO, "myClass", "myMethod", "Wednesday");
logger.logp(Level.INFO, "myClass", "myMethod", "Thursday");
logger.logp(Level.INFO, "myClass", "myMethod", "Friday");
logger.logp(Level.INFO, "myClass", "myMethod", "Saturday");
logger.logp(Level.INFO, "myClass", "myMethod", "Sunday");
}
}
==============================================================
The code ran fine and the logging statements all appear nicely in red on
my console. So far, so good.
But I'd like them to appear in a log file somewhere, too. My
logging.properties has the following lines:
handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
java.util.logging.FileHandler.pattern = %h/java%u.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter
By my reckoning, that should ensure that I'm also getting a log file and,
since I'm running on Windows XP, I should be able to find it at C:
\Documents and Settings\[Windows ID]\javaX.log. Well, I've got a
java0.log through java4.log in that directory but none of them contain my
logging statements.
The only other place I can find to look, suggested by this site -
http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-
guide/tracing_logging.html - translates to C:\Documents and Settings
\[Windows ID]\Application Data\Sun\Java\Deployment\log. There's exactly
one file in that directory and it is a Java log with the ungainly name of
plugin5581819941091650582.log but it contains only this:
<?xml version="1.0" encoding="windows-1252" standalone="no"?>
<!DOCTYPE log SYSTEM "logger.dtd">
<log>
</log>
I'm not sure where else to look so I'm going back to the docs to see what
other clues I can find. I suspect that the indirection involved in trying
to find the log files was another factor in which I decided to create the
loggers the way I did....
The logged files simply aren't much use if you can't find them.
>>>> I realize that I could have each class create its own logger and
>>>> log but
>>>
>>> Huh?
>>>
>>> No!
>>>
>>>> would seem to guarantee a proliferation of logs that would be a
>>>> pain to find. It seems reasonable to me that if I have a bunch of
>>>> programs,
>>>
>>> No, no, no, no.
>>>
>>> You don't create multiple log files, one per class. Where did you
>>> get that notion?
>>>
>> Huh? You seem to be contradicting yourself. Are you saying I should
>> create one logging file per class or not? And why have a separate
>> logging
>
> No. I never said nor implied that you should have one logging file per
> class. That one's on you, brother.
>
Okay. Your phrasing was a bit confusing. I read it as "You don't create
multiple files, (you create) one per class." Apparently that's not what
you mean after all. Sorry.
>> file for each class? Isn't it more logical to have all the messages
>> that come from one program, say Foo, appear in the same log? Isn't
>> the poor
>
> Yes, but why are you arguing a point not in dispute?
>
Because your phrasing seemed to imply that I DID want one log per class.
>> Sysop going to be excessively busy if he has to check a separate log
>> for each and every one of the - hundreds? thousands? - of classes in
>> the system? Wouldn't it be more logical to group logs on the basis of
>> which application is invoking the class? Therefore, if method
>> getCurrentWeekdayName had problems while executing program Foo, the
>> Foo log would contain the information? Wouldn't the person running
>> Foo be the one that's notifying the SysOp that something screwy just
>> happened while running Foo? Then the name of the application would be
>> a huge head start in finding the problem: just look in the Foo log
>> and all will be revealed. Or at least enough to get started.
>
> How you do go on.
>
> No one is suggesting anything like that scenario. so cool your jets,
> Cadet!
>
> Wow.
>
Sorry. I was confused by what you seemed to imply.
>>> You set up the logging in the configuration file. Done. Simple.
>>>
>> What configuration file? I'm not sure what you mean. First, I'm not
>> sure what you mean by a configuration file. Second, are you saying
>> that all applications will normally have a configuration file? I
>> don't remember coming across those in the Java Tutorial, for example,
>> or even seeing them mentioned in this newsgroup.
>
> A configuration file is a file that contains configuration
> information.
>
I'd guessed that much ;-) I'm trying to figure out what they contain,
where I put them, etc. Reading ahead, you're about to explain that....
> As far as what you don't remember, if you follow the link from the API
> docs for java.util.logging:
> <http://docs.oracle.com/javase/7/docs/api/java/util/logging/package-sum
> mary.html>
>
> You come across a recommendation to read the introduction to Java
> logging, which I sure hope you followed:
> "Related Documentation
> For an overview of control flow, please refer to the Java Logging
> Overview." which links you to
> <http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview
> .html> wherein you would have read, had you read it,
> <http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview
> .html#a1.15> "The APIs are structured so that an initial set of
> configuration information is read as properties from a configuration
> file."
>
> As for the tutorials, you have
> <http://lmgtfy.com/?q=Java+logging+tutorial>
> which among other links will find you
> <http://forward.com.au/javaProgramming/javaGuiTips/javaLogging.html>
> that covers a little about the "logging.properties" file.
>
Actually, I have been in all of those documents in the last several hours
as I've been trying to puzzle out the right way to do logging. I'd seen
all of them before at some point, but it was a fair while ago. Back then,
I played with logging and came up with the logging code I posted (more
or less). I truly don't remember how I got to that code though. At a
guess, I didn't want the logs to go where the logging properties file
wanted to put it and wanted it in a directory within each project so that
it was more convenient, rather than putting all logs in the same
directory.
As for the term "configuration file" I didn't realize you meant
"logging.properties". That was my confusion there; I don't recall hearing
that called a configuration file before and thought you were talking
about something completely new and outside my experience.
>> If this is some routine thing that professional developers do, great.
>> I obviously need to know about it. Can you point me to a tutorial or
>> whatever that will explain what they are and how to create them?
>
> GIYF, dude.
>
GIYF??
>>> You are re-inventing the logging wheel. You said,
>>>> Goodness no! I am using the Java Logging classes to do my logging.
>>>> Sorry if that wasn't clear.
>>>
>>> but you aren't using it correctly. What you are doing is defeating
>>> the built-in features and reinventing everything. Don't do that.
>>>
>> That was not my intention. I'm off to look at the logging classes
>> again and see how I can avoid reinventing the wheel. I'm really not
>> seeing why you say that yet. I'm using the standard Java Logging
>> classes. I've
>
> Abusing
>
not deliberately, I assure you.
>> tweaked the properties file that governs logging a little bit to get
>> the
>
> Huh. That's the configuration file, dude.
>
Now the penny drops....
>> effect that I wanted and I created my own variant on the XMLFormatter
>> that is only very slightly different. Aside from that, I'm using the
>> vanilla logging classes. I'm not sure how that constitutes
>> reinventing the framework. But, as I said, I'm going to review the
>> logging classes now and see if I'm overcomplicating the creation of
>> the logger as you say. Perhaps I am....
>
> The properties file specifies the log file, the log level (by type if
> you so choose), the output format, whether you report the class and
> method being logged - all the things you did manually in your utility
> class.
>
>>> And when I said you should know both ju.logging and log4j, somehow
>>> you inferred that to mean that you should use both in the same
>>> program. Such leaps you make! Settle back and stick with inferences
>>> that actually follow from what I say.
>>>
>> Well, here's the exact quote:
>>
>> "Use log4j or java.util.logging (OR BOTH)". [emphasis added]
>
> Not in the same code! Yeesh.
>
> ...
>> As I've said, I'm a one man Java shop in a town that doesn't seem to
>> do much Java. I don't work in a professional Java shop so I have no
>> professional Java code to look at or peers to learn from. So I'm
>> floundering. That's why this newsgroup is important to me. I _AM_
>> trying to get better at this....
>
> Of course, hence the detailed feedback.
>
Which I appreciate, even if I seem a bit grumpy or frustrated at times.
But I'm still confused about the scope of my logs. According to the
logging overview, I want the argument to Logger.getLogger() to be "A name
for the logger. This should be a dot-separated name and should normally
be based on the package name or class name of the subsystem, such as
java.net or javax.swing."
I expect that they are assuming that each project has a unique package
name. Therefore, if my company is novice.com, then the Foo project will
presumably have a package named com.novice.foo and the Bar project will
have a package named com.novice.bar. Then, the logging for the Foo
project will be based on Logger.getLogger("com.novice.foo"), right? Then
every class within the Foo project will have the line:
Logger logger = Logger.getLogger("com.novice.foo");
Have I got this so far?
If so, the next logical step would be to treat all the stuff in the
Common project similarly. If I put all of those classes in package
com.novice.common, then each class would have this:
Logger logger = Logger.getLogger("com.novice.common");
Or would it be better to get a reference to the logger within Foo and
pass that to the classes in the Common project so that they write to the
logger used by the instantiating class from Foo?
Now, as it turns out, I've actually got a bunch of packages in project
Common. I'm separating different kinds of common classes via packages.
I'm not sure now if that is a good idea or a bad one. I've got separate
packages with the Common project for utilities, for classes dealing with
preference handling, for classes that are just simple lookups (including
Enums), classes that create generic panels for GUIs, etc. So maybe I need
to ask first if it is a bad idea to separate my common code into
categories or if it is better to lump it all together into a single
package.
If keeping the separate packages is a good idea, then I need a bit of
guidance on whether there should be a separate logger for each package or
whether I'm better to write all messages from all Common classes to the
same logger, e.g. com.novice.common despite their different packages.
Now, if Project Foo only uses code from one other project, Common, I only
have two logs to worry about, the one that has all the Foo stuff and the
one that has all the Common stuff. That's not too bad. Then again, maybe
it would be better to use Logger.getLogger("com.novice") and write every
message from every class I write to the very same log, regardless of
project. What is the best practice here?
I feel like I'm starting to see what you have in mind but I hope you stay
with me for just a bit longer until we've hashed the last bits out. I
don't want to go off in the wrong direction again so I need your
confirmation that I'm starting to get it now.
--
Novice
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-26 12:25 -0500 |
| Message-ID | <4f4a6b1d$0$290$14726298@news.sunsite.dk> |
| In reply to | #12370 |
On 2/26/2012 12:22 PM, Novice wrote:
> But I'm still confused about the scope of my logs. According to the
> logging overview, I want the argument to Logger.getLogger() to be "A name
> for the logger. This should be a dot-separated name and should normally
> be based on the package name or class name of the subsystem, such as
> java.net or javax.swing."
>
> I expect that they are assuming that each project has a unique package
> name. Therefore, if my company is novice.com, then the Foo project will
> presumably have a package named com.novice.foo and the Bar project will
> have a package named com.novice.bar. Then, the logging for the Foo
> project will be based on Logger.getLogger("com.novice.foo"), right? Then
> every class within the Foo project will have the line:
>
> Logger logger = Logger.getLogger("com.novice.foo");
>
> Have I got this so far?
>
> If so, the next logical step would be to treat all the stuff in the
> Common project similarly. If I put all of those classes in package
> com.novice.common, then each class would have this:
>
> Logger logger = Logger.getLogger("com.novice.common");
>
> Or would it be better to get a reference to the logger within Foo and
> pass that to the classes in the Common project so that they write to the
> logger used by the instantiating class from Foo?
The standard is to use the full (with package) class name as
the name of the logger.
Because logger configuration is applied tree wise, then you can
still configure at package level.
If you used package name as logger name, then you could
not configure by class.
Arne
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-26 21:08 +0000 |
| Message-ID | <XnsA005A56D659E8jpnasty@94.75.214.39> |
| In reply to | #12372 |
Arne Vajhøj <arne@vajhoej.dk> wrote in
news:4f4a6b1d$0$290$14726298@news.sunsite.dk:
> On 2/26/2012 12:22 PM, Novice wrote:
>> But I'm still confused about the scope of my logs. According to the
>> logging overview, I want the argument to Logger.getLogger() to be "A
>> name for the logger. This should be a dot-separated name and should
>> normally be based on the package name or class name of the subsystem,
>> such as java.net or javax.swing."
>>
>> I expect that they are assuming that each project has a unique
>> package name. Therefore, if my company is novice.com, then the Foo
>> project will presumably have a package named com.novice.foo and the
>> Bar project will have a package named com.novice.bar. Then, the
>> logging for the Foo project will be based on
>> Logger.getLogger("com.novice.foo"), right? Then every class within
>> the Foo project will have the line:
>>
>> Logger logger = Logger.getLogger("com.novice.foo");
>>
>> Have I got this so far?
>>
>> If so, the next logical step would be to treat all the stuff in the
>> Common project similarly. If I put all of those classes in package
>> com.novice.common, then each class would have this:
>>
>> Logger logger = Logger.getLogger("com.novice.common");
>>
>> Or would it be better to get a reference to the logger within Foo and
>> pass that to the classes in the Common project so that they write to
>> the logger used by the instantiating class from Foo?
>
> The standard is to use the full (with package) class name as
> the name of the logger.
>
> Because logger configuration is applied tree wise, then you can
> still configure at package level.
>
> If you used package name as logger name, then you could
> not configure by class.
>
Okay, fair enough. Hmm, I need to think through the implications of
that....
So, with respect to my common classes, should they all be in one big
package, like com.novice.common? Or is it better to group them on some
basis so that different types of common modules are in their own
packages? If grouping them is a good idea, what's the best way to group
them?
I'm currently grouping mine on a more-or-less functional basis. If the
class is essentially just a table lookup or enum, then it goes in the
com.novice.common.lookups package. If it is a utility, it goes into
com.novice.common.utilities. And so forth.
Also, do you have any idea where to find the log records I am writing
when I use Logger.getLogger("test") in my play code? I've tried the
location stated in logging.properties and I've tried
<User Application Data Folder>\Sun\Java\Deployment\log on Windows
as suggested in
http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-
guide/tracing_logging.html
but I'm not finding it. There are files there but the days of the week
are NOT in them and that's what I wrote to my logger.
I don't know where else to look.
--
Novice
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-26 18:33 -0500 |
| Message-ID | <4f4ac151$0$291$14726298@news.sunsite.dk> |
| In reply to | #12381 |
On 2/26/2012 4:08 PM, Novice wrote:
> Arne Vajhøj<arne@vajhoej.dk> wrote in
> news:4f4a6b1d$0$290$14726298@news.sunsite.dk:
>> The standard is to use the full (with package) class name as
>> the name of the logger.
>>
>> Because logger configuration is applied tree wise, then you can
>> still configure at package level.
>>
>> If you used package name as logger name, then you could
>> not configure by class.
>>
> Okay, fair enough. Hmm, I need to think through the implications of
> that....
>
> So, with respect to my common classes, should they all be in one big
> package, like com.novice.common? Or is it better to group them on some
> basis so that different types of common modules are in their own
> packages? If grouping them is a good idea, what's the best way to group
> them?
>
> I'm currently grouping mine on a more-or-less functional basis. If the
> class is essentially just a table lookup or enum, then it goes in the
> com.novice.common.lookups package. If it is a utility, it goes into
> com.novice.common.utilities. And so forth.
That is general question not specific to logging or AOP.
You need a good structure of your classes and source code.
A key factor in the decision between com.novice.common and
com.novice.common.xxxx must be the number of classes.
Do you have so many classes that it makes sense to split up?
> Also, do you have any idea where to find the log records I am writing
> when I use Logger.getLogger("test") in my play code? I've tried the
> location stated in logging.properties and I've tried
>
> <User Application Data Folder>\Sun\Java\Deployment\log on Windows
>
> as suggested in
> http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-
> guide/tracing_logging.html
>
> but I'm not finding it. There are files there but the days of the week
> are NOT in them and that's what I wrote to my logger.
It should write to the file specified in the properties file.
May we see that?
Arne
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-26 17:05 -0800 |
| Message-ID | <jiekrs$tk3$2@news.albasani.net> |
| In reply to | #12392 |
Arne Vajhøj wrote: > Novice wrote: > > I'm currently grouping mine on a more-or-less functional basis. If the > > class is essentially just a table lookup or enum, then it goes in the > > com.novice.common.lookups package. If it is a utility, it goes into > > com.novice.common.utilities. And so forth. > > That is general question not specific to logging or AOP. > > You need a good structure of your classes and source code. > > A key factor in the decision between com.novice.common and > com.novice.common.xxxx must be the number of classes. > > Do you have so many classes that it makes sense to split up? That threshold would be one. Every type should be in a package. Every type should be in its appropriate package, irrespective of how many types (not just classes!) you have. A model-view-presenter program could, and probably should, have three packages with just the five or six types (including the three concrete classes but not the test code, which would add more). -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web