Re: [log4perl-devel] =?iso-8859-1?q?Design_question=3A_Why_doesn=27t_?= =?iso-8859-1?q?Log=3A=3ALog4Perl_descend=09from_Class=3A=3ASingleton=3F?=

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

On Mon, 27 Nov 2006, Rolf Schaufelberger wrote:

> I'm having this situation too and got problems when i tried to use init_once.
> The problem may arise by the fact,  that  all of my VirtualHosts have a quite
> similar setup, just the  filenames for the lofiles are different, the names
> for the loggers themself are the same since they use the same librarys and
> most logger names are derived from the library names and the root_loggers
> name is identical. So  I have to call init() with every request, which may be
> not the best choice for best performance.

Right.

In the current implementation, regardless if you call init() or init_once(),
there's only *one* configuration. The difference is just that init() will
overwrite a previous configuration, while init_once() will ignore subsequent
calls to init_once().

Looks like what you need is support for multiple logger repositories:

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

which I think we need to address soon in Log4perl.

But just for the sake of my understanding ... can you please explain the
name conflicts in more detail? Some example code and warning/error message
would be great.

-- Mike

Mike Schilli
m...@pe...

> Yet i use Class:Singleton too in my apps, but setup as subclass
> Apache::Singleton::Request, and so  using it would make no difference at all.
> I can't use Apache::Singleon::Process  because some other modules are using
> caller() to stick some functionality to the callers namespace which doesn't
> work for me properly.
>
> But as you told that you have running several Virt.Hosts and ARE using
> init_once, how do you avoid naming conflicts ? is it sufficient just to give
> the root logger another name ?
>
> >
> > > 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.
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > log4perl-devel mailing list
> > log...@li...
> > https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>
> --
> Rolf Schaufelberger
> rs...@pl...
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>