Re: [log4perl-devel] Design question: Why doesn't Log::Log4Perl descend from Class::Singleton?

[Mike S. <m...@pe...>]

On Thu, 23 Nov 2006, Craig Manley wrote:

> Looking at the Log::Log4Perl code and it's suitability to be used in an
> application framework I'm working on, I see that it can't be used
> (safely) in multiple applications running within the same mod_perl
> server. This is because even though these applications use there own
> module namespaces, they obviously will clash with each other when
> calling the init or init_once method.

Thanks for your suggestion.

But are you sure? I'm running mod_perl servers with several
applications in production, and the way to make it work is to
call either init() at Apache startup or init_once() per
application:

    http://log4perl.sourceforge.net/d/Log/Log4perl/FAQ.html#792b4

> I think a better design would be to make Log::Log4Perl descend from
> Class::Singleton, store all variables that are now globals in the
> instance, and let users optionally create subclassed versions of
> Log::Log4Perl in there own namespaces.

Interesting idea. However, I'm not sure how that would be different
than the situation we have now. Currently we insist that init() gets
called exactly once and the entire Log4perl configuration is set up
for all apps that will be running within a process.

We don't have a way to run several L4p universes within the same process
with their own configuration. That would be useful, but that wouldn't
work with Class::Singleton, which essentially shares one, right?

Maybe you could send more details about the application framework
you're working on, I'd be interested to see how we can make Log4perl
fit its requirements.

-- Mike

Mike Schilli
m...@pe...

> E.g. you'ld get something like this:
>
>
>
> package AppX;
>
> use AppX::Log4Perl; # descends from Log::Log4Perl
>
> ...
>
> my $l4p = AppX::Log4Perl->instance();
>
> $l4p->init_once('appx.conf');
>
> my $logger = $l4p->get_logger();
>
>
>
> .... then in another application sharing the same httpd:
>
> package AppY;
>
> use AppY::Log4Perl; # descends from Log::Log4Perl
>
> ...
>
> $l4p->init_once('appy.conf');
>
> my $logger = $l4p->get_logger();
>
>
>
>
>
> ... and AppX::Log4Perl will look like exactly like this:
>
>
>
> package AppX::Log4Perl;
>
> use strict;
>
> use base(Log::Log4Perl);
>
> 1;
>
> __END__
>
>
>
>
>
> I know it will be a major change to build this into Log::Log4Perl but I
> think it can be done while retaining backwards compatibility.
>
> All current class methods now can be automatically turned into both
> class and object methods at the same time like this:
>
> sub a_class_method {
>
>  my $proto = shift;
>
>  my $self = ref($proto)  ? $proto : $proto->instance();
>
>  }
>
> Actually the magic above can become more involved if necessary.
>
>
>
> Log::Log4Perl is a great piece of work.... I only miss that.
>
>
>
> In general when making packages, one must really scratch one's head a
> few times if deciding to use globals, because they are almost always
> unnecessary (except for constants) and a simple object or else
> Class::Singleton based alternative is almost always the solution.
>
>
>
> That's just my 2p.
>
>
>
> Regards,
>
> Craig Manley.
>
>