Juha & group, It appears that there are two registries available in org.jboss.mx.server.registry. org.jboss.mx.server.ServerConstants seems to indicate that org.jboss.mx.server.registry.BasicMBeanRegistry is the registry that is actually used. Is this the registry that you refer to? What does org.jboss.mx.server.registry.JBossMBeanRegistry do -- is it being used in the server?
Also, I'd like to stay as spec-centric as possible. I noticed that MBeanServer has a registerMBean() method. Any reason not to use it? Looking a little further at the spec and the implementation, I'm getting a bit confused, to be honest. I suppose that I need to create a Model MBean using the createMBean() method on MBeanServer. Then I suppose I would set the MBeanInfo (including persistence settings), and call register on the MBean. The only problem here is that the createMBean() method has already registered the bean. Does this mean that I am supposed to directly instantiate the Model MBean? I got the impression that the server was supposed to provide the Model MBean implementation. Am I missing something here? Why isn't there a method createModelMBean(Object modelObject, MBeanInfo info) on MBeanServer? - Matt -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Friday, September 27, 2002 11:05 PM To: JBoss Developers Group Subject: Re: [JBoss-dev] creating persistent MBeans dynamically 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. -- Juha On Fri, 27 Sep 2002, Matt Munz wrote: > Hi all, > > I have two questions here, a specific one relating to the subject, and a > more general question pertaining to the larger problem that I'm trying to > solve. > > First off, what is the best way to create new MBeans while the server is > running, in a persistent fashion? Say, for example, I have a class Widget, > and a class WidgetFactory. Suppose I create a WidgetFactoryMBean that has a > method > > createNewWidget(String mbeanName, Object[] widgetFeatures); > > that has the purpose of creating a new instance of Widget, wrapping it in > a ModelMBean with the name <mbeanName>, and adding that mbean to the server. > > If I use the mbean server API for this, then the new MBean is loaded in > the VM, but dissapears on server restart. > > One solution for this, I imagine, would be, instead of using the mbean > server API, to actually write a *-service.xml file to the deploy folder each > time createNewWidget() is called. Another solution might be to maintain > references to the widgets in the widget factory, and serialize and load them > through it. There are likely many more solutions. > > Have any of you tried something like this before? Is there code that does > this in the JBoss source tree? > > Now for the more general question... > > What I am trying to do is to allow dynamic generation of persistent > objects in the server. These objects need to be exposed as web services, > and have access to databases, other web services, and JMS topics. As > instances of the same class, all of these ojects will have the same > interface, yet will have different state, and need to expose this through > the web service protocol. Once I have created these instances, I don't want > them to go away unless I specifically remove them. If I restart the server, > they should show up again (technically different instances with identical > state). > > Ultimately, all I want to do is to say "create a widget named foo" via web > services, restart the server, say "tell me something about the widget named > foo" via web services, and get a response. > > I know that there are many ways to skin a cat. Is there a better way > here? Would EJB or some other structure make more sense? I am generally > trying to stay away from EJB for the moment to avoid the overhead of RMI (I > don't need distributed objects), but I am open to any solution that makes > sense. > > - 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 > -- Juha Lindfors Author of "JMX: Managing J2EE with Java Management Extensions" ------------------------------------------------------- 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 ------------------------------------------------------- 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
