RE: [JBoss-dev] creating persistent MBeans dynamically
Hello, And what about deployment order? When I was thinking about it (and we exchanged a few e-mails with David), the deployment order issue has poped up. When you have explicit information about dependencies, that's fine but you don't have this all the time i.e. if you create a new topic through jmx-console, the mbean is successsfuly created because the server is running. Nevertheless, at reboot-time, things may go differently. I suggested to use an internal counter in JBoss that increments each time a new service is deployed. As part of the MBean info that is persisted, we could store this id and, when restarting jboss, deploy the mbeans (which have no explict dependency info) in the sequence of their ID. This scheme is simple and support mbeans that are updated/deleted/created. Another option would be to have, for each MBean, a list of required services. But this was already discussed when we had to deal with dependencies at first. Cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Juha-P Lindfors Envoye : jeudi, 3 octobre 2002 23:19 A : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] creating persistent MBeans dynamically On Thu, 3 Oct 2002, Matt Munz wrote: all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. Perhaps I'm too simplistic, but I think that the server is either responsible for MB info persistence, or it isn't. there's no point duplicating data that doesn't change (mbeaninfo) most of it will be generated and externalized by xdoclet IMHO, nobody's going hand code it for their mbeans. so it is already stored somewhere. How about this? -- When I register my MB with the server, the server takes a peek at the MB's descriptor. If it says Persist my info, then the server takes responsibility for persisting the MB info; else, the server operates as it does now. sure. The entity that persists the MB info should be responsible for loading it at server start. yes, but an MBean loads its own state based on that metadata If MBean info persistence customization is required, I suppose we can have an MBeanInfoPersistenceManager with store() and load() methods similar to the PersistenceManager used to store MBean state, but is this really necessary? no idea, I'm not sure how you got there Either way, what is the benefit of saving part of the MBeanInfo in location A, and part of it in location B? Please explain :) no this is not what I mean at all. You have the mbean info stored once. No duplication. the number of attributes or operations the mbean has does not change during its lifetime. persistence of the metadata is different from the runtime state (the values in your attributes) I think it is necessary to either separate or merge the ideas of the deploy folder and the MB info store. I favor the former. It is easy for me to treat files in the deploy dir as deployment descriptors, and files in the MB info store as server state files. ok now you're getting JBoss deployment mixed into this as well, time to take a break. MB info store is not the state of the server (as in what values the object instances held at time T), it is the definition of it (what mbeans were registered to the server at time T, how to recreate them) and this you want to load at startup the state is separate (handled by individual mbean store() operations), and you did this already, let the individual mbeans worry about how they store and load their state like think of what the registry should store is somewhat similar to creating a db.script with CREATE and REMOVE operations of MBeans. At startup you want to read in that script to recreate the registry. You store just enough info for the MBean to be able to 'prime' itself (eg. you loaded your definition from URL A and your stored your state to URL B, here they are, you're on your own now) This perhaps could be indicated with appropriate naming conventions, comments, and documentation. If it is clear that modifications in the deploy folder will re-deploy the entire application, while the MB info store is generated and maintained by the server, I think the confusion will go away. Between the http jmx-console, JMX-GUI interfaces, the JMX API, and ANT JMX support, people have plenty of ways to modify the state of the server at runtime. Hacking the files in the store should be considered at-your-own-risk. These files
RE: [JBoss-dev] creating persistent MBeans dynamically
Sacha, I think the counter idea will work fine, given a presupposition that all MBs that a given MB (whose info is to be persisted) depends on also have their MB info persisted. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sacha Labourey Sent: Friday, October 04, 2002 9:52 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically Hello, And what about deployment order? When I was thinking about it (and we exchanged a few e-mails with David), the deployment order issue has poped up. When you have explicit information about dependencies, that's fine but you don't have this all the time i.e. if you create a new topic through jmx-console, the mbean is successsfuly created because the server is running. Nevertheless, at reboot-time, things may go differently. I suggested to use an internal counter in JBoss that increments each time a new service is deployed. As part of the MBean info that is persisted, we could store this id and, when restarting jboss, deploy the mbeans (which have no explict dependency info) in the sequence of their ID. This scheme is simple and support mbeans that are updated/deleted/created. Another option would be to have, for each MBean, a list of required services. But this was already discussed when we had to deal with dependencies at first. Cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Juha-P Lindfors Envoye : jeudi, 3 octobre 2002 23:19 A : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] creating persistent MBeans dynamically On Thu, 3 Oct 2002, Matt Munz wrote: all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. Perhaps I'm too simplistic, but I think that the server is either responsible for MB info persistence, or it isn't. there's no point duplicating data that doesn't change (mbeaninfo) most of it will be generated and externalized by xdoclet IMHO, nobody's going hand code it for their mbeans. so it is already stored somewhere. How about this? -- When I register my MB with the server, the server takes a peek at the MB's descriptor. If it says Persist my info, then the server takes responsibility for persisting the MB info; else, the server operates as it does now. sure. The entity that persists the MB info should be responsible for loading it at server start. yes, but an MBean loads its own state based on that metadata If MBean info persistence customization is required, I suppose we can have an MBeanInfoPersistenceManager with store() and load() methods similar to the PersistenceManager used to store MBean state, but is this really necessary? no idea, I'm not sure how you got there Either way, what is the benefit of saving part of the MBeanInfo in location A, and part of it in location B? Please explain :) no this is not what I mean at all. You have the mbean info stored once. No duplication. the number of attributes or operations the mbean has does not change during its lifetime. persistence of the metadata is different from the runtime state (the values in your attributes) I think it is necessary to either separate or merge the ideas of the deploy folder and the MB info store. I favor the former. It is easy for me to treat files in the deploy dir as deployment descriptors, and files in the MB info store as server state files. ok now you're getting JBoss deployment mixed into this as well, time to take a break. MB info store is not the state of the server (as in what values the object instances held at time T), it is the definition of it (what mbeans were registered to the server at time T, how to recreate them) and this you want to load at startup the state is separate (handled by individual mbean store() operations), and you did this already, let the individual mbeans worry about how they store and load their state like think of what the registry should store is somewhat similar to creating a db.script with CREATE and REMOVE operations of MBeans. At startup you want to read in that script to recreate the registry. You store just enough info for the MBean to be able to 'prime' itself (eg. you loaded your definition from URL A and your stored your state to URL B, here they are, you're on your own now) This perhaps could be indicated with appropriate naming conventions, comments, and documentation. If it is clear that modifications
RE: [JBoss-dev] creating persistent MBeans dynamically
On Fri, 4 Oct 2002, Sacha Labourey wrote: Hello, And what about deployment order? wouldn't the order be explicit if the registry stores a script-like file of its changes and then reads it at startup? similar to how a db constructs itself from a tx log -- Juha --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
I suggested to use an internal counter in JBoss that increments each time a new service is deployed. As part of brilliant. It still doesn't take care of dependencies (shut a cluster of services down) but it clearly one of those transparent ease of use things that I like to push. marc f --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
brilliant. are you ironic? :) It still doesn't take care of dependencies (shut a cluster of services down) Why wouldn't it work? Can you give me a simple scenario that fails? Maybe that's evident but I don't see it right now... Ai-je la tete dans le popotin? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
Why wouldn't it work? Can you give me a simple scenario that fails? Maybe that's evident but I don't see it right now... A depends on B. We shut down B. There is no way just by the order of deployment to know that A depends on B. The numbering schemes has the same limitation (the user provides that autonumber). marc f --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
OK, but this limitation is the same for *any* implicit dependency scheme. Either you explicitly state and this problem can be solved or you don't and in the scenario you give A should already fail when we undeploy B (not only when the server restart, but directly after we remove B). At this point, tracking class usages (which service uses which class that originates from which other service) can help detecting such situations: when undeploying B, the controller would see that A depends on it and undeploy A. People will always find a way to mess up things anyway.. We will never be able to prevent a guy from starting a JMS Topic without starting JMS by itself. It is just about freedom: we sbsolutly need to let the door open for fools to do foolish things ;) -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de marc fleury Envoye : vendredi, 4 octobre 2002 16:45 A : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] creating persistent MBeans dynamically Why wouldn't it work? Can you give me a simple scenario that fails? Maybe that's evident but I don't see it right now... A depends on B. We shut down B. There is no way just by the order of deployment to know that A depends on B. The numbering schemes has the same limitation (the user provides that autonumber). marc f --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
we agree, it will serve a purpose, It wont' solve the world hunger problem marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Sacha Labourey Sent: Friday, October 04, 2002 10:57 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically OK, but this limitation is the same for *any* implicit dependency scheme. Either you explicitly state and this problem can be solved or you don't and in the scenario you give A should already fail when we undeploy B (not only when the server restart, but directly after we remove B). At this point, tracking class usages (which service uses which class that originates from which other service) can help detecting such situations: when undeploying B, the controller would see that A depends on it and undeploy A. People will always find a way to mess up things anyway.. We will never be able to prevent a guy from starting a JMS Topic without starting JMS by itself. It is just about freedom: we sbsolutly need to let the door open for fools to do foolish things ;) -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de marc fleury Envoye : vendredi, 4 octobre 2002 16:45 A : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] creating persistent MBeans dynamically Why wouldn't it work? Can you give me a simple scenario that fails? Maybe that's evident but I don't see it right now... A depends on B. We shut down B. There is no way just by the order of deployment to know that A depends on B. The numbering schemes has the same limitation (the user provides that autonumber). marc f --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
On Fri, 4 Oct 2002, Sacha Labourey wrote: It is just about freedom: we sbsolutly need to let the door open for fools to do foolish things ;) I want infinite ways to do it right, and infinite ways to hang myself. :) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha, what you need to persist from the registry is the information to recreate the mbeans OK. Great. Sorry for the confusion. I think this information is essentially the MBeanInfo, the object name, and possibly, a dependency indicator (MB foo must be loaded after MB foobar). here. Incidentally, it appears to indicate that the entire MMB (MMB info and data) should be persisted at store(). no, just the state of the attributes (or diff update on one changed attribute, actually)... imagine an ON_UPDATE policy writing the whole metadata down to storage every time, doesn't make sense. Could you clarify the following from P. 87 of the spec? store Writes the MBean in a persistent store. Should only called by an implementation of the ModelMBean interface to store itself according to persistence policy for the MBean. When used, it may be called with every invocation of setAttribute or on a periodic basis. (optional) If the MBean is (MB info + state), then this clearly states that the *entire* MB is written. It is not specified how it is written (overwrite or write diff). I aggree that this does not make sense, especially considering the fact that dynamic changes to the MBeanInfo are ignored by the server. Perhaps this sentence should be re-written? developers are going to want to know that their beans will be treated similarly across implementations when it comes to the server lifecycle persistence. Does anyone coughJuha/cough know if this is likely? there doesn't seem to be much interest in that at the moment on the other hand it gives us the freedom to write implementations that make sense Well, I'm very interested. The work I do is spec-friendly. An important selling point for us with JBoss is flexibility via spec compliance. Since I see persistence as an invaluable feature for JMX, having it be a full fledged aspect of the spec is important for me. Perhaps if JBoss does it right, it will make its way into the spec eventually :) - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Wednesday, October 02, 2002 5:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically On Wed, 2 Oct 2002, Matt Munz wrote: Perhaps we're using 'persist' differently. The mbean registry contains object references to all of the mbeans in the server.To me, persisting the registry (or a part of it), means serializing those objects completely (MB info + data). no, the individual mbeans already persisted their state they need on their own, what you need to persist from the registry is the information to recreate the mbeans (who will then go an load() their own state they already persisted), ie which constructor to use at startup, what args go into the constructor As I understand it, MBs that want to persist their state must implement the PersistentMBean interface. If the state for all MBs in the server is also to be persisted, then I suppose that all MBs registered must be adapted to the PersistentMBean interface. Does this sound reasonable? I think you're confusing the two different modes of persistence: say I registered an XMbean instance from location http://foo/bar.xml (which is my mbean definition). When you register this mbean to the registry you pass in the valueMap that info, init(URL) was used with arg http://foo/bar.xml + objectname blah. Registry stores this info as part of its own state. When registry is recreated (server restart) it goes to its own persistence location and gets this info, calls the constructor, creates the new mbean instance, bar.xml has the persistence info for the mbean and the bean will load() its own state. I tried to scan the spec for some guidance, but was unable to find portions relating to persistence or lifecycle issues that would be relevant here. Incidentally, it appears to indicate that the entire MMB (MMB info and data) should be persisted at store(). no, just the state of the attributes (or diff update on one changed attribute, actually)... imagine an ON_UPDATE policy writing the whole metadata down to storage every time, doesn't make sense. It would definately be more convienient if some of these issues were addressed in the spec, IMHO. It seems to me that this whole discussion is a logical extension of MMB persistence in the first place, and that MB developers are going to want to know that their beans will be treated similarly across implementations when it comes to the server lifecycle persistence. Does anyone coughJuha/cough know if this is likely? there doesn't seem to be much interest in that at the moment on the other hand it gives us the freedom to write implementations that make sense -- Juha --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss
RE: [JBoss-dev] creating persistent MBeans dynamically
On Thu, 3 Oct 2002, Matt Munz wrote: Juha, what you need to persist from the registry is the information to recreate the mbeans OK. Great. Sorry for the confusion. I think this information is essentially the MBeanInfo, the object name, and possibly, a dependency indicator (MB foo must be loaded after MB foobar). all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. The only changing part in the metadata should be the descriptor which should be persisted regardless of how the mbeaninfo was loaded to the runtime system in the first place. So a simple key, value map or a property file even. The rest of the metadata should remain unchanged during the lifetime of the MBean. Could you clarify the following from P. 87 of the spec? how an mbean is persisted is really not defined in the spec. If the MBean is (MB info + state), then this clearly states that the *entire* MB is written. It is not specified how it is written (overwrite or write diff). I aggree that this does not make sense if the assumption doesn't make sense, and we both agree it doesn't make sense, then concentrate on the part that *does* make sense ;-) Well, I'm very interested. The work I do is spec-friendly. An important selling point for us with JBoss is flexibility via spec compliance. Since I see persistence as an invaluable feature for JMX, having it be a full fledged aspect of the spec is important for me. Perhaps if JBoss does it right, it will make its way into the spec eventually :) perhaps -- Juha --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
Well, I'm very interested. The work I do is spec-friendly. An important selling point for us with JBoss is flexibility via spec compliance. Since I see persistence as an invaluable feature for JMX, having it be a full fledged aspect of the spec is important for me. Perhaps if JBoss does it right, it will make its way into the spec eventually :) The spec moves slowly and they don't standardize advanced stuff (like simple interceptors), so I would focus on ourselves for now. We clearly push the technology through the channels at SUN but it takes time. Put it in JBoss and use the feature. The specs will follow one day, in the mean time we have a working implementation. JBoss vs.NET is an implementation war finally, The spec is dead long live the implementation. marc f --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha, sometimes design-by-email is not a fast route :) ... all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. Perhaps I'm too simplistic, but I think that the server is either responsible for MB info persistence, or it isn't. How about this? -- When I register my MB with the server, the server takes a peek at the MB's descriptor. If it says Persist my info, then the server takes responsibility for persisting the MB info; else, the server operates as it does now. The entity that persists the MB info should be responsible for loading it at server start. If MBean info persistence customization is required, I suppose we can have an MBeanInfoPersistenceManager with store() and load() methods similar to the PersistenceManager used to store MBean state, but is this really necessary? Either way, what is the benefit of saving part of the MBeanInfo in location A, and part of it in location B? Please explain :) I don't have the pleasure of knowing 2.0 ;), but I think I kind of know what you're talking about. Deployment of XMBeans, for example, involves two similar files with nonetheless distinct roles. I think it is necessary to either separate or merge the ideas of the deploy folder and the MB info store. I favor the former. It is easy for me to treat files in the deploy dir as deployment descriptors, and files in the MB info store as server state files. This perhaps could be indicated with appropriate naming conventions, comments, and documentation. If it is clear that modifications in the deploy folder will re-deploy the entire application, while the MB info store is generated and maintained by the server, I think the confusion will go away. Between the http jmx-console, JMX-GUI interfaces, the JMX API, and ANT JMX support, people have plenty of ways to modify the state of the server at runtime. Hacking the files in the store should be considered at-your-own-risk. These files will be generated by the server and loaded at startup only. The other option is to say that the deploy folder is the MB info store (this is kind of how it works today). I don't favor this -- I like to keep my peas on one side of the plate, and my mash potatoes on the other side ;) There is a way to make this work, if desired, but I believe that the route there is to delegate the responsibility for MB info persistence to an object other than the MB registry. Perhaps you have a use case / user story in mind that I can use as a guide. For my MBs, there is no MB info storage -- adding this mechanism will give me one and only one location for that state. This is how it should be in general, I think. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Thursday, October 03, 2002 10:07 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically On Thu, 3 Oct 2002, Matt Munz wrote: Juha, what you need to persist from the registry is the information to recreate the mbeans OK. Great. Sorry for the confusion. I think this information is essentially the MBeanInfo, the object name, and possibly, a dependency indicator (MB foo must be loaded after MB foobar). all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. The only changing part in the metadata should be the descriptor which should be persisted regardless of how the mbeaninfo was loaded to the runtime system in the first place. So a simple key, value map or a property file even. The rest of the metadata should remain unchanged during the lifetime of the MBean. Could you clarify the following from P. 87 of the spec? how an mbean is persisted is really not defined in the spec. If the MBean is (MB info + state), then this clearly states that the *entire* MB is written. It is not specified how it is written (overwrite or write diff). I aggree that this does not make sense if the assumption doesn't make sense, and we both agree it doesn't make sense, then concentrate on the part that *does* make sense ;-) Well, I'm very interested. The work I do is spec-friendly
Re: [JBoss-dev] creating persistent MBeans dynamically
the persistent representation of it. I haven't thought very hard about the advantages and disadvantages of where to put the info. However, at the moment I favor storing the object name and persistence location in the registry persistence, and putting the class name, constructor name, constructor arguments, and attribute values in the mbean infos and storing this separately. I'd favor storing the mbean infos in the xmbean xml format: we already know how to read it, we just have to learn how to write it. thanks david jencks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Thursday, October 03, 2002 10:07 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically On Thu, 3 Oct 2002, Matt Munz wrote: Juha, what you need to persist from the registry is the information to recreate the mbeans OK. Great. Sorry for the confusion. I think this information is essentially the MBeanInfo, the object name, and possibly, a dependency indicator (MB foo must be loaded after MB foobar). all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. The only changing part in the metadata should be the descriptor which should be persisted regardless of how the mbeaninfo was loaded to the runtime system in the first place. So a simple key, value map or a property file even. The rest of the metadata should remain unchanged during the lifetime of the MBean. Could you clarify the following from P. 87 of the spec? how an mbean is persisted is really not defined in the spec. If the MBean is (MB info + state), then this clearly states that the *entire* MB is written. It is not specified how it is written (overwrite or write diff). I aggree that this does not make sense if the assumption doesn't make sense, and we both agree it doesn't make sense, then concentrate on the part that *does* make sense ;-) Well, I'm very interested. The work I do is spec-friendly. An important selling point for us with JBoss is flexibility via spec compliance. Since I see persistence as an invaluable feature for JMX, having it be a full fledged aspect of the spec is important for me. Perhaps if JBoss does it right, it will make its way into the spec eventually :) perhaps -- Juha --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
On Thu, 3 Oct 2002, Matt Munz wrote: all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. Perhaps I'm too simplistic, but I think that the server is either responsible for MB info persistence, or it isn't. there's no point duplicating data that doesn't change (mbeaninfo) most of it will be generated and externalized by xdoclet IMHO, nobody's going hand code it for their mbeans. so it is already stored somewhere. How about this? -- When I register my MB with the server, the server takes a peek at the MB's descriptor. If it says Persist my info, then the server takes responsibility for persisting the MB info; else, the server operates as it does now. sure. The entity that persists the MB info should be responsible for loading it at server start. yes, but an MBean loads its own state based on that metadata If MBean info persistence customization is required, I suppose we can have an MBeanInfoPersistenceManager with store() and load() methods similar to the PersistenceManager used to store MBean state, but is this really necessary? no idea, I'm not sure how you got there Either way, what is the benefit of saving part of the MBeanInfo in location A, and part of it in location B? Please explain :) no this is not what I mean at all. You have the mbean info stored once. No duplication. the number of attributes or operations the mbean has does not change during its lifetime. persistence of the metadata is different from the runtime state (the values in your attributes) I think it is necessary to either separate or merge the ideas of the deploy folder and the MB info store. I favor the former. It is easy for me to treat files in the deploy dir as deployment descriptors, and files in the MB info store as server state files. ok now you're getting JBoss deployment mixed into this as well, time to take a break. MB info store is not the state of the server (as in what values the object instances held at time T), it is the definition of it (what mbeans were registered to the server at time T, how to recreate them) and this you want to load at startup the state is separate (handled by individual mbean store() operations), and you did this already, let the individual mbeans worry about how they store and load their state like think of what the registry should store is somewhat similar to creating a db.script with CREATE and REMOVE operations of MBeans. At startup you want to read in that script to recreate the registry. You store just enough info for the MBean to be able to 'prime' itself (eg. you loaded your definition from URL A and your stored your state to URL B, here they are, you're on your own now) This perhaps could be indicated with appropriate naming conventions, comments, and documentation. If it is clear that modifications in the deploy folder will re-deploy the entire application, while the MB info store is generated and maintained by the server, I think the confusion will go away. Between the http jmx-console, JMX-GUI interfaces, the JMX API, and ANT JMX support, people have plenty of ways to modify the state of the server at runtime. Hacking the files in the store should be considered at-your-own-risk. These files will be generated by the server and loaded at startup only. erm, you're losing the control of the vehicle, matt. keep deployment out of it for now, focus on how to get the restart to work. Perhaps you have a use case / user story in mind that I can use as a guide. For my MBs, there is no MB info storage -- adding this mechanism will give me one and only one location for that state. mbeaninfo is the definition, not the state, the state is in the object instances, separate -- Juha --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] creating persistent MBeans dynamically
On 2002.10.03 17:19:27 -0400 Juha-P Lindfors wrote: On Thu, 3 Oct 2002, Matt Munz wrote: all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. Perhaps I'm too simplistic, but I think that the server is either responsible for MB info persistence, or it isn't. there's no point duplicating data that doesn't change (mbeaninfo) most of it will be generated and externalized by xdoclet IMHO, nobody's going hand code it for their mbeans. so it is already stored somewhere. The location does not have to be accessible after deployment, so the mbean persistence mechanism has to store it itself. How about this? -- When I register my MB with the server, the server takes a peek at the MB's descriptor. If it says Persist my info, then the server takes responsibility for persisting the MB info; else, the server operates as it does now. sure. The entity that persists the MB info should be responsible for loading it at server start. yes, but an MBean loads its own state based on that metadata If MBean info persistence customization is required, I suppose we can have an MBeanInfoPersistenceManager with store() and load() methods similar to the PersistenceManager used to store MBean state, but is this really necessary? no idea, I'm not sure how you got there Either way, what is the benefit of saving part of the MBeanInfo in location A, and part of it in location B? Please explain :) no this is not what I mean at all. You have the mbean info stored once. No duplication. the number of attributes or operations the mbean has does not change during its lifetime. True, but the values of attributes are stored in the mbean info objects and can be stored in the xmbean xml. You can already specify initial values for mbean attributes in the xml rather than specifying them in jboss mbean dd. In fact you can supply the xmbean xml in the *-service.xml file complete with values. I keep waffling on this, but at the moment I think it makes more sense to store the attribute values separately even though this may be more work. david jencks persistence of the metadata is different from the runtime state (the values in your attributes) I think it is necessary to either separate or merge the ideas of the deploy folder and the MB info store. I favor the former. It is easy for me to treat files in the deploy dir as deployment descriptors, and files in the MB info store as server state files. ok now you're getting JBoss deployment mixed into this as well, time to take a break. MB info store is not the state of the server (as in what values the object instances held at time T), it is the definition of it (what mbeans were registered to the server at time T, how to recreate them) and this you want to load at startup the state is separate (handled by individual mbean store() operations), and you did this already, let the individual mbeans worry about how they store and load their state like think of what the registry should store is somewhat similar to creating a db.script with CREATE and REMOVE operations of MBeans. At startup you want to read in that script to recreate the registry. You store just enough info for the MBean to be able to 'prime' itself (eg. you loaded your definition from URL A and your stored your state to URL B, here they are, you're on your own now) This perhaps could be indicated with appropriate naming conventions, comments, and documentation. If it is clear that modifications in the deploy folder will re-deploy the entire application, while the MB info store is generated and maintained by the server, I think the confusion will go away. Between the http jmx-console, JMX-GUI interfaces, the JMX API, and ANT JMX support, people have plenty of ways to modify the state of the server at runtime. Hacking the files in the store should be considered at-your-own-risk. These files will be generated by the server and loaded at startup only. erm, you're losing the control of the vehicle, matt. keep deployment out of it for now, focus on how to get the restart to work. Perhaps you have a use case / user story in mind that I can use as a guide. For my MBs, there is no MB info storage -- adding this mechanism will give me one and only one location for that state. mbeaninfo is the definition, not the state, the state is in the object instances, separate -- Juha
Re: [JBoss-dev] creating persistent MBeans dynamically
On Thu, 3 Oct 2002, David Jencks wrote: The location does not have to be accessible after deployment, so the mbean persistence mechanism has to store it itself. why wouldn't it be accessible? and if my persistence mechanism is something like Dain's CMP engine, I don't expect it to store the whole mbean info object graph, only the values of individual attributes True, but the values of attributes are stored in the mbean info objects theyre cached there, this is no reason to store the whole mbean info structure if a simple getAttribute() will get me the value can be stored in the xmbean xml. You can already specify initial values for mbean attributes in the xml rather than specifying them in jboss mbean dd. In fact you can supply the xmbean xml in the *-service.xml file complete with values. oh well, I give up. too much talk already and no code. you guys do what you do, no biggie. -- Juha --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
Hi all, Now for the interesting stuff... At this point, I have dynamic creation of MBeans figured out -- I can even get them to persist and reload their state through a manually-assisted process. The next step is to complete the cycle by loading the metadata of the MBeans at runtime. There are some options here. Juha wrote the following. make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config info). At registry load() read and recreate mbeans, and then mbeans each load() their state. The MBean registry is a large Object graph, comprising much of the entire server. It seems that this is a lot to tackle, as I don't want to serialize/deserialize the entire server, just a few dynamically created MBeans. I'm willing to try this, or any approach that makes the most sense, but I'd like to hear more design ideas on the subject before going forward. Here's the direction I'm coming from... The process for creating MBs is 1) make MBeanInfo, 2) Make an MBean with that MBeanInfo, and 3) register. After #3, the state of that MBean will be persisted, if appropriate. What will not be persisted is the MBeanInfo generated in step #1. In the case of MBeans created by the ServiceCreator/Deployer, the MBeanInfo is already persistent (stored in *-service.xml in the deploy folder). To achieve this, the dynamically created MBeans need a mechanism to A) persist the MBeanInfo, and B) reload the MBeanInfo and execute steps #2 and #3 at server start. After that, the system will work automatically. This is where I could use some design input. (A) is relatively trivial. To achieve (B), I could create an MBean responsible for loading MBeans from the MBeanInfo database created by (A), at startup. This, of course, is precisely what the Service Deployer does, with the difference that this deployer will not try to load the MBeanInfo stores when they are written (A). Perhaps the solution is to provide a programmatic interface to the service deployer that will write the MBeanInfo for a given MB to the deploy folder, but won't try to re-deploy it? Pheraps there is a better idea? - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
A slight correction -- when I refer to *-service.xml, I really mean *-service.xml _and_ the XMBean definition XML. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Wednesday, October 02, 2002 10:06 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically Hi all, Now for the interesting stuff... At this point, I have dynamic creation of MBeans figured out -- I can even get them to persist and reload their state through a manually-assisted process. The next step is to complete the cycle by loading the metadata of the MBeans at runtime. There are some options here. Juha wrote the following. make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config info). At registry load() read and recreate mbeans, and then mbeans each load() their state. The MBean registry is a large Object graph, comprising much of the entire server. It seems that this is a lot to tackle, as I don't want to serialize/deserialize the entire server, just a few dynamically created MBeans. I'm willing to try this, or any approach that makes the most sense, but I'd like to hear more design ideas on the subject before going forward. Here's the direction I'm coming from... The process for creating MBs is 1) make MBeanInfo, 2) Make an MBean with that MBeanInfo, and 3) register. After #3, the state of that MBean will be persisted, if appropriate. What will not be persisted is the MBeanInfo generated in step #1. In the case of MBeans created by the ServiceCreator/Deployer, the MBeanInfo is already persistent (stored in *-service.xml in the deploy folder). To achieve this, the dynamically created MBeans need a mechanism to A) persist the MBeanInfo, and B) reload the MBeanInfo and execute steps #2 and #3 at server start. After that, the system will work automatically. This is where I could use some design input. (A) is relatively trivial. To achieve (B), I could create an MBean responsible for loading MBeans from the MBeanInfo database created by (A), at startup. This, of course, is precisely what the Service Deployer does, with the difference that this deployer will not try to load the MBeanInfo stores when they are written (A). Perhaps the solution is to provide a programmatic interface to the service deployer that will write the MBeanInfo for a given MB to the deploy folder, but won't try to re-deploy it? Pheraps there is a better idea? - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] creating persistent MBeans dynamically
I don't have time to think this through extensively, but I would like the MBeanRegistry to persit the mbean info of either --all mbeans or --all mbeans with a particular descriptor in their mbeaninfos. I want to change the use of the ServiceController/Creator/Configurator so it is ONLY used when you first deploy a package, NOT when you shut down jboss and restart it. I want the mbean persistence mechanism to take care of reestablishing all the mbeans previously present. I think that following Juha's suggestion and persisting the entire mbean registry is the best way to do this. If you get this working I will take care of making the ServiceController stuff not interfere. For making it work in the short term perhaps only persisting mbeans with a particular descriptor will be the best plan, you can set this descriptor for your dynamically created mbeans now, and we can set it for all the others later. thanks david jencks On 2002.10.02 10:23:50 -0400 Matt Munz wrote: A slight correction -- when I refer to *-service.xml, I really mean *-service.xml _and_ the XMBean definition XML. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Wednesday, October 02, 2002 10:06 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically Hi all, Now for the interesting stuff... At this point, I have dynamic creation of MBeans figured out -- I can even get them to persist and reload their state through a manually-assisted process. The next step is to complete the cycle by loading the metadata of the MBeans at runtime. There are some options here. Juha wrote the following. make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config info). At registry load() read and recreate mbeans, and then mbeans each load() their state. The MBean registry is a large Object graph, comprising much of the entire server. It seems that this is a lot to tackle, as I don't want to serialize/deserialize the entire server, just a few dynamically created MBeans. I'm willing to try this, or any approach that makes the most sense, but I'd like to hear more design ideas on the subject before going forward. Here's the direction I'm coming from... The process for creating MBs is 1) make MBeanInfo, 2) Make an MBean with that MBeanInfo, and 3) register. After #3, the state of that MBean will be persisted, if appropriate. What will not be persisted is the MBeanInfo generated in step #1. In the case of MBeans created by the ServiceCreator/Deployer, the MBeanInfo is already persistent (stored in *-service.xml in the deploy folder). To achieve this, the dynamically created MBeans need a mechanism to A) persist the MBeanInfo, and B) reload the MBeanInfo and execute steps #2 and #3 at server start. After that, the system will work automatically. This is where I could use some design input. (A) is relatively trivial. To achieve (B), I could create an MBean responsible for loading MBeans from the MBeanInfo database created by (A), at startup. This, of course, is precisely what the Service Deployer does, with the difference that this deployer will not try to load the MBeanInfo stores when they are written (A). Perhaps the solution is to provide a programmatic interface to the service deployer that will write the MBeanInfo for a given MB to the deploy folder, but won't try to re-deploy it? Pheraps there is a better idea? - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
David, Thanks. That helps a lot. Regarding persisting MB info... I want to change the use of the ServiceController/Creator/Configurator so it is ONLY used when you first deploy a package, NOT when you shut down jboss and restart it. What about re-deployment? If, after server start, I modify/touch a package already in the deploy folder, will it be re-deployed? For making it work in the short term perhaps only persisting mbeans with a particular descriptor will be the best plan, Makes sense to me. I think that following Juha's suggestion and persisting the entire mbean registry is the best way to do this. Perhaps we're using 'persist' differently. The mbean registry contains object references to all of the mbeans in the server.To me, persisting the registry (or a part of it), means serializing those objects completely (MB info + data). Isn't this excessive? I would prefer to persist only the MB info objects for these beans, as the rest of the state is unnecessary. As I understand it, MBs that want to persist their state must implement the PersistentMBean interface. If the state for all MBs in the server is also to be persisted, then I suppose that all MBs registered must be adapted to the PersistentMBean interface. Does this sound reasonable? Regarding the JMX spec... I tried to scan the spec for some guidance, but was unable to find portions relating to persistence or lifecycle issues that would be relevant here. Incidentally, it appears to indicate that the entire MMB (MMB info and data) should be persisted at store(). One issue that isn't discussed is the set of expectations for registration that relate to the server lifecycle. When I register my MB, is that for the current session (whatever that may be), the life of the server, the life of the JVM, perpetuity, etc. ? If registration is intended to last for the life of the server only, then MBs would expect not to have their MB info persisted, and an opt-in mechanism (like your added descriptor) would be needed. Otherwise, an opt-out (also using a descriptor) might make more sense. I could see a use for transient MBs that were never persisted in any way - I suppose there are many living in the JBoss Server now... It would definately be more convienient if some of these issues were addressed in the spec, IMHO. It seems to me that this whole discussion is a logical extension of MMB persistence in the first place, and that MB developers are going to want to know that their beans will be treated similarly across implementations when it comes to the server lifecycle persistence. Does anyone coughJuha/cough know if this is likely? - Matt Munz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Wednesday, October 02, 2002 12:26 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] creating persistent MBeans dynamically I don't have time to think this through extensively, but I would like the MBeanRegistry to persit the mbean info of either --all mbeans or --all mbeans with a particular descriptor in their mbeaninfos. I want to change the use of the ServiceController/Creator/Configurator so it is ONLY used when you first deploy a package, NOT when you shut down jboss and restart it. I want the mbean persistence mechanism to take care of reestablishing all the mbeans previously present. I think that following Juha's suggestion and persisting the entire mbean registry is the best way to do this. If you get this working I will take care of making the ServiceController stuff not interfere. For making it work in the short term perhaps only persisting mbeans with a particular descriptor will be the best plan, you can set this descriptor for your dynamically created mbeans now, and we can set it for all the others later. thanks david jencks On 2002.10.02 10:23:50 -0400 Matt Munz wrote: A slight correction -- when I refer to *-service.xml, I really mean *-service.xml _and_ the XMBean definition XML. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Wednesday, October 02, 2002 10:06 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically Hi all, Now for the interesting stuff... At this point, I have dynamic creation of MBeans figured out -- I can even get them to persist and reload their state through a manually-assisted process. The next step is to complete the cycle by loading the metadata of the MBeans at runtime. There are some options here. Juha wrote the following. make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config
Re: [JBoss-dev] creating persistent MBeans dynamically
On Wed, 2 Oct 2002, David Jencks wrote: For making it work in the short term perhaps only persisting mbeans with a particular descriptor will be the best plan, you can set this descriptor for your dynamically created mbeans now, and we can set it for all the others later. yes, agreed, add a flag to the mbean descriptor that says this mbean should be recreated at startup -- Juha --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
On Wed, 2 Oct 2002, Matt Munz wrote: Perhaps we're using 'persist' differently. The mbean registry contains object references to all of the mbeans in the server.To me, persisting the registry (or a part of it), means serializing those objects completely (MB info + data). no, the individual mbeans already persisted their state they need on their own, what you need to persist from the registry is the information to recreate the mbeans (who will then go an load() their own state they already persisted), ie which constructor to use at startup, what args go into the constructor As I understand it, MBs that want to persist their state must implement the PersistentMBean interface. If the state for all MBs in the server is also to be persisted, then I suppose that all MBs registered must be adapted to the PersistentMBean interface. Does this sound reasonable? I think you're confusing the two different modes of persistence: say I registered an XMbean instance from location http://foo/bar.xml (which is my mbean definition). When you register this mbean to the registry you pass in the valueMap that info, init(URL) was used with arg http://foo/bar.xml + objectname blah. Registry stores this info as part of its own state. When registry is recreated (server restart) it goes to its own persistence location and gets this info, calls the constructor, creates the new mbean instance, bar.xml has the persistence info for the mbean and the bean will load() its own state. I tried to scan the spec for some guidance, but was unable to find portions relating to persistence or lifecycle issues that would be relevant here. Incidentally, it appears to indicate that the entire MMB (MMB info and data) should be persisted at store(). no, just the state of the attributes (or diff update on one changed attribute, actually)... imagine an ON_UPDATE policy writing the whole metadata down to storage every time, doesn't make sense. It would definately be more convienient if some of these issues were addressed in the spec, IMHO. It seems to me that this whole discussion is a logical extension of MMB persistence in the first place, and that MB developers are going to want to know that their beans will be treated similarly across implementations when it comes to the server lifecycle persistence. Does anyone coughJuha/cough know if this is likely? there doesn't seem to be much interest in that at the moment on the other hand it gives us the freedom to write implementations that make sense -- Juha --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha Group,
make sure you add the getMethod and setMethod mapping to your MMB
attributes.
Thanks. I did this and started re-reading your JMX book. I now have a new
error :)
Below, I include my MBean Info generation code, and some error output. When
I try to view the jmx-console page for my new MBean, the servlet tries to
get all of the bean's attributes. The attribute getId is requested, but
this information is stored by the name Id. I assume that there is
something wrong with my MBean info, but I can't figure out what it is.
Error debug output are listed below. Any help would be appreciated.
- Matt
### metadata generation
public ModelMBeanInfo getModelMBeanInfo()
{
final boolean READABLE = true;
final boolean WRITABLE = true;
final boolean BOOLEAN = true;
// build 'Id' read-write attribute
Descriptor descr1 = new DescriptorSupport();
descr1.setField(name, Id);
descr1.setField(descriptorType, attribute);
descr1.setField(displayName, Identification);
descr1.setField(setMethod, setId);
descr1.setField(getMethod, getId);
ModelMBeanAttributeInfo idAttrInfo;
idAttrInfo = new ModelMBeanAttributeInfo(Id,
String.class.getName(),
Identification.,
READABLE,
WRITABLE,
!BOOLEAN,
descr1);
// MBean descriptor
Descriptor descr4 = new DescriptorSupport();
descr4.setField(name, Widget);
descr4.setField(descriptorType, mbean); // was MBean
// create ModelMBeanInfo
ModelMBeanAttributeInfo[] attrInfo = new ModelMBeanAttributeInfo[] {
idAttrInfo };
ModelMBeanOperationInfo[] operationInfo = new ModelMBeanOperationInfo[]
{};
ModelMBeanInfo info = new
ModelMBeanInfoSupport(RequiredModelMBean.class.getName(),
Widget,
attrInfo,
null,
operationInfo,
null,
descr4);
return info;
}
### AttributeOperationREsolver constructor
11:33:33,020 INFO [STDOUT] !!!m attributes[0]:
ModelMBeanAttributeInfo[Name=Id,Type=java.lang.String,Access=RW,Descript
or(setMethod=setId,descriptorType=attribute,name=Id,displayName=Identificati
on,getMethod=getId)]
### AttributeOperationREsolver.store()
11:33:33,020 INFO [STDOUT] !!!m storing attrName: Id and code: 0
### AttributeOperationREsolver.lookup()
11:34:06,141 INFO [STDOUT] !!!m looking up actionName: getId and signature:
[Ljava.lang.String;@1c87031
### error
java.lang.NoSuchMethodException: Unable to locate method for: getId()
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:300)
at
org.jboss.mx.interceptor.ObjectReferenceInterceptor.invoke(ObjectReferenceIn
terceptor.java:66)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:54)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:91)
at org.jboss.mx.server.MBeanInvoker.invoke(MBeanInvoker.java:79)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:129)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:99)
at
org.jboss.mx.server.MBeanInvoker.getAttribute(MBeanInvoker.java:110)
at
javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBe
an.java:147)
at
org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:455)
at
org.jboss.jmx.adaptor.control.Server.getMBeanAttributeResultInfo(Server.java
:125)
at
org.apache.jsp.inspectMBean_jsp._jspService(inspectMBean_jsp.java:179)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:2
02)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:362)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandl
er.java:284)
at
org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:216)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:151)
at
RE: [JBoss-dev] creating persistent MBeans dynamically
do you have operation info for the operation names you are mapping to
(setId getId)?
On Tue, 1 Oct 2002, Matt Munz wrote:
Juha Group,
make sure you add the getMethod and setMethod mapping to your MMB
attributes.
Thanks. I did this and started re-reading your JMX book. I now have a new
error :)
Below, I include my MBean Info generation code, and some error output. When
I try to view the jmx-console page for my new MBean, the servlet tries to
get all of the bean's attributes. The attribute getId is requested, but
this information is stored by the name Id. I assume that there is
something wrong with my MBean info, but I can't figure out what it is.
Error debug output are listed below. Any help would be appreciated.
- Matt
### metadata generation
public ModelMBeanInfo getModelMBeanInfo()
{
final boolean READABLE = true;
final boolean WRITABLE = true;
final boolean BOOLEAN = true;
// build 'Id' read-write attribute
Descriptor descr1 = new DescriptorSupport();
descr1.setField(name, Id);
descr1.setField(descriptorType, attribute);
descr1.setField(displayName, Identification);
descr1.setField(setMethod, setId);
descr1.setField(getMethod, getId);
ModelMBeanAttributeInfo idAttrInfo;
idAttrInfo = new ModelMBeanAttributeInfo(Id,
String.class.getName(),
Identification.,
READABLE,
WRITABLE,
!BOOLEAN,
descr1);
// MBean descriptor
Descriptor descr4 = new DescriptorSupport();
descr4.setField(name, Widget);
descr4.setField(descriptorType, mbean); // was MBean
// create ModelMBeanInfo
ModelMBeanAttributeInfo[] attrInfo = new ModelMBeanAttributeInfo[] {
idAttrInfo };
ModelMBeanOperationInfo[] operationInfo = new ModelMBeanOperationInfo[]
{};
ModelMBeanInfo info = new
ModelMBeanInfoSupport(RequiredModelMBean.class.getName(),
Widget,
attrInfo,
null,
operationInfo,
null,
descr4);
return info;
}
### AttributeOperationREsolver constructor
11:33:33,020 INFO [STDOUT] !!!m attributes[0]:
ModelMBeanAttributeInfo[Name=Id,Type=java.lang.String,Access=RW,Descript
or(setMethod=setId,descriptorType=attribute,name=Id,displayName=Identificati
on,getMethod=getId)]
### AttributeOperationREsolver.store()
11:33:33,020 INFO [STDOUT] !!!m storing attrName: Id and code: 0
### AttributeOperationREsolver.lookup()
11:34:06,141 INFO [STDOUT] !!!m looking up actionName: getId and signature:
[Ljava.lang.String;@1c87031
### error
java.lang.NoSuchMethodException: Unable to locate method for: getId()
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:300)
at
org.jboss.mx.interceptor.ObjectReferenceInterceptor.invoke(ObjectReferenceIn
terceptor.java:66)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:54)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:91)
at org.jboss.mx.server.MBeanInvoker.invoke(MBeanInvoker.java:79)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:129)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:99)
at
org.jboss.mx.server.MBeanInvoker.getAttribute(MBeanInvoker.java:110)
at
javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBe
an.java:147)
at
org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:455)
at
org.jboss.jmx.adaptor.control.Server.getMBeanAttributeResultInfo(Server.java
:125)
at
org.apache.jsp.inspectMBean_jsp._jspService(inspectMBean_jsp.java:179)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:2
02)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:362)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandl
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha,
do you have operation info for the operation names you are mapping to
(setId getId)?
Nope, and I now see where this causes the problem. At least I'm learning...
Thanks for all the assistance.
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Juha-P Lindfors
Sent: Tuesday, October 01, 2002 12:20 PM
To: JBoss Developers Group
Subject: RE: [JBoss-dev] creating persistent MBeans dynamically
do you have operation info for the operation names you are mapping to
(setId getId)?
On Tue, 1 Oct 2002, Matt Munz wrote:
Juha Group,
make sure you add the getMethod and setMethod mapping to your MMB
attributes.
Thanks. I did this and started re-reading your JMX book. I now have a
new
error :)
Below, I include my MBean Info generation code, and some error output.
When
I try to view the jmx-console page for my new MBean, the servlet tries to
get all of the bean's attributes. The attribute getId is requested, but
this information is stored by the name Id. I assume that there is
something wrong with my MBean info, but I can't figure out what it is.
Error debug output are listed below. Any help would be appreciated.
- Matt
### metadata generation
public ModelMBeanInfo getModelMBeanInfo()
{
final boolean READABLE = true;
final boolean WRITABLE = true;
final boolean BOOLEAN = true;
// build 'Id' read-write attribute
Descriptor descr1 = new DescriptorSupport();
descr1.setField(name, Id);
descr1.setField(descriptorType, attribute);
descr1.setField(displayName, Identification);
descr1.setField(setMethod, setId);
descr1.setField(getMethod, getId);
ModelMBeanAttributeInfo idAttrInfo;
idAttrInfo = new ModelMBeanAttributeInfo(Id,
String.class.getName(),
Identification.,
READABLE,
WRITABLE,
!BOOLEAN,
descr1);
// MBean descriptor
Descriptor descr4 = new DescriptorSupport();
descr4.setField(name, Widget);
descr4.setField(descriptorType, mbean); // was MBean
// create ModelMBeanInfo
ModelMBeanAttributeInfo[] attrInfo = new ModelMBeanAttributeInfo[] {
idAttrInfo };
ModelMBeanOperationInfo[] operationInfo = new
ModelMBeanOperationInfo[]
{};
ModelMBeanInfo info = new
ModelMBeanInfoSupport(RequiredModelMBean.class.getName(),
Widget,
attrInfo,
null,
operationInfo,
null,
descr4);
return info;
}
### AttributeOperationREsolver constructor
11:33:33,020 INFO [STDOUT] !!!m attributes[0]:
ModelMBeanAttributeInfo[Name=Id,Type=java.lang.String,Access=RW,Descript
or(setMethod=setId,descriptorType=attribute,name=Id,displayName=Identificati
on,getMethod=getId)]
### AttributeOperationREsolver.store()
11:33:33,020 INFO [STDOUT] !!!m storing attrName: Id and code: 0
### AttributeOperationREsolver.lookup()
11:34:06,141 INFO [STDOUT] !!!m looking up actionName: getId and
signature:
[Ljava.lang.String;@1c87031
### error
java.lang.NoSuchMethodException: Unable to locate method for: getId()
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat
cher.java:300)
at
org.jboss.mx.interceptor.ObjectReferenceInterceptor.invoke(ObjectReferenceIn
terceptor.java:66)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:54)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:91)
at org.jboss.mx.server.MBeanInvoker.invoke(MBeanInvoker.java:79)
at
org.jboss.mx.interceptor.MBeanAttributeInterceptor.invoke(MBeanAttributeInte
rceptor.java:129)
at
org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceIntercepto
r.java:99)
at
org.jboss.mx.server.MBeanInvoker.getAttribute(MBeanInvoker.java:110)
at
javax.management.modelmbean.RequiredModelMBean.getAttribute(RequiredModelMBe
an.java:147)
at
org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:455)
at
org.jboss.jmx.adaptor.control.Server.getMBeanAttributeResultInfo(Server.java
:125)
at
org.apache.jsp.inspectMBean_jsp._jspService(inspectMBean_jsp.java:179)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha group, It appears that there are two registries available in org.jboss.mx.server.registry. org.jboss.mx.server.ServerConstants seems to indicate that org.jboss.mx.server.registry.BasicMBeanRegistry is the registry that is actually used. Is this the registry that you refer to? What does org.jboss.mx.server.registry.JBossMBeanRegistry do -- is it being used in the server? Also, I'd like to stay as spec-centric as possible. I noticed that MBeanServer has a registerMBean() method. Any reason not to use it? Looking a little further at the spec and the implementation, I'm getting a bit confused, to be honest. I suppose that I need to create a Model MBean using the createMBean() method on MBeanServer. Then I suppose I would set the MBeanInfo (including persistence settings), and call register on the MBean. The only problem here is that the createMBean() method has already registered the bean. Does this mean that I am supposed to directly instantiate the Model MBean? I got the impression that the server was supposed to provide the Model MBean implementation. Am I missing something here? Why isn't there a method createModelMBean(Object modelObject, MBeanInfo info) on MBeanServer? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Friday, September 27, 2002 11:05 PM To: JBoss Developers Group Subject: Re: [JBoss-dev] creating persistent MBeans dynamically make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config info). At registry load() read and recreate mbeans, and then mbeans each load() their state. -- Juha On Fri, 27 Sep 2002, 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https
Re: [JBoss-dev] creating persistent MBeans dynamically
You need to write your own registry implementation. The JBossMBeanRegistry does not automatically add classloaders that happen to be mbeans to the loader repository which the BasicMBeanRegistry does. I believe our implementation of the ModelMBean is the XMBean stuff. Scott Stark Chief Technology Officer JBoss Group, LLC On Monday, September 30, 2002, at 08:08 AM, Matt Munz wrote: Juha group, It appears that there are two registries available in org.jboss.mx.server.registry. org.jboss.mx.server.ServerConstants seems to indicate that org.jboss.mx.server.registry.BasicMBeanRegistry is the registry that is actually used. Is this the registry that you refer to? What does org.jboss.mx.server.registry.JBossMBeanRegistry do -- is it being used in the server? Also, I'd like to stay as spec-centric as possible. I noticed that MBeanServer has a registerMBean() method. Any reason not to use it? Looking a little further at the spec and the implementation, I'm getting a bit confused, to be honest. I suppose that I need to create a Model MBean using the createMBean() method on MBeanServer. Then I suppose I would set the MBeanInfo (including persistence settings), and call register on the MBean. The only problem here is that the createMBean() method has already registered the bean. Does this mean that I am supposed to directly instantiate the Model MBean? I got the impression that the server was supposed to provide the Model MBean implementation. Am I missing something here? Why isn't there a method createModelMBean(Object modelObject, MBeanInfo info) on MBeanServer? - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
Hi Matt, Answers in line. From: Matt Munz [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically Date: Mon, 30 Sep 2002 11:08:40 -0400 Juha group, It appears that there are two registries available in org.jboss.mx.server.registry. org.jboss.mx.server.ServerConstants seems to indicate that org.jboss.mx.server.registry.BasicMBeanRegistry is the registry that is actually used. Is this the registry that you refer to? What does org.jboss.mx.server.registry.JBossMBeanRegistry do -- is it being used in the server? JBossMBeanRegistry is not currently used. MBeanServer.registerMBean() invokes MBeanRegistry.registerMBean() exposing the MBeanRegistry as an MBean has many advantages. Also, I'd like to stay as spec-centric as possible. I noticed that MBeanServer has a registerMBean() method. Any reason not to use it? Looking a little further at the spec and the implementation, I'm getting a bit confused, to be honest. I suppose that I need to create a Model MBean using the createMBean() method on MBeanServer. Then I suppose I would set the MBeanInfo (including persistence settings), and call register on the MBean. The only problem here is that the createMBean() method has already registered the bean. Does this mean that I am supposed to directly instantiate the Model MBean? I got the impression that the server was supposed to provide the Model MBean implementation. Am I missing something here? Why isn't there a method createModelMBean(Object modelObject, MBeanInfo info) on MBeanServer? You can construct/configure the RequiredModelMBean or the XMBean and then register it. The spec does not restrict you to a specific ModelMBean implementation. Regards, Adrian - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Friday, September 27, 2002 11:05 PM To: JBoss Developers Group Subject: Re: [JBoss-dev] creating persistent MBeans dynamically make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config info). At registry load() read and recreate mbeans, and then mbeans each load() their state. -- Juha On Fri, 27 Sep 2002, 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
[JBoss-dev] creating persistent MBeans dynamically
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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] creating persistent MBeans dynamically
make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config info). At registry load() read and recreate mbeans, and then mbeans each load() their state. -- Juha On Fri, 27 Sep 2002, 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] creating persistent MBeans dynamically
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Friday, September 27, 2002 9:08 PM To: [EMAIL PROTECTED] 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
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha, Ok, that sounds cool. I'll try it on Monday. Have a good weekend. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Friday, September 27, 2002 11:05 PM To: JBoss Developers Group Subject: Re: [JBoss-dev] creating persistent MBeans dynamically make the mbean registry persistent (it's already an mbean) triggering store() on registerMBean() calls, and have your widget factory register mbeans using the registry mbean operation registerMBean(Object, ObjectName, Map) where you pass in the valueMap the additional info to store for recreating the mbeans (constructor signature, args, other config info). At registry load() read and recreate mbeans, and then mbeans each load() their state. -- Juha On Fri, 27 Sep 2002, 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
