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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi Rolf,

> -----Original Message-----
> From: log...@li... =
[mailto:log4perl-devel-
> bo...@li...] On Behalf Of Rolf Schaufelberger
> Sent: Wednesday, November 29, 2006 10:42 AM
> To: Mike Schilli
> Cc: log...@li...
> Subject: Re: [log4perl-devel]Design question: Why doesn't =
Log::Log4Perl descend from
> Class::Singleton?
>=20
> 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 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:
> 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.
>=20
> 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
> less custom specific variations, they even use the same database and =
of
> course the same  perl modules. The  differences between my apps is
> maintained by a single  MyApp/<Site>/Param.pm file, which holds =
filenames,
> database connections, etc.  Each VirtualHost has its own setup in =
http.conf
> and has its own mod_perl (MasonX::WebApp) handler. This handler =
initializes
> an "application object which is a subclass  from =
Apache::Singleton::Request
> by passing the name of the site to the instance-method.  In the next =
step
> Log4perl is "init()"ed , the name for the .conf file is recieved from =
the
> application object which gets from the Param.pm.
> Earlier i tried to setup Log4perl with init_once in the mod_perl =
handler init
> phase during apache startup, since all the information I need is known =
at
> that time. Yet, as you write, since the loggers are kept in a global
> namespace all logs where written to the logfiles of the first handler =
calling
> init_once.
> There are no error messages or that, it just doesn't  do what I would =
like it
> to do.
>=20
> The solution would be to allow passing a namespace-parameter to the =
init_once
> method and make get_logger find the right namespace.
>=20
> I have some similar problems with Locale::Maketext which just uses =
caller() to
> get the callers namespace and inserts it's data to that namespace. =
Yet, my
> app uses a common module to make that initialisation and thus the =
namespace
> 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;
>=20
> 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
> (which I would consider as a perl bug)
> So I had to copy (!) the do_init method to each subclass and call
> L::M::L-> setup from there.

That shouldn't be a problem at all using the singleton class approach =
because there's nothing stopping you from passing class names around =
instead of initialization namespace strings in your example. Effectively =
it comes down to the same thing there. I think it's a matter of taste if =
the designers prefer to use classes to distinguish between Log::Log4Perl =
instances or to use strings (passed to init() or init_once()) and =
internal global hashes to store what's now global. The result is the =
same, but personally I prefer the first approach because:
	1. an app won't compile if it uses the wrong class name, whereas when =
using strings it will, and it will run making typos harder to find.
	2. more legible design (but that's really just a matter of taste).
Using optional strings defining the namespace (passed to init() or =
init_once()) on the other hand will make it all more backwards =
compatible in usage.

=20
> I think the name_space problem with mod_perl is something general and =
probably
> should be solved there. Using an individual perl instance for each =
VirtHost
> has the big disadvantage, that my apaches processes become very very =
fat and
> I have no benefit in saving memory by preloading all my needed =
modules.
> So a "use namspace 'MyNamespace" would be fine, but  that's just a =
"wish", not
> a solution I've been thinking about in depth :-)

Uhh I don't quiet get this. I think there is a misunderstanding because =
I didn't imply that it's a requirement to use an individual perl =
instance for each VirtHost or something like that... it's complete =
unrelated, so it's safe to forget about. Besides no matter which of the =
2 approaches is chosen to solve the globals problem, the memory =
consumption will be equivalent and quite minor, so that's not something =
to worry about either.

>=20
> >
> > -- 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 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 =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.
> > > >
> > > > =
-----------------------------------------------------------------------
> > > >-- 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=3D=
DEVD
> > > >EV _______________________________________________
> > > > 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=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> > > _______________________________________________
> > > log4perl-devel mailing list
> > > log...@li...
> > > https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>=20
> --
> Mit freundlichen Gr=FC=DFen
> Rolf Schaufelberger
>=20
>=20
> plusW
> Rolf Schaufelberger
> Beim Br=FCnnele 6        Tel. 49 7181 994 35 50
> 73614 Schorndorf       Fax. 49 7181 994 32 75
> rs...@pl...
>=20
>=20
> =
-------------------------------------------------------------------------=

> 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=3D=
DEVDEV
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
> --
> Deze email is gecontroleerd door CAIWAY Internet Virusvrij.
> Voor meer informatie, zie http://www.caiway.nl/

-Craig Manley