Schaible, J�rg wrote:
Hi Berin,
after some tasks with higher priority I am back at the logger. I switched also the list.
Berin Loritsch wrote:
I recently made an alteration to Fortress (about a week ago) that
altered the way it decided what the root category was going to be.
Previously, it assigned the root category to the LoggerManager--but
that required all logger categories to decend from "fortress.*".
Now the kernel uses its "fortress" logger tree as expected, and the
components live in there own space.
I suppose I have to use the CVS newest version then ...
Also, the way logger names are assigned (I looked deeper into the
code), is based on the component id, not the logger attribute.
Hmm. At least in my current version (from end of January) tries to install a logger category based on the attribute "name".
So what should be done really? I would like to get maximum compatibility between the containers, but I don't know, what the others are doing.
J�rg :
Here is a summary of what Merlin is doing today and where I would like to see things going in the future. Aside from the info below - if your intested in getting more info on the llogging in Merlin specs, - hang in there becauase I'm in the process of reworking a lot of the Merlin docuumentation and I'll be able to0 post more info soon.
Status Today ------------
Merlin does not use the Excalibur logger package. The reason for this is that there is a seperation in Merlin between logging system defintion as opposed to declarations by a specific component type. For example, under Excalibur Logger the configuration model brings together the system and the specific component logging setup into a single configuration instance. In Merlin the logging suystem setup is in the kernel wheras the logging criteria is defined relative to a component type (i.e. <classname>./xinfo) and suppliemented by deployment profiles (i.e. <classname>.xprofile or equivalent in a block.xml package).
At the Merlin kernel level there is limited ability to create a System.out or file based logging targets based on defintion of a logging system. This is nowhere near what I would like (because the system is also mixed with targets - more seperation needed). Actual logging target crieria is defined at the level of types whereas logging directives (priority, etc.) is defined at the level of a deployment profile.
Ideas for Tommorow: -------------------
Formal defintion of a meta-info and meta-data model under the excalibur logger package that allows a really clean seperation of concerns:
* logging system spec * logging criteria spec * logging directive spec
Cheers, Steve.
Having follwing xconf Fortress does currently have only the "Fortress" root logger:
<app logger="app"> <comp1 logger="comp1"> <comp11 logger="comp1.comp11" /> <comp12 logger="comp12" /> </comp1> </app>
IIRC the logger entry for "app" is ignored at all, even if the attribute would be renamed to "name". Renaming "logger" to "name"
I suppose I would get following loggers:
Fortress.comp1 Fortress.comp1.comp11 Fortress.comp12
What is the behaviour of the other containers (ECM, Phoenix, Merlin)?
What I hoped to get was following structure, reflecting the nesting level of the components in the logger hierarchy automatically:
app.comp1 app.comp1.comp1.comp11 app.comp1.comp12
Insights?
Regards, J�rg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
