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

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

On Mon, 27 Nov 2006, Craig Manley wrote:

> Yes, init_once() calls init() which sets the global
> $Log::Log4perl::Logger::INITIALIZED unless it's been set already. In
> mod_perl multiple applications/handlers can run in the same httpd child
> (of course not at the same time), but that means the configuration of
> the first handler that called init_once() will be the configuration that
> will persist through all other handlers called in the future in that
> same httpd child.

Correct. Looks like we need multiple logger repositories:

    http://wiki.apache.org/logging-log4j/AppContainerLogging

I'll look into your suggestion of using Class::Singleton, this
could significantly reduce the work to get rid of these nasty globals
and provide backwards compatibility for those who don't want to
deal with subclassing.

If you have more implementation ideas or (even better!) patches,
please keep'em coming :)

Thanks,

-- Mike

Mike Schilli
m...@pe...

> Side note: Depending on the mod_perl version and configuration, a single
> Perl interpreter instance is shared for every virtual host in a httpd
> child, or each virtual host can get it's own Perl interpreter instance.
> Anyhow in the best of cases, more Perl handlers/apps run can run in the
> same virtual host and share the same Perl interpreter instance and
> therefore all it's loaded modules and globals. Global variables are
> really nasty in such environments and there are more Perl modules that
> use them causing mod_perl programmers to have to localize the globals in
> those modules in order to prevent conflicts with other mod_perl apps.
>
>
> > 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?
>
> Not exactly. There is a separate singleton instance for each child of
> Class::Singleton (and thank goodness for that otherwise that class would
> be quiet useless in practice), so if AppX::Log4Perl and AppY::Log4Perl
> both descend from Class::Singleton, then a separate singleton instance
> will exist for both of these child classes.
>
>
> > 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.
>
> Well you can roughly compare it to one of the existing frameworks such
> as Catalyst etc. I just need a flexible logging system to plug into it
> that doesn't have any known flaws that could get any future users of it
> stuck with weird problems.
>
> -Craig Manley
>
>
> >
> > -- 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.
> > >
> > >
> > --
> > Deze email is gecontroleerd door CAIWAY Internet Virusvrij.
> > Voor meer informatie, zie http://www.caiway.nl/
>