Hi all, Now for the interesting stuff... At this point, I have dynamic creation of MBeans figured out -- I can even get them to persist and reload their state through a manually-assisted process. The next step is to complete the cycle by loading the metadata of the MBeans at runtime.
There are some options here. Juha wrote the following. >make the mbean registry persistent (it's already an mbean) triggering >store() on registerMBean() calls, and have your widget factory register >mbeans using the registry mbean operation registerMBean(Object, >ObjectName, Map) where you pass in the valueMap the additional info to >store for recreating the mbeans (constructor signature, args, other config >info). At registry load() read and recreate mbeans, and then mbeans each >load() their state. The MBean registry is a large Object graph, comprising much of the entire server. It seems that this is a lot to tackle, as I don't want to serialize/deserialize the entire server, just a few dynamically created MBeans. I'm willing to try this, or any approach that makes the most sense, but I'd like to hear more design ideas on the subject before going forward. Here's the direction I'm coming from... The process for creating MBs is 1) make MBeanInfo, 2) Make an MBean with that MBeanInfo, and 3) register. After #3, the state of that MBean will be persisted, if appropriate. What will not be persisted is the MBeanInfo generated in step #1. In the case of MBeans created by the ServiceCreator/Deployer, the MBeanInfo is already persistent (stored in *-service.xml in the deploy folder). To achieve this, the dynamically created MBeans need a mechanism to A) persist the MBeanInfo, and B) reload the MBeanInfo and execute steps #2 and #3 at server start. After that, the system will work automatically. This is where I could use some design input. (A) is relatively trivial. To achieve (B), I could create an MBean responsible for loading MBeans from the MBeanInfo database created by (A), at startup. This, of course, is precisely what the Service Deployer does, with the difference that this deployer will not try to load the MBeanInfo stores when they are written (A). Perhaps the solution is to provide a programmatic interface to the service deployer that will write the MBeanInfo for a given MB to the deploy folder, but won't try to re-deploy it? Pheraps there is a better idea? - Matt ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
