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

[Rolf S. <rs...@pl...>]

Hi, 

Am Montag 27 November 2006 16:31 schrieb Mike Schilli:
> 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'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. 
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...