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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Date | 2012-02-26 11:04 -0400 |
| Message-ID | <TRr2r.9076$zD5.8609@newsfe12.iad> |
| In reply to | #12358 |
On 12-02-26 07:18 AM, Martin Gregorie wrote: > On Sat, 25 Feb 2012 22:20:03 -0800, Lew wrote: > >> The logger being tied to the class (or its name) gives you class-level >> control over the logger behavior at deployment time by adjustment of the >> logging properties (or XML) configuration file. This is desirable. >> > That's an interesting approach, though not one that I use. I tend to > prefer a single logger per process with an associated level attribute, > and to sprinkle classes with logger calls specifying different levels so > I can vary the logged detail depending on what I need to see. The minimal > level may correspond to nothing more than reporting overall run > statistics. Next level will log method exits and show call arguments plus > return value. The level above that shows method entry and beyond that > anything that might be relevant in the method internals: both of these > are omitted unless the method is complex enough to require them. [ SNIP ] I don't see anything you say above as being in conflict with the "standard" use of individual loggers in Java logging frameworks. I can only speak for myself, but I hope that pretty much everyone does what I am about to describe, or at least gets it. When working through a given method in a given class, you decide that at various points you have information that should be logged. You also know for each piece of information what logging level applies: the association of an appropriate logging level (e.g. DEBUG, INFO, WARN, ERROR, or equivalents) with corresponding information to be logged is probably the most important decision that you, the log statement coder, can make. It's not going to change; it's not supposed to change. It is entirely appropriate to have two or three log statements one after another, each at a different level, each with different information. What a lot of developers do though is squash all that together into one log statement at one level: they have just defeated the purpose of logging. The point of having (typically) a logger per class, as Lew indicated, is to then give you the other piece of the puzzle - fine-grained configuration. This does exactly what you do with your "process" logger, and more: from that XML or .properties config file you can easily control which of your log statements in a given package or class get logged, by level. To summarize, the methods in class a.b.c.X get all "logged up", with statements at various carefully-chosen levels. From the config file we control for package a.b or a.b.c or even specifically for class a.b.c.X whether we want to see everything above INFO inclusive, say, or everything down to DEBUG. On a sidenote the configuration isn't just deployment time. With Java EE 5 and 6 servers it's generally reasonably straightforward to do a bit of coding to expose selected logging framework functionality through a JMX MBean, such as the ability to change levels by logger. I'll add that log4j does have a DOMConfigurator.configureAndWatch() method that can be used to load up XML configuration, and have a thread check for config file changes at intervals; I've seen this approach fail with app server restarts so I stick to JMX. AHS -- -- Gaiety is the most outstanding feature of the Soviet Union. Josef Stalin, November 1935
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Date | 2012-02-26 10:22 -0400 |
| Message-ID | <Wer2r.11011$zA2.8174@newsfe02.iad> |
| In reply to | #12352 |
On 12-02-26 02:20 AM, Lew wrote: > markspace wrote: >> Arne Vajhøj wrote: >> >>> That looks as if you are almost building your own logging framework >>> on top of a logging framework. >>> >>> That does not make much sense to me. >> >> >> I can think of a use case for it though. Let's say you haven't decided >> which >> logging framework to use, or you want to be flexible as to which one >> to use. >> (Different customers of yours prefer different loggers.) > > That's what Apache Commons logging is for. As soon as a mention of commons logging comes up, I feel bound to mention SLF4J. :-) For the OP, if you're genuinely researching Java logging, check out SLF4J (http://www.slf4j.org/). This is a facade for other logging frameworks, so you'd actually implement using JUL or log4j or logback. Note that the same fellow who is responsible for log4j also drives slf4j and logback. Also while we are at it, I recommend http://www.javacodegeeks.com/2011/01/10-tips-proper-application-logging.html as a good list of tips for application logging. [ SNIP ] > It's actually common for libraries to use either ju.logging or log4j > without regard for your preference, with the result that both frameworks > wind up in the same program. Yes. There are a few different situations that arise here. In one case, the 3rd party library uses the *same* logging framework as you do. In which case, depending on overall environment and various classloaders, don't be surprised if your logging configuration also applies to that 3rd party library. You may start out with an unexpected spew of log statements in your log files until you finetune your loggers. From my standpoint I always see that extra flow of info with gratitude. I'll usually set first logging configuration to DEBUG for the packages in 3rd party libraries, just to see what I get. If the external parties also wrote good logging statements then the result is a major bonus, to again be filtered and directed as needed. In the other major case, the 3rd party library uses something different. Pay attention to that; hunt down its logging configuration file. You're not just using that library's Java API, you're also using its ability to log what's happening. Avoid having it be a black box that you can only debug into with decompiling to try to figure out what it's doing. >> So the idea is that you wrap the logging framework in your own, and then >> you're free to provide an implementation that matches whatever logging >> framework you choose to use in the future. Maybe this is not for >> everyone, but >> I could see its advantages. Some folks might like java.util.Logger, >> some folks >> like log4j. And some might like things that I don't know about yet. > > I think in Java those two pretty much have it sewn up. See above wrt slf4j and logback. [ SNIP ] AHS -- -- Gaiety is the most outstanding feature of the Soviet Union. Josef Stalin, November 1935
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-26 21:04 +0000 |
| Message-ID | <XnsA005A4C4B17A0jpnasty@94.75.214.39> |
| In reply to | #12359 |
Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote in news:Wer2r.11011$zA2.8174@newsfe02.iad: > On 12-02-26 02:20 AM, Lew wrote: >> markspace wrote: >>> Arne Vajhøj wrote: >>> >>>> That looks as if you are almost building your own logging framework >>>> on top of a logging framework. >>>> >>>> That does not make much sense to me. >>> >>> >>> I can think of a use case for it though. Let's say you haven't >>> decided which >>> logging framework to use, or you want to be flexible as to which one >>> to use. >>> (Different customers of yours prefer different loggers.) >> >> That's what Apache Commons logging is for. > > As soon as a mention of commons logging comes up, I feel bound to > mention SLF4J. :-) > > For the OP, if you're genuinely researching Java logging, check out > SLF4J (http://www.slf4j.org/). This is a facade for other logging > frameworks, so you'd actually implement using JUL or log4j or logback. Right now, I'm focusing on trying to use JUL correctly and I'm a little worried that I'm going to confuse myself by switching horses to a different logging approach. But it sounds like sfl4j may be the way to go in the not too distant future. As it happens, I downloaded a package called DBPool this week and had a newbie question that involved logging. My question didn't seem to be covered in the documentation. I used the email link on the web page and got some assistance from the developer. He mentioned in passing that he is probably switching to slf4j in his next release. That was the first time I heard of it but from what you're saying, it may be the way to go very soon.... By the way, I've skimmed the introduction to slf4j on their website. It looks pretty good! Maybe I SHOULD switch to that approach! > Note that the same fellow who is responsible for log4j also drives > slf4j and logback. > > Also while we are at it, I recommend > http://www.javacodegeeks.com/2011/01/10-tips-proper-application-logging > .html as a good list of tips for application logging. > Interesting article! I'm not finished yet but the 6th of his tips seems very counter-intuitive. He strongly advocates not including the class name and method name in the log records. To my way of thinking, those are among the most essential parts of the message. If I don't know where the message was written, how am I supposed to find the source code to debug it? I really don't see what he's saying. Is he assuming that the class name and method name will be inferred in some other way anyway so it isn't necessary to include that in each log message? If so, how will it be determined? Otherwise, this tip doesn't seem to make any sense. > [ SNIP ] > >> It's actually common for libraries to use either ju.logging or log4j >> without regard for your preference, with the result that both >> frameworks wind up in the same program. > > Yes. There are a few different situations that arise here. In one > case, the 3rd party library uses the *same* logging framework as you > do. In which case, depending on overall environment and various > classloaders, don't be surprised if your logging configuration also > applies to that 3rd party library. You may start out with an > unexpected spew of log statements in your log files until you finetune > your loggers. > > From my standpoint I always see that extra flow of info with > gratitude. I'll usually set first logging configuration to DEBUG for > the packages in 3rd party libraries, just to see what I get. If the > external parties also wrote good logging statements then the result is > a major bonus, to again be filtered and directed as needed. > > In the other major case, the 3rd party library uses something > different. Pay attention to that; hunt down its logging configuration > file. You're not just using that library's Java API, you're also using > its ability to log what's happening. Avoid having it be a black box > that you can only debug into with decompiling to try to figure out > what it's doing. > >>> So the idea is that you wrap the logging framework in your own, and >>> then you're free to provide an implementation that matches whatever >>> logging framework you choose to use in the future. Maybe this is not >>> for everyone, but >>> I could see its advantages. Some folks might like java.util.Logger, >>> some folks >>> like log4j. And some might like things that I don't know about yet. >> >> I think in Java those two pretty much have it sewn up. > > See above wrt slf4j and logback. > Thanks for another very helpful post, Arved! -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-26 14:01 -0800 |
| Message-ID | <jiea3n$bva$1@news.albasani.net> |
| In reply to | #12379 |
Novice wrote: > Arved Sandstrom wrote: >> Also while we are at it, I recommend >> http://www.javacodegeeks.com/2011/01/10-tips-proper-application-logging >> .html as a good list of tips for application logging. >> > Interesting article! I'm not finished yet but the 6th of his tips seems > very counter-intuitive. He strongly advocates not including the class > name and method name in the log records. To my way of thinking, those are > among the most essential parts of the message. If I don't know where the > message was written, how am I supposed to find the source code to debug > it? By the content of the message, duh. The problem with using the logger to reflectively obtain the class and method name is that the documentation claims it is a horrid performance penalty, as you would know if you read the logger documentation. > I really don't see what he's saying. Is he assuming that the class name > and method name will be inferred in some other way anyway so it isn't No, he's recommending that if you need that information that you include it in your message explicitly, not by inference. > necessary to include that in each log message? If so, how will it be > determined? Otherwise, this tip doesn't seem to make any sense. There's that word "seem" again. You need to stop using it. You know damn well that the tip makes sense. You just don't know how yet. "Seems" is putting a wall between you and comprehension. As far as the cost of using the logger to elicit class and method information, that probably won't matter as much as the documentation claims. At level WARN[ING] and above, performance is probably not an issue, and below that you usually have logging disabled, and performance again is not an issue. When you do have DEBUG [FINE] enabled, you probably aren't examining performance and again it doesn't matter. So I tend to go ahead and use the logger to show class and method data. Since you can change this by altering the configuration file without rebuilding the app, it's a non-issue. You just change the logging output as you need when you need to. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-26 18:46 -0500 |
| Message-ID | <4f4ac444$0$288$14726298@news.sunsite.dk> |
| In reply to | #12388 |
On 2/26/2012 5:01 PM, Lew wrote: > Novice wrote: >> Arved Sandstrom wrote: >>> Also while we are at it, I recommend >>> http://www.javacodegeeks.com/2011/01/10-tips-proper-application-logging >>> .html as a good list of tips for application logging. >>> >> Interesting article! I'm not finished yet but the 6th of his tips seems >> very counter-intuitive. He strongly advocates not including the class >> name and method name in the log records. To my way of thinking, those are >> among the most essential parts of the message. If I don't know where the >> message was written, how am I supposed to find the source code to debug >> it? > > By the content of the message, duh. > > The problem with using the logger to reflectively obtain the class and > method name is that the documentation claims it is a horrid performance > penalty, as you would know if you read the logger documentation. > As far as the cost of using the logger to elicit class and method > information, that probably won't matter as much as the documentation > claims. At level WARN[ING] and above, performance is probably not an > issue, and below that you usually have logging disabled, and performance > again is not an issue. When you do have DEBUG [FINE] enabled, you > probably aren't examining performance and again it doesn't matter. So I > tend to go ahead and use the logger to show class and method data. Yep. I think most actually do use the feature and live with its consequences. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-26 09:50 -0500 |
| Message-ID | <4f4a46a2$0$282$14726298@news.sunsite.dk> |
| In reply to | #12351 |
On 2/25/2012 11:22 PM, markspace wrote: > On 2/25/2012 3:22 PM, Arne Vajhøj wrote: >> That looks as if you are almost building your own logging framework >> on top of a logging framework. >> >> That does not make much sense to me. > > I can think of a use case for it though. Let's say you haven't decided > which logging framework to use, or you want to be flexible as to which > one to use. (Different customers of yours prefer different loggers.) Commons Logging already exist to handle that! Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-26 10:38 -0500 |
| Message-ID | <4f4a5200$0$285$14726298@news.sunsite.dk> |
| In reply to | #12351 |
On 2/25/2012 11:22 PM, markspace wrote: > Lastly, I don't know about log4j, but I don't think the > java.util.logging package uses threads when logging. Any IO operations > the logger makes will block the calling thread. I've heard this is > undesirable in most cases. So rolling your own framework also gives you > control over threading issues too, which again might be important for > some customers. I don't think log4j write in a separate thread either. But I don't think it is necessary. If the call actually had to block until the data were written to the rotating plates, then it could be significant. But on modern OS'es the data will just be copied over to some system memory where it will be transferred to the RAID controller memory where it will be transferred to the memory in the drives before it eventually end up on the plates. Arne
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-26 20:49 +0000 |
| Message-ID | <XnsA005A20C7713Bjpnasty@94.75.214.39> |
| In reply to | #12351 |
markspace <-@.> wrote in news:jicc1d$er6$1@dont-email.me:
> On 2/25/2012 3:22 PM, Arne Vajhøj wrote:
>
>> That looks as if you are almost building your own logging framework
>> on top of a logging framework.
>>
>> That does not make much sense to me.
>
>
> I can think of a use case for it though. Let's say you haven't decided
> which logging framework to use, or you want to be flexible as to which
> one to use. (Different customers of yours prefer different loggers.)
>
> (Not syntax checked or tested.)
>
> abstract class MyLogger {
>
> public static MyLogger getLogger( String name ) {
> MyLogger logger = Class.forName(
> System.getProperty("me.mystuff.MyLogger.logImpl",
> "me.mystuff.MyDefaultLogger" ).newInstance());
> return logger;
> }
>
> public abstract void logStuff(Object...);
> }
>
>
> So the idea is that you wrap the logging framework in your own, and
then
> you're free to provide an implementation that matches whatever logging
> framework you choose to use in the future. Maybe this is not for
> everyone, but I could see its advantages. Some folks might like
> java.util.Logger, some folks like log4j. And some might like things
> that I don't know about yet.
>
I wish I could say I was that clever but I'd be lying if I did.
I've simply been doing logging incorrectly. I don't even remember what
thought process got me doing things the way I do in my code. I worked
that technique out a few years ago, then had a gap away from Java for a
while and am finally revisiting a lot of my old code to do things the
proper way. Lew has convinced me it's not the right way to do things. Now
I'm trying to get a clear picture of what I SHOULD be doing so that I can
revise my code....
> A couple of other things.
>
> Lew wrote:
>
> public class Foo
> {
> final Logger logger = getLogger(getClass());
> [...]
> }
>
> This requires that a logger is instantiated for each object as it is
> created. Potentially this is a lot of work, and each logger may not be
> used. (Even declaring the logger to be static still requires a logger
> per class loaded.)
>
> Whereas this:
>
> ...
> try {
> ... some stuff...
> } catch (Exception ex) {
> getLogger(getClass()).log( ... );
> }
>
> creates the logger lazily and therefore doesn't spend any resources if
> logging happens to be never required.
>
> Lastly, I don't know about log4j, but I don't think the
> java.util.logging package uses threads when logging. Any IO operations
> the logger makes will block the calling thread. I've heard this is
> undesirable in most cases. So rolling your own framework also gives
you
> control over threading issues too, which again might be important for
> some customers.
>
>
--
Novice
[toc] | [prev] | [next] | [standalone]
| From | jlp <jlp@jlp.com> |
|---|---|
| Date | 2012-02-25 09:47 +0100 |
| Message-ID | <4f48a005$0$21455$ba4acef3@reader.news.orange.fr> |
| In reply to | #12310 |
Why not the Eclipse / AspectJ forum ? http://www.eclipse.org/aspectj/userlists.php Le 25/02/2012 06:47, Novice a écrit : > 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? >
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-25 17:03 +0000 |
| Message-ID | <XnsA0047BC47D6D9jpnasty@94.75.214.39> |
| In reply to | #12313 |
jlp <jlp@jlp.com> wrote in news:4f48a005$0$21455$ba4acef3@reader.news.orange.fr: > > Why not the Eclipse / AspectJ forum ? > > http://www.eclipse.org/aspectj/userlists.php > > Thanks, I'll probably use that in addition to this newsgroup. -- Novice
[toc] | [prev] | [next] | [standalone]
| From | jlp <jlp@jlp.com> |
|---|---|
| Date | 2012-02-25 20:02 +0100 |
| Message-ID | <4f493032$0$12503$ba4acef3@reader.news.orange.fr> |
| In reply to | #12323 |
Le 25/02/2012 18:03, Novice a écrit : > jlp<jlp@jlp.com> wrote in > news:4f48a005$0$21455$ba4acef3@reader.news.orange.fr: > >> >> Why not the Eclipse / AspectJ forum ? >> >> http://www.eclipse.org/aspectj/userlists.php >> >> > Thanks, I'll probably use that in addition to this newsgroup. > > -- > Novice and the main developper of AspectJ ( Andy CLEMENT) is very reactive in the forum ( without flaming newbies ;-) ) -- Cordialement Jean-Louis Pasturel
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Date | 2012-02-25 10:20 -0400 |
| Message-ID | <m662r.13950$yb.8316@newsfe20.iad> |
| In reply to | #12310 |
On 12-02-25 01:47 AM, 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 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? > A bit of reasoning can go a long ways to telling you whether aspects make sense for a particular job. This reasoning starts with an examination of the join points that AspectJ makes available in its join point model (JPM). You'll find this information tabulated in the AspectJ programming guide. You'll see that the join points available to us in AspectJ include method calls/executions. The method call/execution join points have state, one piece of which is the object array of method arguments. As you might expect the other pieces of state are the objects involved (only one for the method execution join point). You also know, or should be starting to understand, that pointcuts are the mechanism by which you choose *which* join points are in use. This can be very powerful: for the method execution join point you could easily select only the public methods for a given class, and that becomes a certain pointcut that you use. Dynamic pointcuts would even allow you to say that, for example, if you have defined a pointcut, say Pointcut 1, that selects all the public methods for class A (more precisely, selects the join points that represent the executions for all the public methods in class A), that you are also interested in the executions of methods that happen within the context of those join points. In other words, if "public A.someMethod(args)" runs, that's been identified by Pointcut 1. Pointcut 2 could include any methods that are *called by* A.someMethod(args). Finally, with the _advice_, you have even more control on what code you run at each selected join point, *when* you run it in temporal relation to the join point (e.g. maybe you run some code if the method threw an exception), and even whether you run the code at all. And as you might expect, the advice knows about certain state - advice associated with a pointcut has access to the state of the join points. So an advice associated with our Pointcut 1 sees the method arguments. Of all the other join points available in AspectJ, let's keep field assignment and constructor calls/executions in mind as well, as we think logging. So let's consider logging, armed with all of this knowledge. If nothing else, you know that you can log method calls & executions with great flexibility. If you wanted to, you could be logging, using log4j say, messages out at an error or warn level for exceptions thrown by any methods which are called by public methods in package org.whatsit.*. At the same time you might log the public calls in that package at debug level. As an aside, you can see why this type of application of AOP is called tracing. Very powerful tracing, but still execution tracing. But, and this is one main "but", you don't have access to the guts of interesting methods unless the internals are also identifiable by join points. If there is an important conditional, the correct behaviour of which is bedevilling you, and which relies on local variables computed in a local chunk of code in that method, AspectJ has no eyes on it. You're not going to be logging this kind of thing with aspects. Another big "but", maybe not so much a "but" rather a general consideration, is that if you start getting very fine-grained about pointcuts, you're sort of defeating the purpose of AOP. We're, I expect, considering a codebase that has no extensive logging, maybe none. If you are going to spend inordinate amounts of time tailoring pointcuts and advice for umpteen different types of logging, *you may as well bite the bullet and go into the code and directly use the logging framework*, rather than apply it through the agency of aspects. In a nutshell, for logging, I myself have used AspectJ for emergency maintenance: the codebase in question has no logging, or what it has is useless, and there is limited time to add logging to source. So this is execution tracing logging. I hope this helps. AHS -- -- Gaiety is the most outstanding feature of the Soviet Union. Josef Stalin, November 1935
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2012-02-25 08:18 -0800 |
| Message-ID | <jib1l6$2mf$1@dont-email.me> |
| In reply to | #12315 |
On 2/25/2012 6:20 AM, Arved Sandstrom wrote: > > You'll see that the join points available to us in AspectJ include > method calls/executions. That was a great post on AoP, and I appreciate you taking the time to type all that out. I have a couple of additional questions, if I may: Does "method calls/execution" include static methods? And, is all AoP in Java code weaving now, or does some of it involve wrapper classes or reflection?
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-25 12:04 -0500 |
| Message-ID | <4f4914ab$0$294$14726298@news.sunsite.dk> |
| In reply to | #12321 |
On 2/25/2012 11:18 AM, markspace wrote: > Does "method calls/execution" include static methods? AspectJ can be used with static methods. > And, is all AoP in Java code weaving now, or does some of it involve > wrapper classes or reflection? Static or dynamic weaving. And weaving is more the how where wrapper is that what. Arne
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-25 17:17 +0000 |
| Message-ID | <XnsA0047E34BAB40jpnasty@94.75.214.39> |
| In reply to | #12315 |
Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote in news:m662r.13950$yb.8316@newsfe20.iad: [snip] >>But the >> bigger issue remains: are aspects a good approach for what I want to >> do? If not, what would be a better strategy? >> > A bit of reasoning can go a long ways to telling you whether aspects > make sense for a particular job. This reasoning starts with an > examination of the join points that AspectJ makes available in its > join point model (JPM). You'll find this information tabulated in the > AspectJ programming guide. > > You'll see that the join points available to us in AspectJ include > method calls/executions. The method call/execution join points have > state, one piece of which is the object array of method arguments. As > you might expect the other pieces of state are the objects involved > (only one for the method execution join point). > > You also know, or should be starting to understand, that pointcuts are > the mechanism by which you choose *which* join points are in use. This > can be very powerful: for the method execution join point you could > easily select only the public methods for a given class, and that > becomes a certain pointcut that you use. > > Dynamic pointcuts would even allow you to say that, for example, if > you have defined a pointcut, say Pointcut 1, that selects all the > public methods for class A (more precisely, selects the join points > that represent the executions for all the public methods in class A), > that you are also interested in the executions of methods that happen > within the context of those join points. In other words, if "public > A.someMethod(args)" runs, that's been identified by Pointcut 1. > Pointcut 2 could include any methods that are *called by* > A.someMethod(args). > > Finally, with the _advice_, you have even more control on what code > you run at each selected join point, *when* you run it in temporal > relation to the join point (e.g. maybe you run some code if the method > threw an exception), and even whether you run the code at all. And as > you might expect, the advice knows about certain state - advice > associated with a pointcut has access to the state of the join points. > So an advice associated with our Pointcut 1 sees the method arguments. > > Of all the other join points available in AspectJ, let's keep field > assignment and constructor calls/executions in mind as well, as we > think logging. > > So let's consider logging, armed with all of this knowledge. If > nothing else, you know that you can log method calls & executions with > great flexibility. If you wanted to, you could be logging, using log4j > say, messages out at an error or warn level for exceptions thrown by > any methods which are called by public methods in package > org.whatsit.*. At the same time you might log the public calls in that > package at debug level. > > As an aside, you can see why this type of application of AOP is called > tracing. Very powerful tracing, but still execution tracing. > > But, and this is one main "but", you don't have access to the guts of > interesting methods unless the internals are also identifiable by join > points. If there is an important conditional, the correct behaviour of > which is bedevilling you, and which relies on local variables computed > in a local chunk of code in that method, AspectJ has no eyes on it. > You're not going to be logging this kind of thing with aspects. > I think you just saved me a fair bit of time ;-) I was curious to see whether I could use aspects to do what I'll call diagnostic logging. I have some methods that do "calculations" of one kind or another, like the best width for a column in a JTable given the width of the values in each column, and it would be neat if I could remove all of that logging code from the method itself and put it in aspects. Then, when the method is working 100% to my satisfaction, I can discard that aspect and leave the method uncluttered. From what you're saying, I may not be able to capture the values of all the variables that are being juggled in the suspect method. I had wondered about that and was going to try it myself to see. I probably still will but I'll be less surprised/disappointed if I can't access the information I want. > Another big "but", maybe not so much a "but" rather a general > consideration, is that if you start getting very fine-grained about > pointcuts, you're sort of defeating the purpose of AOP. We're, I > expect, considering a codebase that has no extensive logging, maybe > none. If you are going to spend inordinate amounts of time tailoring > pointcuts and advice for umpteen different types of logging, *you may > as well bite the bullet and go into the code and directly use the > logging framework*, rather than apply it through the agency of > aspects. > Actually, I already have logging in place for most of classes and am retrofitting it to the rest. I use the Java Logging classes, as opposed to Log4j, but I'm not fanatical about it. I'm hearing more and more to the effect that Log4j is better so maybe I'll make the switch. The better I design my logging, the less painful that is going to be ;-) > In a nutshell, for logging, I myself have used AspectJ for emergency > maintenance: the codebase in question has no logging, or what it has > is useless, and there is limited time to add logging to source. So > this is execution tracing logging. > > I hope this helps. > It does, Arved. Thanks! So what do you use aspects for, besides the occasional need to add logging into poorly-logged classes? -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Date | 2012-02-25 18:40 -0400 |
| Message-ID | <0sd2r.15294$xF1.8403@newsfe01.iad> |
| In reply to | #12325 |
On 12-02-25 01:17 PM, Novice wrote: > Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote in > news:m662r.13950$yb.8316@newsfe20.iad: > [snip] [ SNIP ] >> But, and this is one main "but", you don't have access to the guts of >> interesting methods unless the internals are also identifiable by join >> points. If there is an important conditional, the correct behaviour of >> which is bedevilling you, and which relies on local variables computed >> in a local chunk of code in that method, AspectJ has no eyes on it. >> You're not going to be logging this kind of thing with aspects. >> > I think you just saved me a fair bit of time ;-) I was curious to see > whether I could use aspects to do what I'll call diagnostic logging. I > have some methods that do "calculations" of one kind or another, like the > best width for a column in a JTable given the width of the values in each > column, and it would be neat if I could remove all of that logging code > from the method itself and put it in aspects. Then, when the method is > working 100% to my satisfaction, I can discard that aspect and leave the > method uncluttered. > > From what you're saying, I may not be able to capture the values of all > the variables that are being juggled in the suspect method. I had > wondered about that and was going to try it myself to see. I probably > still will but I'll be less surprised/disappointed if I can't access the > information I want. I'd recommend your own experimentation in any case. The available join points in AspectJ, as I mentioned before, do provide a lot of power, and it may well be that you can live with what they give you, for your own code. I'll point at something that I remember trying out a few years back, albeit maybe a different version, I dunno. You can find it at http://www.eclipse.org/aspectj/doc/released/faq.php#q:seeingjoinpoints Make the modifications as noted to run it on your code, and select your own entry point. The output XML will show all of the join points in detail that you could use "within" that entry point. >> Another big "but", maybe not so much a "but" rather a general >> consideration, is that if you start getting very fine-grained about >> pointcuts, you're sort of defeating the purpose of AOP. We're, I >> expect, considering a codebase that has no extensive logging, maybe >> none. If you are going to spend inordinate amounts of time tailoring >> pointcuts and advice for umpteen different types of logging, *you may >> as well bite the bullet and go into the code and directly use the >> logging framework*, rather than apply it through the agency of >> aspects. >> > Actually, I already have logging in place for most of classes and am > retrofitting it to the rest. I use the Java Logging classes, as opposed > to Log4j, but I'm not fanatical about it. I'm hearing more and more to > the effect that Log4j is better so maybe I'll make the switch. The better > I design my logging, the less painful that is going to be ;-) I've used java.util.logging (JUL) quite a lot, log4j considerably more. My main objection to JUL is that it is/was a lightweight framework. I always have had this suspicion that the Sun developers that wrote it got bored after designing the interfaces and skimped on the real implementation classes. log4j out of the box has considerably more options, and extras offer even more choices. >> In a nutshell, for logging, I myself have used AspectJ for emergency >> maintenance: the codebase in question has no logging, or what it has >> is useless, and there is limited time to add logging to source. So >> this is execution tracing logging. >> >> I hope this helps. >> > It does, Arved. Thanks! > > So what do you use aspects for, besides the occasional need to add > logging into poorly-logged classes? > Nothing. :-) I try to stay aware of AOP developments, just in case something comes up in the real world that could use it. As others have stated, AOP doesn't really figure for general application programming, it's more for infrastructure code like frameworks. From a software engineering standpoint, not restricting to AspectJ or even Java, aspect oriented programming and software engineering is not going away. Crosscutting concerns do exist and will always exist. We have barely scratched the surface of how to handle them. I like work that is being done (has been done) on Design by Contract in relation to aspects (aspect oriented design or AOD), and just as a few other examples I think there is serious potential for talking about security and transactionality from the cross-cutting perspective. But again this is more infrastructure oriented work and research. AHS -- -- Gaiety is the most outstanding feature of the Soviet Union. Josef Stalin, November 1935
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-25 18:18 -0500 |
| Message-ID | <4f496c36$0$283$14726298@news.sunsite.dk> |
| In reply to | #12325 |
On 2/25/2012 12:17 PM, Novice wrote: > Actually, I already have logging in place for most of classes and am > retrofitting it to the rest. I use the Java Logging classes, as opposed > to Log4j, but I'm not fanatical about it. I'm hearing more and more to > the effect that Log4j is better so maybe I'll make the switch. The better > I design my logging, the less painful that is going to be ;-) As a rule of thumb I would go for: SE => jul EE => log4j (based on sophistication needed and deployment context) Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-25 09:21 -0500 |
| Message-ID | <4f48ee64$0$289$14726298@news.sunsite.dk> |
| In reply to | #12310 |
On 2/25/2012 12:47 AM, Novice wrote: > Lew<noone@lewscanon.com> wrote in news:ji8u23$f6m$1@news.albasani.net: >> 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? Those things seems perfectly valid to do using AOP. Arne
[toc] | [prev] | [next] | [standalone]
| From | Roedy Green <see_website@mindprod.com.invalid> |
|---|---|
| Date | 2012-02-25 14:35 -0800 |
| Message-ID | <9umik7lk9nnkgc5dddkg5js0v43hajl7ef@4ax.com> |
| In reply to | #12310 |
On Sat, 25 Feb 2012 05:47:39 +0000 (UTC), Novice <novice@example..com> wrote, quoted or indirectly quoted someone who said : >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.... see http://mindprod.com/jgloss/newsgroups.html for the possibilities and some hints on dealing with the denizens. -- Roedy Green Canadian Mind Products http://mindprod.com One of the most useful comments you can put in a program is "If you change this, remember to change ?XXX? too".
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2012-02-24 14:30 -0800 |
| Message-ID | <ji931u$34e$1@dont-email.me> |
| In reply to | #12296 |
On 2/24/2012 12:10 PM, Novice wrote: > 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.... I'm not an expert on Aspects or CDI, but I feel that AoP has largely been replaced in the Java world by CDI (Context and Dependency Injection). Which is perhaps why you haven't seen much discussion of AoP. AoP is probably important in some fields of research and with other languages, or with specialized systems. But most of us here are generalists, and AoP doesn't seem to be used much, if at all, in general Java programming.
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web