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.
| [reply] |
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.
| [reply] |
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.
| [reply] |
