RE: [JBoss-dev] more jmx domain structure
Sounds good to me. --jason > -Original Message- > From: [EMAIL PROTECTED] [mailto:jboss- > [EMAIL PROTECTED]] On Behalf Of Sacha Labourey > Sent: Friday, January 04, 2002 10:06 AM > To: Jason Dillon; [EMAIL PROTECTED]; jboss- > [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] more jmx domain structure > > Jason, > > Sorry to come late on this... but what about jboss.cluster for clustering? > > cheers, > > > Sacha > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > Jason Dillon > > Envoye : jeudi, 3 janvier 2002 05:26 > > A : [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Objet : RE: [JBoss-dev] more jmx domain structure > > > > > > 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 > > > ___ > 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
Re: [JBoss-dev] more jmx domain structure
>Yah that's it... I love the way ... U ... come back .. on nothingness´s /p "The language we use influences the thoughts we think much more than the thoughts we think influence the language we use." ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] more jmx domain structure
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 jboss.example:name=example1 we'd have 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
RE: [JBoss-dev] more jmx domain structure
Yah that's it... or not... can't really tell. I have no clue what this means. --jason > -Original Message- > From: Peter Fagerlund [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 04, 2002 7:03 PM > To: Jason Dillon; 'marc fleury'; [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] more jmx domain structure > > on 04-01-2 23.28, Jason Dillon at [EMAIL PROTECTED] wrote: > > > I would not expect users to have to or want to change those. > > I think this defines well the semantic func going on ... > > I am a user ( proud user, that is ( ... ) ( so are U ( ...( proud that is > ) > ) ) ... ) ... I am a dev ... I am I ... sematics ... lets use ( ... ) in > a > market drive ... instead of ... in a *censor* ... > > Yoprs ... or how U like spel it ... while meaning is the same ... > > /peter_f > > " Languages task specifies which language resources should get included in > the installer. By default, all Core and Western languages (Latin > languages) > are built into the installer. (Note: To build installers for Eastern > languages, you must make sure you are bundling an internationalized > virtual > machine with your installer. See the InstallAnywhere Users' Guide for > additional information.)" ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] more jmx domain structure
on 04-01-2 23.28, Jason Dillon at [EMAIL PROTECTED] wrote: > I would not expect users to have to or want to change those. I think this defines well the semantic func going on ... I am a user ( proud user, that is ( ... ) ( so are U ( ...( proud that is ) ) ) ... ) ... I am a dev ... I am I ... sematics ... lets use ( ... ) in a market drive ... instead of ... in a *censor* ... Yoprs ... or how U like spel it ... while meaning is the same ... /peter_f " Languages task specifies which language resources should get included in the installer. By default, all Core and Western languages (Latin languages) are built into the installer. (Note: To build installers for Eastern languages, you must make sure you are bundling an internationalized virtual machine with your installer. See the InstallAnywhere Users' Guide for additional information.)" ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] more jmx domain structure
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
RE: [JBoss-dev] more jmx domain structure
Jason, Sorry to come late on this... but what about jboss.cluster for clustering? cheers, Sacha > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de > Jason Dillon > Envoye : jeudi, 3 janvier 2002 05:26 > A : [EMAIL PROTECTED]; [EMAIL PROTECTED] > Objet : RE: [JBoss-dev] more jmx domain structure > > > 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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
RE: [JBoss-dev] more jmx domain structure
Hi Jason, comments below: On Thu, 3 Jan 2002, Jason Dillon wrote: > > > 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. > Sorry but I've purged the CVS update notifications so I don't know which bits of code you've been changing - which is why my question may be off the mark. Are you talking about MBeans which implement MBeanRegistration and return a new ObjectName in preRegister()? If so, that returned ObjectName is *only* used if the one supplied in the preRegister() arglist is null. In this instance if the MBean doesn't return a valid ObjectName then a RegistrationException will get thrown and postRegister(false) is called on the MBean. Depending on how you are changing things (and what may have already been there) you may need to review your changes to see if you need to do any cleanup in response to a postRegister(false). Regards, Trevor ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] more jmx domain structure
> 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
Re: [JBoss-dev] more jmx domain structure
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 PROTE
RE: [JBoss-dev] more jmx domain structure
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 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. 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. Anyways, my thoughts on this issue haven't settled down yet, so any insight would be helpful. --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 compon
Re: RE: [JBoss-dev] more jmx domain structure
Hi, JMImplementation is part of the JMX spec and is created by the MBeanServer. Regards, Adrian __ 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
Re: [JBoss-dev] more jmx domain structure
Hi "SingleJBoss" comes from my JSR-77 implementation. It can be that this is hardcoded but I am not quite sure. Will investigate it next week when I am back. See ya - Andy - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, January 02, 2002 8:25 PM Subject: RE: [JBoss-dev] more jmx domain structure > 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. > > 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
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
RE: [JBoss-dev] more jmx domain structure
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. 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
RE: [JBoss-dev] more jmx domain structure
Perhaps once Marc's changes are commited we can look into make this a reality. --jason On Wed, 12 Dec 2001, Bill Burke wrote: > 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
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
