log4perl-devel

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

[Craig M. <C.M...@of...>]

Hi,

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.=20

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.

E.g. you'ld get something like this:

=20

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();

=20

.... 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();

=20

=20

... and AppX::Log4Perl will look like exactly like this:

=20

package AppX::Log4Perl;

use strict;

use base(Log::Log4Perl);

1;

__END__

=20

=20

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.

=20

Log::Log4Perl is a great piece of work.... I only miss that.

=20

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.

=20

That's just my 2p.

=20

Regards,

Craig Manley.

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

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

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 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.
>
>

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...

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
>

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?=

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

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...