I have two possibly relevant ideas: 1. I think there are only a few object names it is reasonable to hardcode - such as ServiceController. If we adopted the idea of creating "namespaces" by including a namespace=xxx attribute in every object name, the appropriate e.g. ServiceController object name can be constructed from a hardcoded name (missing the namespace attribute) by including the namespace from the current mbean. This kind of equates namespace with jboss instance in a vm, in case you want to have several jboss instances running in the same vm.
2. Maybe a proliferation of depends tags could be sidestepped by an alternate xml config structure -- where mbean confs could be nested instead of having refs. So instead of <mbean code="..." name="jboss.example:name=example1"> </mbean> <mbean code="..." name="jboss.example:name=example2"> <depends optional-attribute-name="parent">jboss.example:name=example1</depends> </mbean> we'd have <mbean code="..." name="jboss.example:name=example1"> <mbean code="..." name="jboss.example:name=example2"> </mbean> </mbean> David Jencks n 2002.01.04 17:28:32 -0500 Jason Dillon wrote: > I agree that we probably don't want to expose the configuration of the > primary kernel services, but it would be nice if we could not hard code > them still. > > Perhaps a helper object which would take the servers default domain and > then use that to construct the actual object name for these components. > > Ahhh... but then that object would need a reference to the server and > components a reference to the helper. If the helper was static then it > would be forced to find a server which might not return the correct > server if there were more than one. > > Could have the helper take the server from the component and use that to > generate names. > > Doesn't really seem worth it though... not sure. > > I would prefer scoped names, but in short of that, why not expose the > kernel names via config? Most of this would be done in > jboss-serivce.xml or in core kernel components so I would not expect > users to have to or want to change those. > > ... > > --jason > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:jboss- > > [EMAIL PROTECTED]] On Behalf Of marc fleury > > Sent: Friday, January 04, 2002 6:44 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] more jmx domain structure > > > > > Does this mean that there are hard-coded references > > > between mbeans? I > > > think it would be a good idea to convert these to > > > depends elements in the > > > mbean configuration (formerly mbean-ref elements) to > > > make these > > > dependencies more explicit. What do you think? > > > > > > Good and bad, don't make it a default (which is what I am reading > here). > > The truth is that while we use JMX to loosely create and configure > > objects, some islands of objects just live together should we hardcode > the > > links in there (inside the island) or should we expose these links *at > the > > same level of management as we do the rest of the configuration*? the > > answer is no.. don't, keep the real configuration (that that will > change) > > configurable. These links are explicit in normal java code as we > compile > > against them and pass reference. In JMX we configure objectnames as > > string, but the fact is that the code flow is mostly always the same > and > > (for example) an EJBDeployer and a SARDeployer will always use the > > "MainDeployer" (in the new deployer codebase I will commit when I get > back > > to Atlanta). Should we expose that reference for *users* to see and > > configure? *NO* > > > > Hardcoding JMX Object Names references (through the use of > > MyInterface.OBJECT_NAME as we do today) is in fact the better, more > > useable solution. Don't expose kernel configuration knowledge in a > file > > that users are supposed to read and configure... > > > > > > marcf > > ______________________________________________________________________ > > View this jboss-dev thread in the online forums: > > http://jboss.org/forums/thread.jsp?forum=66&thread=5570 > > > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
