Menu
▾
▴
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?=
|
From: Rolf S. <rs...@pl...> - 2006-11-29 09:41:49
|
Hi,=20 Am Mittwoch 29 November 2006 07:26 schrieb Mike Schilli: > 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 be= st > > 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: Yes! > > http://wiki.apache.org/logging-log4j/AppContainerLogging Yes, looks like the same problem. > > which I think we need to address soon in Log4perl. I agree. > > 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. I would'nt call it name conflicts. My situation looks like the following: I have several applications running on the same machine. All apps are more = or=20 less custom specific variations, they even use the same database and of=20 course the same perl modules. The differences between my apps is =20 maintained by a single MyApp/<Site>/Param.pm file, which holds filenames,= =20 database connections, etc. Each VirtualHost has its own setup in http.conf= =20 and has its own mod_perl (MasonX::WebApp) handler. This handler initializes= =20 an "application object which is a subclass from Apache::Singleton::Request= =20 by passing the name of the site to the instance-method. In the next step=20 Log4perl is "init()"ed , the name for the .conf file is recieved from the=20 application object which gets from the Param.pm.=20 Earlier i tried to setup Log4perl with init_once in the mod_perl handler in= it=20 phase during apache startup, since all the information I need is known at=20 that time. Yet, as you write, since the loggers are kept in a global=20 namespace all logs where written to the logfiles of the first handler calli= ng=20 init_once.=20 There are no error messages or that, it just doesn't do what I would like = it=20 to do. The solution would be to allow passing a namespace-parameter to the init_on= ce=20 method and make get_logger find the right namespace. I have some similar problems with Locale::Maketext which just uses caller()= to=20 get the callers namespace and inserts it's data to that namespace. Yet, my= =20 app uses a common module to make that initialisation and thus the namespace= =20 would be identical for all callers. I have : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D package MyApp::I18N; sub do_init { # do Locale::Maketet::Lexion setup here L::M::L->setup (...) ..} 1; MyApp::<Site:>::I18N; use base MyApp::I18N; 1; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Now when I call MyApp::<Site>::I18N->do_init in L::M::L::setup caller() gives you MyApp::I18N=20 (which I would consider as a perl bug) So I had to copy (!) the do_init method to each subclass and call=20 L::M::L-> setup from there. I think the name_space problem with mod_perl is something general and proba= bly=20 should be solved there. Using an individual perl instance for each VirtHost= =20 has the big disadvantage, that my apaches processes become very very fat an= d=20 I have no benefit in saving memory by preloading all my needed modules.=20 So a "use namspace 'MyNamespace" would be fine, but that's just a "wish", = not=20 a solution I've been thinking about in depth :-) > > -- 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 =3D AppX::Log4Perl->instance(); > > > > > > > > $l4p->init_once('appx.conf'); > > > > > > > > my $logger =3D $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 =3D $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 b= ut > > > > 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 =3D shift; > > > > > > > > my $self =3D 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. > > > > > > ---------------------------------------------------------------------= =2D- > > >-- Take Surveys. Earn Cash. Influence the Future of IT > > > Join SourceForge.net's Techsay panel and you'll get the chance to sha= re > > > your opinions on IT & business topics through brief surveys - and earn > > > cash > > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CI= D=3DDEVD > > >EV _______________________________________________ > > > log4perl-devel mailing list > > > log...@li... > > > https://lists.sourceforge.net/lists/listinfo/log4perl-devel > > > > -- > > Rolf Schaufelberger > > rs...@pl... > > > > > > -----------------------------------------------------------------------= =2D- > > 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=3Djoin.php&p=3Dsourceforge&CID= =3DDEVDEV > > _______________________________________________ > > log4perl-devel mailing list > > log...@li... > > https://lists.sourceforge.net/lists/listinfo/log4perl-devel =2D-=20 Mit freundlichen Gr=FC=DFen Rolf Schaufelberger plusW Rolf Schaufelberger=20 Beim Br=FCnnele 6 Tel. 49 7181 994 35 50 73614 Schorndorf Fax. 49 7181 994 32 75 rs...@pl... |
