The mbean name must be unique, so you'll have to add something in the name for uniqueness, e.g. mydomain:name=mymbean,id=123
Also note that you can't have more than a couple of thousand mbeans, it won't scale.
Thanks, this information really helps. As a new-bie in this field, i'd like to ask a question related to concurrency offered by the container to handle multiple requests on same dynamic mbean. For example, say on a request a dynamic mbean queries a resource and populates it's attribute, done using MBeanInfo which is built dynamically. But say in a case where two requests come to a single instance of mbean and the resources the mbean is going to query are different and hence the attributes are different, how can this case be handled?
Essentially can an mbean have multiple MBeanInfo at the same time?
By design mbeans must handle their own concurrency, as many threads can be accessing them.
Dynamic mbeans can alter their mbean interface dynamically, e.g. now they report 3 attributes and 2 operation, then next moment 5 attributes and 4 operations, although this is not very common.
Conceptually, the mbean would report a single MBeanInfo, at any given point in time, in practise, you can alter the reported mbeaninfo even for concurrent requests, but this is certainly a sick thing to do.
Dynamic mbeans are really meant for adapting their interface to a particular backend/resource upon creation, plus they are supposed to be a little faster (no reflective calls), but harder to code. They are not meant for changing their interface every millisecond.
I think you should start the other way round. What you want to do?