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.

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