> I'm sure I'm being naive, but why can't you add a depends attribute/object > name valued property for each one? I would think finding them all would > be > the hard part.
There are some components which are not directly controlled by configuration and/or have static fields which hold the object name. Take org.jboss.system.Server.ShutdownHook for example. This is a component which needs to know the name of the service controller. This isn't the best example, because I have already fixed this to not use a hard coded object name. It might be easier than I think... but I have yet to see that. We should probably change as many to depends... though I am not sure that we can set the core components (controller, deployer, ...) this way (don't really know). > > I don't think that the actual component has any business providing the > > name which it will be bound under, rather the code which registers it > > should decide that. > > Aren't the hard-coded names for the mbean itself only used if no name is > provided when the mbean is created? Does the spec require such names? I'd > be pretty happy just putting them in as a comment/suggestion if they > aren't > spec-required. That was probably the initial design, but there are lots of places in Jboss where we simply ignore the supplies/configured object name and just return the default. I have been changing this everywhere I find, but it is still a problem. > How about instead of using the domain-name part of the object name just > adding another attribute to it-- > > jboss.system:name=aaa,service=bbb,namespace=ccc Not sure what that buys. > I've had in the back of my mind for a while using an "id=nnn" attribute > like this for multiple simultaneous versions of the same mbean for use in > really-hot-redeploy (no service interruption) That seems like a good idea. We need to come up with a general policy for how attributes for jmx names are used. I image that we might eventually want to start using the query language to get access to components, so that anything that any given component which matched could be used. This would sorta be line how JINI works with interfaces, but for us it would be object name... or rather matching object name. The only way to make this work would be to standardize on name usage and then move to a query model for talking to MBeans. --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development