Re: Aspect questions?
On 02/26/2012 09:22 AM, Novice wrote:
Lew wrote:
Novice wrote:
Lew wrote:
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.
The sentence began with "You don't...". I fail to see what can be confusing
there. An appositive phrase doesn't invert the sense of the predicate.
Which leaves the question of how we got the miscommunication in the first
place, when I never suggested such a thing.
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.
"Seemed" foists the responsibility off. I didn't do the "seeming".
....
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.
I used the term in the exact same sense as the logging library documentation
and in computer programming generally.
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??
http://lmgtfy.com/?q=GIYF
....
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
Huh?
Have you read the Java tutorial?
<http://docs.oracle.com/javase/tutorial/java/package/index.html>
presumably have a package named com.novice.foo and the Bar project will
Don't presume; design. It is very possible that the "Foo" project will not
have a package 'com.novice.foo', if it has 'com.novice.foo.qux',
'com.novice.foo.bleh' and so on.
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");
No, it won't. First, you have completely ignored that I said "one logger per
class". How did you distort that into "one logger per package"? Second, you
don't design packages for the logger, you design loggers for the packages.
Have I got this so far?
Not yet.
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:
STOP!
I don't know how you make these leaps, and I am defeated as to how to advise
you not to. You go on for paragraphs about bad ideas that were never suggested
to you.
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?
Once again, I repeat, and you may recall the Javadoc quotes I provided
upthread on this matter, getting a logger with a particular name gets a
reference to that same-named logger. Already. Without additional complication
on your part. It's built in. You don't need to reinvent it. It already
happens. All you have to do is give the same name. You will already have
gotten the reference. You don't have to pass it anywhere. It's already there.
Read the Javadocs. Again. And again. And again. And again. Don't read what
isn't in there - read what it says. It says that if you give the 'getLogger()'
the same name, it will return a reference to the same logger.
Aside from that, I have no idea at all what you intend to say by, "so that
they write to the logger used by the instantiating class from Foo". What
precisely do you mean there?
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
READ THE TUTORIAL!
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.
It is better to group types into packages.
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.
Once again, as I stated upthread some time ago and others have reiterated, the
common practice (but by no means the only one) is one logger per class.
Loggers "inherit", so that gives some flexibility in how you do things.
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
What? You should only have one log, unless they use different libraries to log.
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?
Huh? again.
What you name the logger is not connected to where it logs. Where it logs is
determined by the configuration for that logger. Usually it'll write to the
same log as its parent. The best practice here is to make sense in the first
place. You ask a question about naming a logger, but cast it in turns of where
it logs. Apples and oranges, dude. Naming a logger doesn't change where it
logs. Read the logger documentation, please. All this information is in the
documentation.
The configuration determines where the log goes. No changes to logger names
are needed, just change the configuration file and restart.
We're starting to make the same points over and over again. It's frustrating
to provide you an answer and have you come back with the same question. Please
assimilate the answers already given.
To summarize the repeated points here:
- Configuration files usually suffice to configure logging. You rarely need to
programmatically configure logging, and should resist doing so. Otherwise you
defeat the point of changing logging strategy without having to rebuild.
- The logger name determines which logger instance you get. NOT, and I repeat,
*NOT* where it logs.
- Conventionally, and usually most usefully, loggers are named for the class
in which they are used. So the logger for 'com.lewscanon.example.Foo' would
come via 'getLogger(com.lewscanon.example.Foo.class.getName())'.
and emergingly,
- Packages are to organize your program irrespective of logging strategy.
Some of this is material in the basic tutorial, particular the info about
packages, and should be mastered first before, say, learning how to code a
for-each loop.
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.
Your commitment is duly noted and quite laudable.
But "starting" is still a long way from "hash ... the last bits out". So I
hope your patience is up to the task. You lack certain Java fundamentals.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg