Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Message-Id: <5.0.2.1.0.20031004145038.00a94020@pop.gmx.net>
Date: Sat, 04 Oct 2003 15:01:15 +0200
To: geronimo-dev@incubator.apache.org
From: Jari Krause <jarikrause@gmx.de>
Subject: RE: [Deployment] IM #2 Summary for Directory Issue
In-Reply-To: <000001c38a57$f4955100$2ba38351@ABU>
References: <Sea1-F133vpFVjCRGry00009e81@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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:gianny_damour@hotmail.com]
> > Sent: Saturday, October 04, 2003 1:54 AM
> >
> > From: "Jeremy Boynes" <jeremy@coredevelopers.net>
> > 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