This one!! :
| Attempt III ----------------------------------------------------------
|
| public class Logger {
|
|
| /**
| @deprecated Category class is deprecated.
| Please use the {link #getLogger} instead
If you are maintaining code for a older project
where Category is used a lot, it might make more
sense to keep with that.
and maybe not deprecate it yet either.. For a couple of versions, at
least..
| */
| public
| static
| Category getInstance(String name) {
| // returns a Category object
| }
|
| public
| static
| Logger getLogger(String name) {
| // do we return a Category object or a Logger object?
Logger, definately!
| }
|
|
| public
| void debug(Object o) {
| ...
| }
| }
|
|
| public Category extends Logger {
| // empty class
| }
|
| The getLogger method offers a migration path from Category to Logger.
Totally agree!
| would throw a ClassCastException at runtime. In other words, the user
| would be more aggressively pushed to migrate. (I favor this later
| alternative.)
Still totally agree!
|
| There are many remaining problems:
|
| Runtime inconsistencies
| =======================
|
| If the client mixes Logger.getLogger and CategorygetInstance method we
| might get into hairy situations. Example:
Why would he mix? Either it's kind of actively developing, where you
probably would migrate the whole thing, and thus only use Logger, or you'd
still use Category (because the javadoc told you about this "phenomena",
where if your old code uses Category, then still use it.)
|
| Logger logger = Logger.getLogger("foo.bar");
|
| at a later time
|
| Category cat = Category.getInstance("foo.bar");
|
| The second line would throw a ClassCastException at runtime.
This one is a rather good point, but
1) How often would this really occur? Common pratice, at least after what
I read of your doc back then, is to use class names. Then you'd have one
category pr. class.
2) Couldn't you get around this one by using some kind of "converting
mechanism" in both getLogger() and getInstance() (these are not required
to be that extremely fast, because you do it only once pr. class (or
whatever) ?), where you knew that the foo.bar logger was instantiated as a
Logger, and therefore had to instantiate another foo.bar of class
Category? Kind of having two trees, maybe, but where those two trees are
coupled very tight together??
|
| Documentation inconsistencies
| =============================
|
| Documentation would need to be updated.
Hmm.. This is not a very good point, though! ;)
|
| Configuration language
| ======================
|
| The configuration language would need to be changed while keeping backward
| compatibility.
Both could exist?
|
| CVS inconsistencies
| ===================
|
| If we check in a intermediary version of the code that does not
| compile or that breaks backward incompatibility, then jakarta-GUMP
| would detect this and jakarta-projects relying on log4j would not
| build under GUMP. This situation could become intolerable if log4j
| could not be fixed within a few days and I am not entirely sure we
| could guarantee a quick fix.
This is also not the biggest point I've heard of why not doing something.
Should one never "go ahead" with anything because something else would not
compile for a couple of days?! What about a slight little fork-off, or
whatever that stuff is called (branching!)? Couldn't you get these
projects to compile then?
| My message is that renaming Category to Logger is a lot more
| complicated than what one would think at first. I am not saying that
| we should not do it, I am just saying that the change has to be
| planned with care.
I think that aligning towards the logging API from Sun will be very
valueable.. This is actually my biggest point here, I don't care if this
classname is a bit weird..! The package works very good, and you can, if
you really want and have the time to do it, explain why it has this
strange name to your new developers.. ("Just bleedin' accept it, and don't
ask more questions about it!" ;-)
--
Mvh,
Endre
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
