in reply to Re: Accessing Log::Log4perl Configuration Values
in thread Accessing Log::Log4perl Configuration Values

Thank you andyford,

but Log::Log4perl::Config::DOMConfigurator has the same problem of Log::Log4perl::Config::PropertyConfigurator: it cannot be used standalone to access configuration values and, when used with Log::Log4perl::Config, returns an hash reference. This is why I wrote that small package.

Ciao, Valerio

  • Comment on Re^2: Accessing Log::Log4perl Configuration Values

Replies are listed 'Best First'.
Re^3: Accessing Log::Log4perl Configuration Values
by andyford (Curate) on Mar 19, 2007 at 09:39 UTC

    Sorry I should have explained my thoughts in more detail.

    What I'm thinking is that your write your log4perl configs in XML. Log::Log4perl::Config::DOMConfigurator is used in your perl programs that are actually using Log::Log4perl. Then when you want to get at your config elements from somewhere else, you parse the XML with a DTD and an XML parser. That buys you a clean way to get at everything in the log4perl configs.

    Of course this is a lot of work and it may be overkill for your needs. However it does "future-proof" you in the case of later requirements causing your home grown parsing to become unwieldy or hard to maintain.

    non-Perl: Andy Ford

      Now I understand what you mean :) I think, however, that such parser should also handle variable substitution, forcing me to reinvent a wheel, right? So I think that it is better to stick with Log4perl internal classes (those classes should be "future-proof"), hence the solution above.

      Thanks, Valerio

        I haven't looked closely, but for the XML config, you'd probably not use variable substitution. It's just for convenience anyway.

        The DOMConfiguration module is by the same author as Log4perl itself, so it's not likely to go stale.

        non-Perl: Andy Ford