RE: [JBoss-dev] creating persistent MBeans dynamically

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

David,

  I've been hearing this in bits an pieces for a while.  Thanks for laying
it all out.

  I think that most of that sounds quite sensible, and is in line with my
goals for server management.

  I look at this as a matter of function.  Currently, if you want to make a
temporary (life of the server) change, you can use the APIs, Adaptors, JMX
Console, etc. If you want to make a permanent change, you need to edit the
XML and redeploy the MBean.  Since one seldom wants to make a temporary
change (except when testing, and probably not even then), this makes some of
the most interesting functionality  less usable.

> 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.

  I've been putting mine in /conf/mbean-state for now.  If object names are
unique, then they provide a useful map for persistence locations.  I could
see user:service=FooMBean being stored at
../mbean-state/user/service/FooMBean.xml (Note the xml extension -- my guess
is that the best file based persistence will be XML- and
PropertyEditor-based).  A similar construct could be used for a JDBC
persistence mechanism.

  The thing that might help with this would be a Persistence Manager MBean
that could be used to serialize or load any other MBean (I think you
suggested this previously).

  One question I have is how does all of this relate to the JMX spec.  I
assume that OnUpdate, Never, etc. values for persistence are part of the
spec.  There really isn't an OnShutdown.  Does the spec mention anything
about defaults?  It seems to me to be a reasonable behavior to persist
unless told not to, but of course I could understand arguments to the
contrary as well...

  Really interesting stuff...

  - Matt

-----Original Message-----
From: jbo...@li...
[mailto:jbo...@li...]On Behalf Of David
Jencks
Sent: Friday, September 27, 2002 9:08 PM
To: jbo...@li...
Subject: Re: [JBoss-dev] creating persistent MBeans dynamically

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
> Jbo...@li...
> 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
Jbo...@li...
https://lists.sourceforge.net/lists/listinfo/jboss-development