Re: [jira] Commented: (LOG4PHP-108) Add HTML line break to LoggerAppenderEcho output

[Ivan Habunek <iv...@gmail.com>]

Hi everybody. Remember this thread? X)

Well, I'm back on this problem once again. So far it has been proposed
that a long term solution would be either:

a) to stop using LoggerAppenderPool
Personally I think we could do without it, in fact my rewrite of the
XML configurator does not use an appender pool at all. I believe the
same could be achieved for other configurators easily.

b) make LoggerAppenderPool non-static, and instantiate it by the configurators
This will work as well, but I think it's not the most elegant solution.

Now, obviously my vote is for a. Do you have any preferences?

As a quick-fix, I will implement clearing of the LoggerAppenderPool in
LoggerHierarchy::resetConfiguration(). This soulution will do until we
agree on a more permanent solution.

Regards,
Ivan


On 4 May 2010 08:39, Ivan Habunek <iv...@gmail.com> wrote:
> On 4.5.2010 7:03, Christian Grobmeier wrote:
>>
>> It still works for me. But the running order might be different on
>> different os. I heard from some other guy who has this failure.
>
> It is definitely a problem related to the order in which the tests run. As a
> matter of interest, which OS are you using? I tested on WinXP and Debian.
>
>> First, LoggerAppenderPool is only used by Configurators, I think we
>> should move it in this package and not on leave it in the root
>> package.
>>
>> Second, I don't see that LoggerAppenderPool needs to be statically
>> available. If we create a new LoggerAppenderPool object in each
>> configurators constructor and use the object then this should be
>> solved without any additional reset calls or clear methods.
>>
>> What do you think?
>
> I've been working on the XML configurator and, frankly, I don't see the need
> for LoggerAppenderPool at all, at least not in the way it is currently used.
> As you said, it is only used by the configurator classes, and if this is the
> only place it is meant to be used, then it can easily be replaced by a
> private variable within the configurator class.
>
> Maybe I missed something? Otherwise, your ideas look OK. :)
>
> Regards,
> Ivan
>
>
>