RE: [JBoss-dev] JMX: Adding Model MBean database persistence
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 acce
Re: [JBoss-dev] JMX: Adding Model MBean database persistence
On Wed, 26 Jun 2002, David Jencks wrote: > This may work fine for packages deployed by a deploymentScanner, but will > work less well for packages deployed by directly calling > MainDeployer.deploy. Scanning for packages may not be the most useful > deployment method... even though right now it is the easiest to use. > > What if we thought of the mbean server as more or less a database of > persistent objects, and the deploy/undeploy/redeploy operations using > service.xml files as the insert/delete/update operations? If you deployed > a package, those mbeans would stay until you explicitly undeployed them, > whether or not the *service.xml file was accessible on server restart. My > comments on persisting timestamps over server restarts were based on this > idea and attempting to think of how the deployment scanner might work with > it. The registry of the MBean server is an MBean itself, and can be persisted by configuring a persistence interceptor to its invocation chain. Implement an interceptor that makes the persistence callbacks on registerMBean() and unregisterMBean() calls. This will give you a persisted state of the MBean server's registry. The registry allows you to attach metadata for each entry in the registry. Use this to store the URL to the MBeans management interface definition, constructor signature and values used for creating the MBean instance. This allows you to write a PM that persists the registry in an MLET like file format, with the metadata (usual rules about types needing string representation apply). You can recreate the contents of a registry by adding an Mlet like MBean to the MBean server at startup that points to this file. -- Juha --- 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
Re: [JBoss-dev] JMX: Adding Model MBean database persistence
Your ideas both seem promising. I'm still not sure about what we want as the primary determinant of which mbeans are present in a restarted server. My impression of your proposals is that they result in the set of mbeans being determined by the deployed *-service.xml files available at restart, but the attribute values determined by the mbean persistence. This may work fine for packages deployed by a deploymentScanner, but will work less well for packages deployed by directly calling MainDeployer.deploy. Scanning for packages may not be the most useful deployment method... even though right now it is the easiest to use. What if we thought of the mbean server as more or less a database of persistent objects, and the deploy/undeploy/redeploy operations using service.xml files as the insert/delete/update operations? If you deployed a package, those mbeans would stay until you explicitly undeployed them, whether or not the *service.xml file was accessible on server restart. My comments on persisting timestamps over server restarts were based on this idea and attempting to think of how the deployment scanner might work with it. What do you think? thanks david jencks On 2002.06.26 10:10:28 -0400 Paul Ward wrote: > >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. > > Yes, I've already run into that. For now I'm just leaving the default > values out of my own service files. > > >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: > > There are two things I don't like about that. First, the timestamp may > change without any changes to the values themselves. Second, what if the > user doesn't want the 'new' default values to overwrite what has been > changed through the jmx interface. > > I was thinking more along the lines of adding an Active flag to the > persistence interceptor. It's false at instantiation and is set to true > at the end of the ServiceConfigurator. The active flag could be modified > through a dynamic descriptor and be automatically removed from the > mbeaninfo after it's called by the ServiceConfigurator. Heck, we might > just make it an attribute and leave it in there so users can turn on and > off persistence. > > A second option would be to actually have persistence specified in the > -service.xml and have the ServiceConfigurator set all the attributes then > add the persistence interceptor onto the stack. As soon as the > persistence interceptor is added, it overwrites the defaults with any > persisted values. This would have the added benefit of being able to > turn on persistence per instance instead of just per class. > > What do you think? > > --Paul > > > --- > 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
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
Re: [JBoss-dev] JMX: Adding Model MBean database persistence
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
Re: [JBoss-dev] JMX: Adding Model MBean database persistence
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. The only flexibility to change this that I've found is the system property the specifies the required xmbean class. 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. Third, the PM needs the objectName value of the bean to persist. Might be missing something here as well. Obviously, these issues can be resolved if we're able to modify the existing XMBean. I was going under the assumption that the PM I'm writing might not be merged into the CVS tree. - Why it's a problem if the server creates an MBean instance of it's own: When the system starts up, the 'JMImplementation:type=MBeanRegistry' service is started with model mbean support. Since the XMBean implementation creates an instance of the PM at creation time and the MBeanRegistry comes up before any other services, the persistence options are VERY limited. If we could specify the PM to use on an XMBean by XMBean basis (I'm assuming in the descriptor here or maybe in the mbean tag if we want even finer control), the user would be able to make sure the services required by the PM itself were loaded before the service the PM is persisting. - What I mean by 'how this should be tied into the system?': How we address the above issues. - 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. -- Paul --- 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
Re: [JBoss-dev] JMX: Adding Model MBean database persistence
On Tue, 25 Jun 2002, Paul Ward wrote: > I am currently in the process of creating an XMBean descendant and >PersistenceManager implementation We don't need an XMBean descendant, just the PM implementation. > Is there any interest in having this added to the JBoss head? Yes. > If so, does anyone have input as to how this should be tied into the system? What do you mean? > This combined with the fact that the MBeanServerImpl class fires up an instance > of the required model mbean in it's constructor makes the options for > connecting to a datasource rather limited. Why is it a problem for your PM implementation if the server creates a model mbean instance on its own? -- 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
