Hi Berin, first of all: After retrieving the source from CVS some of the files are in "bad" format i.e they have wrong line endings:
$ head -3 ComponentFactory.java | od -c 0000000 / * \r \r \n \r \r \n = = = = = = = 0000020 = = = = = = = = = = = = = = = = * 0000120 = = = = = \r \r \n 0000130 This makes it somewhat problematic to send patches, because converting the file locally to the proper format will result in a diff for the complete file. If I edit the original, any new line will have other line endings as the original ones, but the diff is at least understandable ... Currently I have a patch ready for the support of the logger attribute for components. Id is still used for the logger name, if logger is not available. Additional see my comments for the proposal below. Schaible, J�rg wrote: > Hi Berin, > >> 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". > > After using the latest version from CVS, "id" is used now. The current > behaviour is to use the id directly as category. IMHO this is not > smart if you have nested compoments, since the id has other semantics > in Fortress. This prevents the creation of useful logger hierarchies. > > Do you mind if I send a patch implementing following scheme: > > Use "logger" as direct logger definition if present. Use id otherwise, > but install the logger as child of the parent's logger. > > <app logger="app"> > <comp1 id="c1"> > <comp11 id="c11" /> > <comp12 id="c12" logger="special.comp12"> > <comp121 id="c121" /> > </comp12> > </comp1> > </app> > > this xconf would result in following hierarchy: > > app > app.c1 > app.c1.c12 > special.comp12 > special.comp12.c121 > > Is this fine? My intention was to build automatically a logger hierarchy based on the id of the component. Looking at the current implementation I detected, that the logger category for the root container is normally set using the entry ContextManagerConstants.LOG_CATEGORY in the context, so my logger attribute for the "app" element above is somewhat obsolete. Anyway, to build the logger hierarchy for the components based on the id I need additional information in the ComponentFactory.aquireLogger, because I do not know the name of my container's logger (or at least I found no way). My idea would be to add missing logger attributes in the configuration automatically reflecting the container's logger name and the id of the child if it has no logger attribute. This can be done in AbstractContainer.configure. What do you think about this? Regards, J�rg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
