On 2002.01.03 18:44:45 -0500 Jason Dillon wrote: > Yes there are lots of card coded references between components... which > was part of why this was harder than I had expected. > > We should try to move all of those references to configurable links. > > That said, I don't really have a good plan of attack to change this, > though I think this work sets that up.
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. > > I was trying to get the system to a state where it might be possible to > registered two separate JBoss instances bound to separate JMX domains on > one JVM. This might be useful for embedding (which the Server* changes > were aimed at), but is also a useful way to find all of the places where > we are not as pluggable and adaptable as we should be. I like that. > > It is too bad that JMX does not provide a better was to handle domain > names, such as a scoped namespace and such. Which would be to say that > if a component is registered under domain x.y then sub-components > created by it using :XXX=YYY would default to using x.y:XXX=YYY > > I think that this might be possible with the current JMX spec, but we > would have to dramatically revise how we use ObjectName and how > components get there names to make that happen. > > 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. 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 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) > > Anyways, my thoughts on this issue haven't settled down yet, so any > insight would be helpful. anyway, I'm glad someone is taking a look at this. david jencks > > --jason > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of > David Jencks > Sent: Wednesday, January 02, 2002 8:59 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] more jmx domain structure > > On 2002.01.02 23:25:43 -0500 Jason Dillon wrote: > > I just finished commiting this. I was unable to change the > > 'SingleJBoss' or the 'JMImplementation' domains, so I left them as > they > > were. I don't know where the later even gets set. I tried changing > > SingleJBoss, but it is not as straight forward as the others I > changed. > > > > Currently the default build has the follwing domains: > > > > JMImplementation > > SingleJBoss > > jboss.j2ee > > jboss.jca > > jboss.jmx > > jboss.mq > > jboss.mq.destination > > jboss.security > > jboss.system > > jboss.system.classloader > > jboss.web > > jboss > > > > Where everything that did not fit into a specific domain went into > > jboss. > > > > It was a bit trickier than I had expected to make the change, as some > > compoinents did not check to make sure they had valid references to > > objects and throw some rather unhelpful exceptions. I have added some > > more detail to some of those areas to help avoid this in the future. > > 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? > > david jencks > > > > I am still running into cluster related exceptions as well as some > > strange Remote and RMI exceptions... not really sure why... don't > think > > they are related to the domain name change though. > > > > Components (like the Axis stuff) which are not part of the default > tests > > may need a little help, though I really tried to update all names so > it > > might just work. > > > > Happy new year. > > > > --jason > > > > > > -----Original Message----- > > From: Bill Burke [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, December 12, 2001 2:21 PM > > To: Jason Dillon; [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] more jmx domain structure > > > > Excellent idea. > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > Jason > > > Dillon > > > Sent: Wednesday, December 12, 2001 5:08 PM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] more jmx domain structure > > > > > > > > > Again, quick thought... > > > > > > Was thinking that we might want to change the way we use JMX > > > domain names. > > > Right now we have something like this: > > > > > > Adaptor > > > J2EE > > > JBOSS-SYSTEM > > > JBossMQ > > > JCA > > > JMImplementation > > > JMX > > > Jetty > > > Security > > > SingleJBoss > > > ZClassLoaders > > > > > > This does not really show which bits are specific to JBoss, which > > > are part > > > of the JMX reference impl and which bits might be user components. > > So, I > > > was thinking something more DNS like: > > > > > > jboss.system > > > jboss.system.classloaders > > > jboss.mq > > > jboss.jmx > > > jboss.jmx.adaptor > > > jboss.jca > > > jboss.j2ee > > > jboss.security > > > jboss.management > > > jboss.web > > > > > > Then users might specify components like: > > > > > > user.mydomain > > > user.mydomain.subdomain > > > > > > I think that this would work for querying jmx names too, like say > > > you wanted > > > to see all of hte jboss.system domains & components, you might be > able > > to > > > use "jboss.system.*:*" > > > > > > --jason > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > 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
