> >>>>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.
when your component crosses problem boundaries (of which the container may not be aware, ie remoting 'n stuff), the component will need to identify itself to a caller and/or callee in some way. Another such issue is wrt to i18n. In many systems it is cumbersome to make dealing with that the task of the container, whereas it is usually easy to resource the components. > I still don't see any *compelling* reason to expose the component's > name to itself. There is nothing it can do programatically. yep. But what it can do is provide this information to "userspace", where it is perfectly viable for the component doing so directly instead of through the container. > 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. Think of a GUI manager for InfoMover...you'd want to expose components. Think of JMX support in phoenix...that's all about (well also about) exposing components.............I suspect we're thinking different things here... I wasn't completely sure we needed avalon:name before; I am now =) cheers, - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
