There have been some discussions about this, and my opinion is not universally accepted by any means...
At the moment there isn't any provision for persisting any mbean configuration and using it in any way. I hope that we can use the persistence stuff you wrote to make the following scheme work easily. I think jboss and the mbean server should be basically a database of mbeans. When you shut down your database server, the contents are saved. Similarly, when you shut down jboss, the mbeans present should be saved and reappear when the mbean server is restarted. Shutting down jboss should not undeploy anything. You didnt' ask to undeploy anything, you asked to stop the server. Similarly, when you restart jboss, the packages that were deployed when you shut down should be in a deployed state when you restart jboss, without having to find them and redeploy them. For instance, if you deploy a package through the ant jmx task or the jmx-console, there is no need for the url to remain accessible after deployment is complete. When you restart jboss, you shouldn't need to access the url, just load the mbeans represented by the deployment from storage. As far as the mbean persistence stuff goes, I think the main thing we need is a canonical or distinguished persistence location, that is examined on server startup, and all the mbeans stored there are recreated. As far as the rest of jboss goes, we have to stop undeploying anything on shutdown, and on restart first recreate all the DeploymentInfo mbeans: then the deployment scanner can tell if a package has been refreshed while jboss was down. Thanks david jencks On 2002.09.27 17:23:13 -0400 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 > > ------------------------------------------------------- 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
