That raises interesting issues. For example: do we really have a single
point of configuration? Currently, (almost) yes: the files in /conf and
/deploy are enough to start jboss but changes are not brought back to these
files.
If we now want to persist any changes to a db (or anything else) to remember
changes, we no more have a single point of configuration. Does it mean that
the db only contains diff from the files? I would say no. Furthermore, now
we speak about modifying a current config but what if we add/start new
mbeans and delete/destroy mbeans from the http connector for example?
Should we consider the files in /deploy and /conf only as a way to bootstrap
a fresh jboss instance and then *only* work with the state from the db? This
could be interesting for different things:
- with this scheme, we can easily add AS versioning: we keep an history
state (snapshot) of configuration + deployments! (jar, etc.) At any time
then, we can say: I want the state of services, applications, queues, etc.
while running the 21.04.2001 at 19h34. It is up to the user to say: create a
new snapshot now, I want to be able to use it now. For new deployments,
imagine the win! you can make a snapshot, update your app/services/etc., see
if it works and if it doesn't (possibly by an automatic test), revert to the
previous state. No app server has this.
- if you want a locked-down version for production, the whole state
(config+jar+etc.) could be merged in a single file (sar, jar, whatever fits)
and deployed in a naked jboss instance with this single file in deploy.
If we keep focusing on the basic set of files, we will be quite limited and
will always have headache with: "who owns the correct state".
But I agree, being able to specify in the mbean definition what kind of
persistence an mbean requires is a must. e.g.: transient, read-only,
persistable, etc. Anyway, the mbean tag definition will most probably need
to be extended. For example, we will need to add a tag such as jndi-name.
When deploying the mbean, a generic proxy (one per available invoker for
example) would be automatically bound by the deployer in JNDI. It would make
any mbean invocable at no cost for the developer (at least for standard
mbeans). For other bean (dynamics, etc.) the developer could provid its own
client-side interface to be used to generate the proxy.
cheers,
SAcha
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> David Jencks
> Envoyé : mercredi, 26 juin 2002 13:42
> À : [EMAIL PROTECTED]
> Objet : Re: [JBoss-dev] JMX: Adding Model MBean database persistence
>
>
> First of all, I'm really delighted you are working on this.
>
> You are going to have conflicts with our current usage of **-service.xml
> files, since we are abusing them to serve for both telling the server what
> mbeans we want and what their initial configuration is, and as our only
> form of persistence. If we get real mbean persistence we will need to
> rethink our **-service.xml usage.
>
> My preferred approach is to process each **-service.xml file only when its
> timestamp changes or you provide explicite deploy/undeploy/redeploy
> instructions, something like this:
>
> deploy **-service.xml file, creates and configures mbeans
>
> shutdown server, mbeans persisted through PM
>
> restart server, mbeans reloaded through PM. Timestamp of **-service file
> checked, since it hasn't changed (timestamp was saved in an mbean
> representing the deployment), it is ignored
>
> remove (or undeploy explicitly) **-service.xml file, mbeans removed from
> server.
>
> What do you think of this scheme?
>
> I think to implement it we need to:
> --remove the shutdown method from MainDeployer
> --make DeploymentInfo and possibly the DeploymentScanner (I think it has a
> list of packages and timestamps as well) into mbeans so the set
> of deployed
> packages and their timestamps is persisted.
>
> Thanks
> david jencks
>
> On 2002.06.26 07:02:27 -0400 Juha-P Lindfors wrote:
> > On Wed, 26 Jun 2002, Paul Ward wrote:
> >
> > > Why I had to create an XMBean descendant:
> > >
> > > First, XMBean's link to the PM interface is through the instance
> > created in the static
> > > initializer for the ModelMBeanInvoker class. This class is hard coded
> > to use the NullPersistence
> > > class as it's PM.
> >
> > True, as we don't have any PMs yet. Just change this
> > implementation to allow you to configure any PM.
> >
> > > Second, the PM needs a reference to the XMBean instance so that it may
> > > call the MBeanInvoker.getAttribute and MBeanInvoker.setAttribute
> > > methods. It is not practical to try and access the attributes through
> > > the stack since we'll need to restore the values before the mbean is
> > > registered with the server. Maybe I'm missing something here about
> > > another way to access the mbean attribute values themselves.
> >
> > We will make the callback to load() as part of the MBean's registration
> > phase, after the interceptor stack has been properly set up (rather than
> > making the completely brain dead load() in the constructor which is what
> > the spec mandates).
> >
> > Therefore it might be worth it to change the PM interface to contain a
> > reference to the invoker directly rather than to the metadata
> (which will
> > be available through the invoker) and therefore you will have direct
> > access to the set/getAttribute as well (with properly working stack by
> > the
> > time your load() is called).
> >
> >
> > > Third, the PM needs the objectName value of the bean to persist.
> > > Might be missing something here as well.
> >
> > This will also be available through the MBeanInvoker interface. I will
> > commit these changes in about a week to the CVS.
> >
> >
> >
> > > Obviously, these issues can be resolved if we're able to modify the
> > existing XMBean.
> >
> > You are.
> >
> > > I was going under the assumption that the PM I'm writing might not be
> > merged into
> > > the CVS tree.
> >
> > You're the first one wanting to take a stab at it. I will get you a CVS
> > RW.
> >
> > > If we could specify the PM to use on an XMBean by XMBean basis
> >
> > Yes that is the idea.
> >
> >
> > > (I'm assuming in the descriptor here or maybe in the mbean tag if we
> > > want even finer control),
> >
> > Yes.
> >
> >
> > > What I mean by 'how this should be tied into the system?':
> > >
> > > How we address the above issues.
> >
> > Go ahead and make the changes directly to the XMBean implementation.
> >
> > There are some changes coming to the invoker/invocation though. I will
> > commit these by the end of the month. You might want to wait
> for those to
> > appear first.
> >
> >
> > > BTW, I have the implementation up and running. The user must not
> > specify
> > > the default values in the jboss-service.xml though, since doing so
> > persists
> > > the default values right over top of the values persisted on the last
> > > server run. Any insight you could provide to address this issue would
> > > be appreciated.
> >
> > I don't know how jboss-service.xml works.
> >
> > -- Juha
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Jabber Inc.
> > Don't miss the IM event of the season | Special offer for OSDN members!
> > JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber Inc.
> Don't miss the IM event of the season | Special offer for OSDN members!
> JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
-------------------------------------------------------
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
