I don't think they were ever truly abstract. It just indicates that they are there as a default impl, which you can easily override if in need of something more. I agree with you that it's probably not the best name choice, it could be Base or really Default, but I think you should ping Adrian to explain you the real motivation behind the name. David M. Lloyd wrote:

The only problem is that names are meaningless unless they communicate something to someone besides the person assigning the name. Dimitris Andreadis wrote: -- Jason T. Greene JBoss, a division of Red Hat

Adrian Brock wrote: Then there should be no reason to instantiate it. The humpty dumpty argument is very weak. Following this argument, I could call every class StringXXX, since the code making up the class itself is a String. This, however, does not make it a good name. Names are completely meaningless if they do not convey a meaning to someone besides the author. That is unless you intend on being the only person to use it. -- Jason T. Greene JBoss, a division of Red Hat

On Wed, 2009-06-03 at 08:33 -0500, Jason T. Greene wrote: If you want a serious discussion then cool the ad-homeniem attacks. Frankly, I've got better things to do than worry about whether somebody can understand what a class does from its name without reading the javadoc or even the code (it is open source). The same goes for all the other "feeble" topics that have been drowning the dev-list recently. If I see another topic on logging I might even unsubscribe from the list. ;-) "Rearranging the deck chairs on the titanic" is a phrase that springs to mind. -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

On 06/04/2009 07:10 AM, Adrian Brock wrote: Figuring out what code does is useless without knowing what it's supposed to do. The Javadoc is a critical part of this, and frankly there isn't much on most of our codebase. That's pretty derisive, and I for one don't appreciate it. That reminds me... ;-) I'm not following your metaphor. What exactly is the titanic here? The AS? Does that make you William Pirrie? ;-) Seriously we all want to make things better here, and frankly we could really use your help, not your insults. - DML

On Thu, 2009-06-04 at 10:33 -0500, David M. Lloyd wrote: We'll we had that argument a long time ago and you ignored my advice. Its a more polite metaphor about priorities than the one about the toilet function and the wind. ;-) -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

On 06/04/2009 11:30 AM, Adrian Brock wrote: I think you'll find that you are incorrect, if you're referring to this thread: http://lists.jboss.org/pipermail/jboss-development/2007-December/011166.html I argued the following: 1) All popular logging APIs should be supported 2) Everyone should switch to JUL 3) App developers should be able to use whatever API they like without blowing things up or getting other unexpected results. I still stick by my #1 and #3, though I conceded #2 a rather long time ago (there are a lot of features present in other logging APIs that are missing in the j.u.l.Logger API, and my current opinion based on user feedback is that slf4j is least likely to introduce dependencies that aren't already present in a given project). As I recall, your response was: 1) Everyone should use jboss logger 2) We will always have to deal with many logging frameworks 3) JUL is broken and can never be used safely, period I still disagree with #1, but that's one of those things that nobody will ever really agree on. I agree totally with #2, and in fact that ties directly with my #1 and #3. I have since refuted your #3 by producing a JDK logmanager (with javadocs btw) that isn't broken, which allows us in 5.1.x to trap JUL messages and forward them into our log without risking performance/deadlock/memory leak/etc issues. I have since come to the conclusion that there are two separate arguments: what logging APIs to support, and what logging backend to use. The answer to the first is "all of them", and the answer to the second is "it doesn't matter, so long as it works". Thus it doesn't matter what logging APIs each project chooses to use because all the major APIs should be supported. So when working on the new logging POJO service, I've stuck to that philosophy. Since that time the vast majority of my posts on the topic of logging have gone unanswered. Do you have anything to add? If so, how about posting constructive criticism here: http://www.jboss.org/community/wiki/LoggingPOJOServiceRequirements So my question for you in this thread is, are we still in disagreement about something that is relevant here? - DML

On Thu, 2009-06-04 at 13:36 -0500, David M. Lloyd wrote: I've argued it so many times before, I've got nothing to add. I don't see why I should re-re-re-repeat my arguments just because you've asked for them again. Just re-read what I've already posted (including those before we had our previous argument about it). You didn't give them any credit last time, so I think posting them on the WIKI would just be a waste of time. SUMMARY (for those you don't know how or are too lazy to search the e-mail archives): If you want to make things more complicated, use a known broken api and therefore make things more brittle, that's your right. But it also makes it your responsiblity to support it when it almost certainly breaks things. A buggy or badly configured logging api, being pervasive, can cause lots of problem, something we've had to deal with in the past and that took lots of effort to get it into a stable state. Have fun trying achieve the same stablity with your recent experiment. -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx