-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
robert burrell donkin wrote:
>
> 1 IMHO Logger is used far too often already. i'd prefer another name. i
> don't think that IoCLog is not commonly used so that's a possibility.
> not sure whether that'd be a good or bad name. Log2 is used often used
> in this circumstance. LogPlus is unique and novel.
>
> opinions?
I think Logger is a very apropriate name. The reason that it is used
quite often is that this is excatly the right name for such an interface.
Aint this why we have namespaces in Java?
If it is not acceptable for the majority, I could live with something like
"IoCLog".
>
> 2 for me, the documentation for this would be critical. i'd like to have
> a firm commitment for good documentation to be produce to go with this
> patch.
I am very willing to produce documentation for this issue. But this proposal was
asked at least 2 times before on this list and then died. If I get the feeling
that my issue will not be dropped later, I will "invest" more time. But still
I do not have a clue if my patch is acceptable.
>
> 3 should probably go through the old bugzilla reports and see whether
> there are any other bits and pieces which are missing from Log and
> should be added to log2.
My intention always was to focus on the "getChildLogger" method and not to
overload the issue. In the end the hole thing might be dropped because another
feature was added but caused a controverse discussion.
But I agree that this would be a good idea. Maybe we could vote for each
different issues that will arise. But anyways someone has to do the
list-crawling.
>
> 4 not happy about upgrading the log4j dependency at the same time.
The current code in SVN does not compile with an older log4j. So
I just added some sort of "bugfix" to my patch.
> 5 should use a string buffer in getChildLoggerName.
Okay, I was thinking about this... but since only one string construction takes
place, this is happening anyways: the compiler will do this for you.
>
> 6 bit unsure about fitting a superclass (AbstractLogger) just to provide
> a utility method. sometimes this can prove harmful in the long run since
> it may limit inheritance options for the future. can't think of any
> reason why this would apply in this case right now, though.
The reason is NOT just to provide a utility method. It is to have the ability to
add a method to the "Logger" interface later without breaking compatibility.
The javadoc would then say that you should never directly implement
the "Logger" interface but always extend "AbstractLogger" (it currently does
not).
But you are right with the "single-inheritance-problem" of JAVA.
For me this is no issue if the implementation is just a facade to a native
logger. But if we could convince a native logger library ('s community) to
directly implement "our" "Logger" interface. They might not like to extend
the AbstractLogger class for arbitrary reasons.
>
> opinions?
read above...
>
> - robert
Regards
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDSW16mPuec2Dcv/8RAseVAJ0UFYFcZYFRq3sA4hMlLTfFF7kx3ACgmURr
nxK+Pyk5upNOSqO1Rr4HzFY=
=jsZ+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
