Hello everyone,
I'm new to this and following your discussion with interest - I thought I just wanted to add some comments from the view of an EJB developer:
* when I restart the server, this is only done because there is a bug in
the hot deployment and I have the feeling that the application is not deployed
correctly. A restart usually has the purpose to remove a buggy state. The war or ear file is usually
automatically generated by using ant - so in the development phase a JMX interface will hardly
be used to change any settings.
* Serializing MBean states doesn't sound like a clean solution for me - the purpose of an MBean is
to represent a resource - for a configuration this would be the (proprietary) deployment descriptor.
Thus an MBean should have the state of the resource and not a (temporary?) own state.
When the ear / war / jar is actually deployed for productive use, the JMX agent is in my eyes seen as comfortable alternative to edit descriptor files, with the advantage that the application does not have to be redeployed. There should definitely be the possibility to persist the new settings. This would mean the deployment descriptor of the original deployment should be modified, not the one of a temporary copy used
by the server.
good luck :-) Jari
At 11:14 04.10.2003, you wrote:
> From: gianny DAMOUR [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 04, 2003 1:54 AM > > From: "Jeremy Boynes" <[EMAIL PROTECTED]> > Date: Sat, 4 Oct 2003 00:50:19 -0700 > > >MBean persistence is used to store the configuration of each > MBean (the > >values of persistent attributes). This is used to reload the > MBeans on > >restart. The JSR77 state is not a persistent attribute, so > all MBeans > >come back in the STOPPED state. > I see. So the "Persistence Service" snapshots the persistent > attribute of an > MBean. And the "Service Controler" snapshots the transient > attributes, which > are specific to the MBean state? > > What I had in mind was to add a persistent attribute to > AbstractManagedObject abstracting the target state to reach > when the server > is restarted. This persistent attribute mirrors the transient state > attribute and is persisted based on the installed persistence > policy (which > could be checkpoint, on attribute change et cetera). The > mirroring of the > transient state and the target state is broken when a request > to shutdown > the server is received. >
This is why I believe the two need to be separate. The service controller manages the global state of the server and would be managing a controlled shutdown; so it can save the target configuration rather than having to have separate target and actual state values in each MBean. It also means that all the state can be dumped in one go, rather than having to persist each MBean individually (which could involve significantly more data).
> When a ManagedObject is restored, one uses this target state > to trigger the > relevant operation. One drawback I see in defining two > services is that we > will end up with two locations to be merged when the server > is re-started. > Moreover, it allows to share the persistence policy between these two > services.
I don't get the two locations bit - I would say there are N+1 persistent datasets (persistent attributes from N MBeans + 1 target global state definition (which may be the persistent state of the ServiceController but that is impl detail)).
> > >Given child objects can be stopped, I doubt startRecursive > is the way > >to go - instead, the controller will need to start each one > >individually (and in the correct order). > startRecursive is not the way to go to restore the identical > state. However > it will be the more simple to implement. > > Indeed, as you have underlined the controller will need to > start in the > right order the services. To start in the right order these > services, this > controller will need to re-implement a significant part of the > DependencyService. I agree that the canStart method is a good > template to > implement such a feature. This is an academic exercice and > also quite time > consuming. >
I have a feeling that the service controller and the dependency service will be very closely coupled anyway, but that's Dain's problem :-)
-- Jeremy
