Leo Simons wrote:
> On Wed, 2002-09-18 at 15:19, Berin Loritsch wrote:
>
>>Leo Simons wrote:
>>
>>>On Tue, 2002-09-17 at 23:07, Berin Loritsch wrote:
>>>
>>>>avalon:name java.lang.String The name of a component (is this
>>>> really necessary?)
>>>
>>>
>>>+1. Seems useful to me (wrt logging, GUIs, etc). Regardless, I doubt
>>>anyone would ever want to attach a different class or meaning to
>>>"avalon:name" so I doubt it will lead to problems.
>>
>>Well, with logging the category can be assigned to the "avalon:name",
>>and management GUIs would have another way to access that information.
>>So my point is why would we need it to solve real problems?
>
>
> that doesn't compute....could you elaborate a bit...it seems to me if
> you want to assign the category to avalon:name, you should define
> avalon:name....?
The container sets the Logger, and therefore the category for the
Component. The component does not need to know what its name is to
create child loggers either because it can perform this:
Logger classLoaderLogger = getLogger().getChildLogger( "classloader" );
m_myLoader.setLogger( classLoaderLogger );
In fact, that is prefered to explicitly setting the category because
logging is performed within the scope that the container wants it
performed.
I still don't see any *compelling* reason to expose the component's
name to itself. There is nothing it can do programatically. The
Logging category is set by the container, not the component. GUIs can
get at the name through other mechanisms than the component itself. In
fact, I would have a hard time justifying exposing *all* components to a
GUI.
The only *possible* argument would be for Instrumentation. However, we
already addressed that because the parent can add to the name of the
child instrument.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
