Mailing List Archive

* Adam Witney <awitney@sgul.ac.uk> [2014-11-12 13:55]:
> I have Log4Perl controlling the logging in my Catalyst app, but
> I can't seem to get the debug information from the normal Catalyst
> startup (routing table, Loaded plugins etc) included into the Log4Perl
> output.
>
> Is it possible to log this output through Log4Perl?

Synchronicity:

http://techblog.babyl.ca/entry/catalystx-info

_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

> * Adam Witney <awitney@sgul.ac.uk> [2014-11-12 13:55]:
> > I have Log4Perl controlling the logging in my Catalyst app, but I
> > can't seem to get the debug information from the normal Catalyst
> > startup (routing table, Loaded plugins etc) included into the Log4Perl
> > output.
> >
> > Is it possible to log this output through Log4Perl?
>
> Synchronicity:
>
> http://techblog.babyl.ca/entry/catalystx-info


Hi,

Thanks for your email, I saw this post, but I 'm not sure I can use it to get the Catalyst normal startup output in my logs. Is this possible?

Thanks

Adam

_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Hi Adam,

* Adam Witney <awitney@sgul.ac.uk> [2014-11-13 12:45]:
> I saw this post, but I 'm not sure I can use it to get the Catalyst
> normal startup output in my logs. Is this possible?

I guess you could make half a work-around with this module, by writing
a plugin that uses the module to log this data manually during startup.
How satisfactory that is I cannot say, since that depends on whether you
also want the normal debug output to not to go to screen and whether you
need debug mode in general.

The problem with redirecting this stuff is that Catalyst produces the
debug output very early during its startup, before it has loaded any
extensions or plugins, so the logging facilities are the built-in stuff.
(Hm, maybe it is possible to load the logging-related modules yourself
and then hack them in with BEGIN or some such.) The code to produce this
output is part of the startup code and not well accessible separately
(which is the whole reason for CatalystX::Info after all).

I.e. Catalyst basically doesn’t support what you want, and any solution
done without built-in support will be ugly in some way or other.

However maybe it can be modularised to support this. The tricky part of
that is that you do want to output this info early, so that it will be
useful for debugging e.g. when components break during loading – but
OTOH it should optionally be subject to the user’s configured logging
system. How do you resolve that contradiction? The rest of a new design
should fall out of the answer to that question automatically.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

On Thu Nov 13 2014 at 20:22:51 Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:

> Hi Adam,
>
> * Adam Witney <awitney@sgul.ac.uk> [2014-11-13 12:45]:
> > I saw this post, but I 'm not sure I can use it to get the Catalyst
> > normal startup output in my logs. Is this possible?
>
> The problem with redirecting this stuff is that Catalyst produces the
> debug output very early during its startup, before it has loaded any
> extensions or plugins, so the logging facilities are the built-in stuff.
> (Hm, maybe it is possible to load the logging-related modules yourself
> and then hack them in with BEGIN or some such.) The code to produce this
> output is part of the startup code and not well accessible separately
> (which is the whole reason for CatalystX::Info after all).
>
>
>
I've had success with this sort of approach, by overriding finalize_config
in the base class:

=head2 finalize_config

After config merging is complete initialise log4perl as our logger and
enrich the available version info

=cut

sub finalize_config {
my $class = shift;

$class->next::method(@_);

$class->log( Log::Log4perl::Catalyst->new( $class->config->{logfile} ) );

my $visible_version = $class->_describe_version;
$class->config->{version} = $visible_version;
$class->log->info( "Starting version: [" . $visible_version->{name} . "]"
);
}

Something like that should do what you need.

--
Scott

> -----Original Message-----
> From: Aristotle Pagaltzis [mailto:pagaltzis@gmx.de]
> Sent: 13. novembra 2014 20:22
> To: catalyst@lists.scsys.co.uk
> Subject: Re: [Catalyst] Log4Perl and Catalyst startup routing table
>
> Hi Adam,
>
> * Adam Witney <awitney@sgul.ac.uk> [2014-11-13 12:45]:
> > I saw this post, but I 'm not sure I can use it to get the Catalyst
> > normal startup output in my logs. Is this possible?
>
> I guess you could make half a work-around with this module, by writing a
> plugin that uses the module to log this data manually during startup.
> How satisfactory that is I cannot say, since that depends on whether you also
> want the normal debug output to not to go to screen and whether you need
> debug mode in general.
>
> The problem with redirecting this stuff is that Catalyst produces the debug
> output very early during its startup, before it has loaded any extensions or
> plugins, so the logging facilities are the built-in stuff.
> (Hm, maybe it is possible to load the logging-related modules yourself and
> then hack them in with BEGIN or some such.) The code to produce this
> output is part of the startup code and not well accessible separately (which is
> the whole reason for CatalystX::Info after all).
>
> I.e. Catalyst basically doesn’t support what you want, and any solution done
> without built-in support will be ugly in some way or other.
>
> However maybe it can be modularised to support this. The tricky part of that
> is that you do want to output this info early, so that it will be useful for
> debugging e.g. when components break during loading – but OTOH it should
> optionally be subject to the user’s configured logging system. How do you
> resolve that contradiction? The rest of a new design should fall out of the
> answer to that question automatically.
>

Thanks for the suggestions.

It turns out that if you use

log4perl.logger.MyApp = DEBUG, Screen

then you lose all the standard Catalyst output, but if you use

log4perl.rootLogger = DEBUG, Screen

then you get it back again.

Thanks

Adam


_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/