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
