You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Joerg Hohwiller <jo...@j-hohwiller.de> on 2005/10/01 02:07:56 UTC
[logging] getChildLogger Patch submitted to bugzilla issue #36062
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
it all works and all tests passed.
I submitted the full patch at
http://issues.apache.org/bugzilla/show_bug.cgi?id=36062
Discussion is most welcome.
Regards
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDPdNcmPuec2Dcv/8RAtpZAJ4jci6XfPnu53Z9VIq+KBESNiyJTQCeNv8R
chNPKn61u+XTk2yhFs2Ic7g=
=cTcE
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] getChildLogger Patch submitted to bugzilla
issue #36062
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-10-09 at 21:31 +0200, Joerg Hohwiller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> robert burrell donkin wrote:
> > On Sat, 2005-10-01 at 02:52 +0200, Joerg Hohwiller wrote:
> >
> >>-----BEGIN PGP SIGNED MESSAGE-----
> >>Hash: SHA1
> >>
> >>Joerg Hohwiller wrote:
> >>
> >>>Hi there,
> >>>
> >>>it all works and all tests passed.
> >>>I submitted the full patch at
> >>>http://issues.apache.org/bugzilla/show_bug.cgi?id=36062
> >>>
> >>>Discussion is most welcome.
> >>
> >>First issue: I suggested to have non-arg constructors for each Logger
> >>implementation that create a "root-logger" (logger with empty name).
> >>This is not yet included (in the patch). I think this would be an
> >>additional issue towards IoC because the container could use that constructor
> >>instead of the LogFactory or the String constructor and from that point work
> >>with getChildLogger from the Logger interface without casting.
> >
> >
> > note that there are a few log implementations (in particular
> > AvalonLogger) which cannot logically support this. sounds like a
> > reasonable additional for those loggers which can logically support it.
> The loggers that can not logically support this (AvalonLogger, but what else?)
> are a bride to another meta-logger.
IIRC just avalon
> So the answer from the IoC point of view:
> A component requires a logger and for using the logger it is bound against
> a specific interface. The IoC container will provide a logger implementation for
> this interface and injects it into the component. It will make no sense to
> use another meta-logger as JCL implementation if you are in IoC and have the
> freedom of choice.
> If I understand it right, the only reason for such things as "AvalonLogger" are
> if you have Avanlon as IoC container but want to use a library in a
> avalon-component that wants to have a JCL logger.
> The AvalonLogger has to be statically initialized anyways to be used properly
> with JCL which is sick.
depends on the usage pattern. Log instances don't have to be created as
constants each class, it's just the most common idiom. for AvalonLogger
to be of much use, i'd say that the component would need to support
setting the Log instance on a per-class basis.
> So the short resumee: does not matter for me.
good
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] getChildLogger Patch submitted to bugzilla issue #36062
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
robert burrell donkin wrote:
> On Sat, 2005-10-01 at 02:52 +0200, Joerg Hohwiller wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Joerg Hohwiller wrote:
>>
>>>Hi there,
>>>
>>>it all works and all tests passed.
>>>I submitted the full patch at
>>>http://issues.apache.org/bugzilla/show_bug.cgi?id=36062
>>>
>>>Discussion is most welcome.
>>
>>First issue: I suggested to have non-arg constructors for each Logger
>>implementation that create a "root-logger" (logger with empty name).
>>This is not yet included (in the patch). I think this would be an
>>additional issue towards IoC because the container could use that constructor
>>instead of the LogFactory or the String constructor and from that point work
>>with getChildLogger from the Logger interface without casting.
>
>
> note that there are a few log implementations (in particular
> AvalonLogger) which cannot logically support this. sounds like a
> reasonable additional for those loggers which can logically support it.
The loggers that can not logically support this (AvalonLogger, but what else?)
are a bride to another meta-logger.
So the answer from the IoC point of view:
A component requires a logger and for using the logger it is bound against
a specific interface. The IoC container will provide a logger implementation for
this interface and injects it into the component. It will make no sense to
use another meta-logger as JCL implementation if you are in IoC and have the
freedom of choice.
If I understand it right, the only reason for such things as "AvalonLogger" are
if you have Avanlon as IoC container but want to use a library in a
avalon-component that wants to have a JCL logger.
The AvalonLogger has to be statically initialized anyways to be used properly
with JCL which is sick.
So the short resumee: does not matter for me.
>
> - robert
Regards
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDSXAOmPuec2Dcv/8RArGWAJ9AN3ugtSoDvDkHkcyqQ1aw2+grcACfXk03
1ZDDfXGajqVephY/0Vi6O/w=
=nFg+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] getChildLogger Patch submitted to bugzilla issue
#36062
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2005-10-01 at 02:52 +0200, Joerg Hohwiller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Joerg Hohwiller wrote:
> > Hi there,
> >
> > it all works and all tests passed.
> > I submitted the full patch at
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=36062
> >
> > Discussion is most welcome.
> First issue: I suggested to have non-arg constructors for each Logger
> implementation that create a "root-logger" (logger with empty name).
> This is not yet included (in the patch). I think this would be an
> additional issue towards IoC because the container could use that constructor
> instead of the LogFactory or the String constructor and from that point work
> with getChildLogger from the Logger interface without casting.
note that there are a few log implementations (in particular
AvalonLogger) which cannot logically support this. sounds like a
reasonable additional for those loggers which can logically support it.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] getChildLogger Patch submitted to bugzilla issue #36062
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joerg Hohwiller wrote:
> Hi there,
>
> it all works and all tests passed.
> I submitted the full patch at
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36062
>
> Discussion is most welcome.
First issue: I suggested to have non-arg constructors for each Logger
implementation that create a "root-logger" (logger with empty name).
This is not yet included (in the patch). I think this would be an
additional issue towards IoC because the container could use that constructor
instead of the LogFactory or the String constructor and from that point work
with getChildLogger from the Logger interface without casting.
>
> Regards
> Jörg
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDPd3HmPuec2Dcv/8RAsLIAJ9mm9bqEyqswYaTXYisdoWm+HU9yACePCSu
q/Ch6k6A6n9aUUczxN3A+9o=
=Lpl2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] getChildLogger Patch submitted to
bugzilla issue #36062
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2005-10-11 at 23:16 +0200, Joerg Hohwiller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> robert burrell donkin wrote:
> > On Sun, 2005-10-09 at 21:20 +0200, Joerg Hohwiller wrote:
> >
> >>-----BEGIN PGP SIGNED MESSAGE-----
<snip>
> >>>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.
> >
> >
> > not sure i understand this correctly. so long as Logger is an interface,
> > methods cannot be added without breaking compatibility. in order to be
> > able to add new methods, the Logger logical interface would need to be
> > implementated as an abstract class.
> You are right with what you are saying. To make it clear what I meant.
> If someone is directly implementing the Logger interface and not extending
> AbstractLogger even though suggested, he will have no guarantee for
> compatibility. I do not know if this is acceptable. As I pointed out,
> the big issue for me is, if one day guys from log4j or whatever decide to
> directly implement the JCL API.
> But the suggestion in javadoc is at least reducing the harm about compatibility
> while not giving up the flexibility of an interface.
i think that there are two different issues here.
i agree that the proposal satisfies implementation compatibility. (in
other words, it's not unreasonable to ask a Log implementor to extend
AbstractLogger.) however, this group is tiny constituency. my main
concern is for JCL users.
once an interface is published, it cannot be changed without breaking
backwards compatibility. if Logger changes then every bit of code that
uses that interface must be recompiled.
for an application, this isn't a major problem. for a shallow library
(typically used directly by applications) this is an issue but such a
huge one. but for a deep library used by libraries, breaking backwards
compatibility is a very major issue since every version of every library
would need recompiling to be compatible.
IMO JCL is now so widely used that braking compatibility is unthinkable.
so it must be assumed that any new interfaces are immutable.
it is therefore usual for deep libraries to prefer to model logical
interfaces as abstract classes: trading flexibility for compatibility.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] getChildLogger Patch submitted to bugzilla issue #36062
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
robert burrell donkin wrote:
> On Sun, 2005-10-09 at 21:20 +0200, Joerg Hohwiller wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Hi,
>>
>>robert burrell donkin wrote:
>
>
> <snip>
>
>
>>>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.
>
>
> good enough for me :)
>
>
>>>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.
>
>
> that'd be the way to proceed
>
>
>>But anyways someone has to do the list-crawling.
>
>
> to ship another release someone's going to have to go through the
> bugzilla's in any case.
When we have cleared how to proceed at all, I will help out - not saying that I
will do the hole thing :)
>
>
>>>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 see :)
>
>
>>So I just added some sort of "bugfix" to my patch.
>
>
> releases need to be compiled against 1.2.6 but the maven build will need
> to run against 1.2.12 for now. i'll fix this sometime soon and add some
> notes into the comments section for that dependency.
Actually, as I told before, for maven we would need to create a subproject
for each bridge implementation to have it right. Then we could also do the tests
properly with maven. BUT this would be ugly for maintainence and by default
would create a jar for each bridge (commons-logging-log4j12.jar, ...).
I will raise this issue on maven-dev for m2, because it is even not targeted
with m2.
>
>
>>>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.
>
>
> i agree in general terms but JCL is used in a wide variety of JVMs so
> it's best to code these things in. not a big issue, though.
Okay. I will update this in my local code. Anyways I have to supply a new patch
sooner or later.
>
>
>>>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.
>
>
> not sure i understand this correctly. so long as Logger is an interface,
> methods cannot be added without breaking compatibility. in order to be
> able to add new methods, the Logger logical interface would need to be
> implementated as an abstract class.
You are right with what you are saying. To make it clear what I meant.
If someone is directly implementing the Logger interface and not extending
AbstractLogger even though suggested, he will have no guarantee for
compatibility. I do not know if this is acceptable. As I pointed out,
the big issue for me is, if one day guys from log4j or whatever decide to
directly implement the JCL API.
But the suggestion in javadoc is at least reducing the harm about compatibility
while not giving up the flexibility of an interface.
Maybe we can prevent all this if we look for the issues on the list and in
bugzilla before we release this Logger thingy.
I have found the indirect proposal for generic access to "log" and "is*Enabled"
methods via a typesafe enum (NOT a JDK 5.0 enum to make this clear).
Actually I like this idea.
But while for the "is*Enabled" method this is peanuts, for a generic "log"
method implemented in the AbstractLogger
(or vice versa: implementing all methods "trace", "debug", ...) this will
increase the level of indirection. I am not worrying too much about performance,
more about the way the logger gets the actual caller-method from the stack-trace
(you now these output "[MyClass.myMethod][DEBUG]Hello World").
BTW: the "vice versa" could at least make it be on a constant level - just one
level higher than now. Anyways I am sure there are also guyz on this list who
bleed for performance and would not like that to happen. Please confirm this for
me guyz.
So in this case we could only live with a "log" method that directs to the
existing logging methods causing the trouble of different stracktrace levels.
Can someone give me a hint if this would be hard to solve.
Or is everybody saying "this proposal should go to hell right away" :)
>
> - robert
Take care
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDTCu7mPuec2Dcv/8RAmcZAJ9cBRg/c41zb2yem5RGNUMpdlrTfwCfbcmO
sRcGjdY1z700tV4jMjnpXWw=
=uiH0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] getChildLogger Patch submitted to bugzilla
issue #36062
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-10-09 at 21:20 +0200, Joerg Hohwiller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> robert burrell donkin wrote:
<snip>
> > 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.
good enough for me :)
> > 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.
that'd be the way to proceed
> But anyways someone has to do the list-crawling.
to ship another release someone's going to have to go through the
bugzilla's in any case.
> > 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 see :)
> So I just added some sort of "bugfix" to my patch.
releases need to be compiled against 1.2.6 but the maven build will need
to run against 1.2.12 for now. i'll fix this sometime soon and add some
notes into the comments section for that dependency.
> > 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.
i agree in general terms but JCL is used in a wide variety of JVMs so
it's best to code these things in. not a big issue, though.
> > 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.
not sure i understand this correctly. so long as Logger is an interface,
methods cannot be added without breaking compatibility. in order to be
able to add new methods, the Logger logical interface would need to be
implementated as an abstract class.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] getChildLogger Patch submitted to bugzilla issue #36062
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] getChildLogger Patch submitted to bugzilla issue
#36062
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2005-10-01 at 02:07 +0200, Joerg Hohwiller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi there,
>
> it all works and all tests passed.
> I submitted the full patch at
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36062
>
> Discussion is most welcome.
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?
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.
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.
4 not happy about upgrading the log4j dependency at the same time.
5 should use a string buffer in getChildLoggerName.
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.
opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org