You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2005/10/01 14:21:37 UTC
Twisted maze of loggers, all alike..
I was trying to wrap my brain around the current log code, following a
possible null pointer dereference in LogManager and found a twisted
little maze of code...
Nathan, as this is your baby, do you object to some of the following
changes:
- Nuke the public C'tor for Log(). Do we want anyone walk around and
create new Log instances? Add a LogManager.getLog() method which returns
a Log object.
- Make LogManager.createLogChute() private. This should _only_ be called
from LogManager.updateLog()
- Make HoldingLogChute() package private. Even better, make it a private
static inner class of LogManager. We never ever want users to use that
directly. It is a vehicle intended for pre-init logging.
- rename HoldingLogChute() to PreInitLogChute()
- rename LogChuteSystem() to LogSystemLogChute() :-)
Some bike shed painting here, I admit.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Twisted maze of loggers, all alike..
Posted by Nathan Bubna <nb...@gmail.com>.
On 10/1/05, Henning P. Schmiedehausen <hp...@intermeta.de> wrote:
> I was trying to wrap my brain around the current log code, following a
> possible null pointer dereference in LogManager and found a twisted
> little maze of code...
>
> Nathan, as this is your baby, do you object to some of the following
> changes:
>
> - Nuke the public C'tor for Log(). Do we want anyone walk around and
> create new Log instances? Add a LogManager.getLog() method which returns
> a Log object.
hmm. i'm actually not a big fan of this. it doesn't really solve the
problem. because then there are two getLog() methods (one in
LogManager and one in RuntimeServices/Instance). "anyone" might just
as easily get an unofficial Log instance from LogManager.getLog() as
creating it themselves, with the potential extra problem that they'd
think it was legit because the LogManager gave it to them. if they
create a new one themselves, then they at least shouldn't have any
expectation that it would do anything.
so -1 is my vote on this.
> - Make LogManager.createLogChute() private. This should _only_ be called
> from LogManager.updateLog()
+1 i should have done that. i just forgot.
> - Make HoldingLogChute() package private. Even better, make it a private
> static inner class of LogManager. We never ever want users to use that
> directly. It is a vehicle intended for pre-init logging.
interesting. i hadn't thought of making it package private because i
was just re-implementing the PrimordialLogSystem. but it makes good
sense. +1
as for making it a static inner class of LogManager... -1 (because
that makes less sense given my -1 above)
> - rename HoldingLogChute() to PreInitLogChute()
-0 (i slightly prefer names that speak to function over those that
refer to time of use, but it's not a big deal to me)
> - rename LogChuteSystem() to LogSystemLogChute() :-)
+0 (this is a deprecated hack class. what do i care? ;-) )
> Some bike shed painting here, I admit.
:)
> Best regards
> Henning
>
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> 4 - 8 - 15 - 16 - 23 - 42
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org