RE: [JBoss-dev] MBean persistence?
Dain, What is going on with MBean persistence? Not much, as far as I can tell. Can we do this today? Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence engines have yet to be written. If not is anyone working on it? I origionally wrote the code that I did to scratch an itch. As far as I know, nobody else is using it... When do you expect to have it finished? I reccommend not going to production with ObjectOutputStream persistence as it is fragile. By reusing the code from the ServiceCreator (unmarshalling) and the JMX Console (marshalling), the XML persistence engine should be fairly simple to write. - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:42 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] MBean persistence? What is going on with MBean persistence? I have been at lot of sites lately that are going into production with JBoss and the one thing admins always ask for is the ability to have changes to the beans in the JMX console to be written back out the the XML files. They don't care if the formatting changes or if comments are lost, they just want to be able to change and option and have it preserved when the server reboots. I love the practicality of system administrators. Can we do this today? If not is anyone working on it? When do you expect to have it finished? I think this fairly simple feature will make 80% of the admins happy. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat
Re: [JBoss-dev] MBean persistence?
So Matt are you interested in working on the XML persistence? -dain On Monday, January 13, 2003, at 08:32 AM, Matt Munz wrote: Dain, What is going on with MBean persistence? Not much, as far as I can tell. Can we do this today? Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence engines have yet to be written. If not is anyone working on it? I origionally wrote the code that I did to scratch an itch. As far as I know, nobody else is using it... When do you expect to have it finished? I reccommend not going to production with ObjectOutputStream persistence as it is fragile. By reusing the code from the ServiceCreator (unmarshalling) and the JMX Console (marshalling), the XML persistence engine should be fairly simple to write. - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:42 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] MBean persistence? What is going on with MBean persistence? I have been at lot of sites lately that are going into production with JBoss and the one thing admins always ask for is the ability to have changes to the beans in the JMX console to be written back out the the XML files. They don't care if the formatting changes or if comments are lost, they just want to be able to change and option and have it preserved when the server reboots. I love the practicality of system administrators. Can we do this today? If not is anyone working on it? When do you expect to have it finished? I think this fairly simple feature will make 80% of the admins happy. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MBean persistence?
Dain, So Matt are you interested in working on the XML persistence? Yeah, I suppose I could put some more time into it. It sounds like you know a few people that might actually be users of this feature. Do you have a use case in mind? - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 10:07 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? So Matt are you interested in working on the XML persistence? -dain On Monday, January 13, 2003, at 08:32 AM, Matt Munz wrote: Dain, What is going on with MBean persistence? Not much, as far as I can tell. Can we do this today? Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence engines have yet to be written. If not is anyone working on it? I origionally wrote the code that I did to scratch an itch. As far as I know, nobody else is using it... When do you expect to have it finished? I reccommend not going to production with ObjectOutputStream persistence as it is fragile. By reusing the code from the ServiceCreator (unmarshalling) and the JMX Console (marshalling), the XML persistence engine should be fairly simple to write. - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:42 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] MBean persistence? What is going on with MBean persistence? I have been at lot of sites lately that are going into production with JBoss and the one thing admins always ask for is the ability to have changes to the beans in the JMX console to be written back out the the XML files. They don't care if the formatting changes or if comments are lost, they just want to be able to change and option and have it preserved when the server reboots. I love the practicality of system administrators. Can we do this today? If not is anyone working on it? When do you expect to have it finished? I think this fairly simple feature will make 80% of the admins happy. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat
RE: [JBoss-dev] MBean persistence?
Title: Re: [JBoss-dev] MBean persistence? Matt, I think we want seemless integration here. If the MBean is packaged within a SAR, the SAR should be exploded, the XML file modified and the SAR re-jared. Same goes withstraight XML files or SARS embedded withinSARs (russian doll). I'm in the process of creating task lists at SourceForge for each project. I can assign you this task? Thanks for your effort, Bill BurkeChief ArchitectJBoss Group, LLC -Original Message-From: Matt Munz [mailto:[EMAIL PROTECTED]]On Behalf Of Matt MunzSent: Monday, January 13, 2003 10:48 AMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] MBean persistence? Dain, So Matt are you interested in working on the XML persistence? Yeah, I suppose I could put some more time into it. It sounds like you know a few people that might actually be users of this feature. Do you have a use case in mind? - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 10:07 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? So Matt are you interested in working on the XML persistence?-dainOn Monday, January 13, 2003, at 08:32 AM, Matt Munz wrote: Dain, What is going on with MBean persistence? Not much, as far as I can tell. Can we do this today? Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence engines have yet to be written. If not is anyone working on it? I origionally wrote the code that I did to scratch an itch. As far as I know, nobody else is using it... When do you expect to have it finished? I reccommend not going to production with ObjectOutputStream persistence as it is fragile. By reusing the code from the ServiceCreator (unmarshalling) and the JMX Console (marshalling), the XML persistence engine should be fairly simple to write. - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:42 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] MBean persistence? What is going on with MBean persistence? I have been at lot of sites lately that are going into production with JBoss and the one thing admins always ask for is the ability to have changes to the beans in the JMX console to be written back out the the XML files. They don't care if the formatting changes or if comments are lost, they just want to be able to change and option and have it preserved when the server reboots. I love the practicality of system administrators. Can we do this today? If not is anyone working on it? When do you expect to have it finished? I think this fairly simple feature will make 80% of the admins happy. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat---This SF.NET email is sponsored by: FREE SSL Guide from Thawteare you planning your Web Server Security? Click here to get a FREEThawte SSL guide and find the answers to all your SSL security issues.http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en___Jboss-development mailing list[EMAIL PROTECTED]https://lists.sourceforge.net/lists/listinfo/jboss-development attachment: winmail.dat
Re: [JBoss-dev] MBean persistence?
Yes basically. Here is what I have in mind: as each attribute is loaded from the source xml the location from where it was loaded is remembered. When an attribute is changed that was loaded from the xml, the persistence manager overwrites the existing XML. I don't think you have to explode the jar, but I do think you basically have to rewrite the entire file. I think the trick will be to convince the auto deployer to not redeploy the modified file (if you can't figure that out it is ok... I get David J to get it to work :-) Does this sound do-able? -dain On Monday, January 13, 2003, at 09:54 AM, Bill Burke wrote: Matt, I think we want seemless integration here. If the MBean is packaged within a SAR, the SAR should be exploded, the XML file modified and the SAR re-jared. Same goes with straight XML files or SARS embedded within SARs (russian doll). I'm in the process of creating task lists at SourceForge for each project. I can assign you this task? Thanks for your effort, Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: Matt Munz [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Monday, January 13, 2003 10:48 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] MBean persistence? Dain, So Matt are you interested in working on the XML persistence? Yeah, I suppose I could put some more time into it. It sounds like you know a few people that might actually be users of this feature. Do you have a use case in mind? - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 10:07 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? So Matt are you interested in working on the XML persistence? -dain On Monday, January 13, 2003, at 08:32 AM, Matt Munz wrote: Dain, What is going on with MBean persistence? Not much, as far as I can tell. Can we do this today? Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence engines have yet to be written. If not is anyone working on it? I origionally wrote the code that I did to scratch an itch. As far as I know, nobody else is using it... When do you expect to have it finished? I reccommend not going to production with ObjectOutputStream persistence as it is fragile. By reusing the code from the ServiceCreator (unmarshalling) and the JMX Console (marshalling), the XML persistence engine should be fairly simple to write. - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:42 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] MBean persistence? What is going on with MBean persistence? I have been at lot of sites lately that are going into production with JBoss and the one thing admins always ask for is the ability to have changes to the beans in the JMX console to be written back out the the XML files. They don't care if the formatting changes or if comments are lost, they just want to be able to change and option and have it preserved when the server reboots. I love the practicality of system administrators. Can we do this today? If not is anyone working on it? When do you expect to have it finished? I think this fairly simple feature will make 80% of the admins happy. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MBean persistence?
(copied from a message I sent direct to Bill) Bill, I couldn't figure out how to add a comment to the task, so I'm just emailing you. I think we want seemless integration here I think you're integrating apples and oranges ;) What you've described does not match the current behavior of the ObjectStreamPersistenceManager. Are you saying that the jboss-service.xml files should be dynamically modified? I think that this adds unneeded complexity. Here is how I currently use MBean Persistence in my applications. --- jboss-service.xml - describes the initial (deploy-time) configuration of the bean, and the location of the corresponding XMBean descriptor xml. *-xmbean.xml - describes the signature of the metadata for the MBean. Includes the persistence configuration. Specifies the persistence type (ObjectOutputStream) and the persistence store name. /$Persistence_Dir/$Persistence_Store_Name.oos - the file where the MBean Server stores the record of the dynamically changing state of the MBean. --- Exchange XML for ObjectOutputStream and .xml for .oos in the above, and I believe we have a production-ready MBean Persistence mechanism. MBean persistence and MBean deployment are two separate mechanisms/concepts. This separation of concerns is *very* important, IMO, to preserve flexibility and ease-of-use/development. There are all sorts of things that need to go into a deployment descriptor that have little to do with the persistent state of the MBean, and vice versa. Although I see the motivation for a Grand Unified Descriptor, I don't see a rationale for it. I think a use case would really help here. For example, I don't see an individual in the deployment role ever touching the deployed archive. Rather they would use the JMX Console to modify the MBean attributes, which would be recorded in the MBean Persistence Store (XML, JDBC, OOS, whatever), and that would be the extent of their configuration work. In the case of an extreme server failure (uncommon), they could hack the store directly when the server was off-line (XML files, JDBC Tables...). Although this case is relatively uncommon, I believe this is one example where the separation of concerns mentioned above is useful. If I get the server into an inconsistent state and, as a result, it fails at restart (the inconsistency is reloaded), then, I can always delete the Persistence Store. When the server restarts, it returns to a clean-slate (deploy-time) state. If, as you seem to be suggesting, the (inconsistent) state has been stored in the deployment descriptors themselves, however, this clean-slate is not possible. One must go through each descriptor until the erroneous state information is found. Then it must be manually corrected. Since the MBean persistence engine will be writing to these files automatically, it may not be apparent how to do this. Could you explain further the behaviour you would like to see in MBean Persistence? - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Bill Burke Sent: Mon 1/13/2003 10:54 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] MBean persistence? Matt, I think we want seemless integration here. If the MBean is packaged within a SAR, the SAR should be exploded, the XML file modified and the SAR re-jared. Same goes with straight XML files or SARS embedded within SARs (russian doll). I'm in the process of creating task lists at SourceForge for each project. I can assign you this task? Thanks for your effort, Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: Matt Munz [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Monday, January 13, 2003 10:48 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] MBean persistence? Dain, So Matt are you interested in working on the XML persistence? Yeah, I suppose I could put some more time into it. It sounds like you know a few people that might actually be users of this feature. Do you have a use case in mind? - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 10:07 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence
RE: [JBoss-dev] MBean persistence?
Dain, Please see my recent email in response to Bill. I origionally started with this approach, but the more I thought about it, the more untenable it seemed. Based on my experience so far, I just don't want the server mucking with my deployment descriptors. I'm sure I can figure out the autodeployer ;) But look what you're saying. Implement Persistence, modify deployer. Do you see how the two concerns are being tightly bound by this approach? We don't need AOP to solve this one ;) -- just locate the persistence in a separate place (this is what it wants to do anyway, IMO -- consider standalone applications. I've never seen an application open up its jars and stuff info into them. They always use a separate DB). BTW, I want to relocate this discussion to the Forums, as Bill suggests, but which one? I see at least 3 JMX-related forums! - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 11:38 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? Yes basically. Here is what I have in mind: as each attribute is loaded from the source xml the location from where it was loaded is remembered. When an attribute is changed that was loaded from the xml, the persistence manager overwrites the existing XML. I don't think you have to explode the jar, but I do think you basically have to rewrite the entire file. I think the trick will be to convince the auto deployer to not redeploy the modified file (if you can't figure that out it is ok... I get David J to get it to work :-) Does this sound do-able? -dain On Monday, January 13, 2003, at 09:54 AM, Bill Burke wrote: Matt, I think we want seemless integration here. If the MBean is packaged within a SAR, the SAR should be exploded, the XML file modified and the SAR re-jared. Same goes with straight XML files or SARS embedded within SARs (russian doll). I'm in the process of creating task lists at SourceForge for each project. I can assign you this task? Thanks for your effort, Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: Matt Munz [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Monday, January 13, 2003 10:48 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] MBean persistence? Dain, So Matt are you interested in working on the XML persistence? Yeah, I suppose I could put some more time into it. It sounds like you know a few people that might actually be users of this feature. Do you have a use case in mind? - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 10:07 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? So Matt are you interested in working on the XML persistence? -dain On Monday, January 13, 2003, at 08:32 AM, Matt Munz wrote: Dain, What is going on with MBean persistence? Not much, as far as I can tell. Can we do this today? Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence engines have yet to be written. If not is anyone working on it? I origionally wrote the code that I did to scratch an itch. As far as I know, nobody else is using it... When do you expect to have it finished? I reccommend not going to production with ObjectOutputStream persistence as it is fragile. By reusing the code from the ServiceCreator (unmarshalling) and the JMX Console (marshalling), the XML persistence engine should be fairly simple to write. - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:42 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] MBean persistence? What is going on with MBean persistence
Re: [JBoss-dev] MBean persistence?
always delete the Persistence Store. When the server restarts, it returns to a clean-slate (deploy-time) state. If, as you seem to be suggesting, the (inconsistent) state has been stored in the deployment descriptors themselves, however, this clean-slate is not possible. One must go through each descriptor until the erroneous state information is found. Then it must be manually corrected. Since the MBean persistence engine will be writing to these files automatically, it may not be apparent how to do this. Could you explain further the behaviour you would like to see in MBean Persistence? - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Bill Burke Sent: Mon 1/13/2003 10:54 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] MBean persistence? Matt, I think we want seemless integration here. If the MBean is packaged within a SAR, the SAR should be exploded, the XML file modified and the SAR re-jared. Same goes with straight XML files or SARS embedded within SARs (russian doll). I'm in the process of creating task lists at SourceForge for each project. I can assign you this task? Thanks for your effort, Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: Matt Munz [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Monday, January 13, 2003 10:48 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] MBean persistence? Dain, So Matt are you interested in working on the XML persistence? Yeah, I suppose I could put some more time into it. It sounds like you know a few people that might actually be users of this feature. Do you have a use case in mind? - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 10:07 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? So Matt are you interested in working on the XML persistence? -dain On Monday, January 13, 2003, at 08:32 AM, Matt Munz wrote: Dain, What is going on with MBean persistence? Not much, as far as I can tell. Can we do this today? Yes, but only by persisting to ObjectOutputStream files. XML / JDBC persistence engines have yet to be written. If not is anyone working on it? I origionally wrote the code that I did to scratch an itch. As far as I know, nobody else is using it... When do you expect to have it finished? I reccommend not going to production with ObjectOutputStream persistence as it is fragile. By reusing the code from the ServiceCreator (unmarshalling) and the JMX Console (marshalling), the XML persistence engine should be fairly simple to write. - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Sat 1/11/2003 1:42 PM To: [EMAIL PROTECTED] Cc: Subject: [JBoss-dev] MBean persistence? What is going on with MBean persistence? I have been at lot of sites lately that are going into production with JBoss and the one thing admins always ask for is the ability to have changes to the beans in the JMX console to be written back out the the XML files. They don't care if the formatting changes or if comments are lost, they just want to be able to change and option and have it preserved when the server reboots. I love the practicality of system administrators. Can we do this today? If not is anyone working on it? When do you expect to have it finished? I think this fairly simple feature will make 80% of the admins happy. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat --- This SF.NET email is sponsored by: FREE
RE: [JBoss-dev] MBean persistence?
Title: Re: [JBoss-dev] MBean persistence? Like Matt, I have concerns about modifying the files in the deployment as well. I think his concerns about division of roles are valid - I'd go further and say this needs to be able to handle a split between 'deployer' and 'operator/sys admin' as well (where e.g. deployer defines which database to use, the sys admin defines the connection pool size). There are also circumstances where the SAR will be unmodifyable - e.g. if it is set read-only on the OS or if it is loaded from an http: URL. One possibility might be to store the local changes as a transform applied against the original file e.g. an XSLT. This also has the advantage that local changes don't get lost whena new version is received from development. Also the same file can be rolled dev-test-stage-prod without needing to modify the deployment descriptor each time (one of the biggest compaints I've had from sys admins). -Original Message-From: Matt Munz [mailto:[EMAIL PROTECTED]]On Behalf Of Matt MunzSent: Monday, January 13, 2003 8:47 AMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] MBean persistence? (copied from a message I sent direct to Bill) Bill, I couldn't figure out how to add a comment to the task, so I'm just emailing you. I think we want seemless integration here I think you're integrating apples and oranges ;) What you've described does not match the current behavior of the ObjectStreamPersistenceManager. Are you saying that the jboss-service.xml files should be dynamically modified? I think that thisadds unneeded complexity. Here is how I currently use MBean Persistence in my applications. --- jboss-service.xml - describes the initial (deploy-time) configuration of the bean, and the location of the corresponding XMBean descriptor xml. *-xmbean.xml - describes the signature of the metadata for the MBean. Includes the persistence configuration. Specifies the persistence type (ObjectOutputStream) and the persistence store name. /$Persistence_Dir/$Persistence_Store_Name.oos - the file where the MBean Server stores the record of the dynamically changing state of the MBean. --- Exchange XML for ObjectOutputStream and .xml for .oos in the above, and I believe we have a production-ready MBean Persistence mechanism. MBean persistence and MBean deployment are two separate mechanisms/concepts. This separation of concerns is *very* important, IMO, to preserve flexibility and ease-of-use/development. There are all sorts of things that need to go into a deployment descriptor that have little to do with the persistent state of the MBean, and vice versa. Although I see the motivation for a "Grand Unified Descriptor", I don't see a rationale for it. I think a use case would really help here. For example, I don't see an individual in the "deployment" role ever touching the deployedarchive. Ratherthey would use the JMX Console to modify theMBean attributes, which would be recorded in the MBean Persistence Store (XML, JDBC, OOS, whatever), and that would be the extent of their configuration work. In the case of an extreme server failure (uncommon), they could hack the store directly when the server was off-line (XML files, JDBC Tables...). Although this case is relatively uncommon, I believe this is one example where the separation of concerns mentioned above is useful. If I get the server into an inconsistent state and, as a result, it fails at restart (the inconsistency is reloaded), then, I can always delete the Persistence Store. When the server restarts,it returns to a clean-slate (deploy-time) state. If,as you seem to be suggesting, the(inconsistent)state has been stored in the deployment descriptors themselves,however, this clean-slate is not possible. One must go through eachdescriptor until the erroneous state information is found. Then it must be manually corrected. Since the MBean persistence engine will be writing to these files automatically, it may not be apparent how to do this. Could you explain further the behaviour you would like to see in MBean Persistence? - Matt attachment: winmail.dat
Re: [JBoss-dev] MBean persistence?
On Monday, January 13, 2003, at 11:26 AM, Matt Munz wrote: Dain, Please see my recent email in response to Bill. Yes. I think sf is creating a big lag between our emails. I origionally started with this approach, but the more I thought about it, the more untenable it seemed. Based on my experience so far, I just don't want the server mucking with my deployment descriptors. I understand, but the admins do want this. As a developers, I won't be turing this feature on. As an admin, I most likely will. I'm sure I can figure out the autodeployer ;) But look what you're saying. Implement Persistence, modify deployer. Do you see how the two concerns are being tightly bound by this approach? Yes. If you modify a descriptor the auto deployer will have to be modified to not redeploy the file. Right? Am I missing something? We don't need AOP to solve this one ;) -- just locate the persistence in a separate place (this is what it wants to do anyway, IMO -- consider standalone applications. I've never seen an application open up its jars and stuff info into them. They always use a separate DB). I agree AOP is not required. I also I think we need this in 3.x. BTW, I want to relocate this discussion to the Forums, as Bill suggests, but which one? I see at least 3 JMX-related forums! Sure but you will most likely loose my comments. The server is s slow that I quickly loose interest in posting. Hopefully the new hardware will fix this problem. -dian --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MBean persistence?
Simpler console for common tasks The administrator the power of the JMX console, and think it is cool they can change the behavior of the entire system. On the other hand they are overwhelmed by the options. Most would like a very simple static interface that does 80% of the common tasks and the option to fire-up the full console for hard core hacking sessions. Basically they would like a static interface similar to the one supplied by Weblogic and JRun. (I have some ideas here if anyone is interested in working on this.) FYI I've commited such a framework and a basic implementation in HEAD two weeks ago: http://www.jboss.org/modules.php?op=modloadname=phpBB_14file=indexaction= viewtopictopic=267852 There's even a screen snapshot --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
I love you sacha! I can't seem to find the screen shot. I'll see if I can get this working on my apple. -dain On Monday, January 13, 2003, at 11:39 AM, Sacha Labourey wrote: Simpler console for common tasks The administrator the power of the JMX console, and think it is cool they can change the behavior of the entire system. On the other hand they are overwhelmed by the options. Most would like a very simple static interface that does 80% of the common tasks and the option to fire-up the full console for hard core hacking sessions. Basically they would like a static interface similar to the one supplied by Weblogic and JRun. (I have some ideas here if anyone is interested in working on this.) FYI I've commited such a framework and a basic implementation in HEAD two weeks ago: http://www.jboss.org/ modules.php?op=modloadname=phpBB_14file=indexaction= viewtopictopic=267852 There's even a screen snapshot --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MBean persistence?
The new forum software doesn't support attachements, which is why. Try again: I've added it as an img link. http://www.jboss.org/modules.php?op=modloadname=phpBB_14file=indexaction= viewtopictopic=26785 -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Dain Sundstrom Envoye : lundi, 13 janvier 2003 18:51 A : [EMAIL PROTECTED] Objet : Re: [JBoss-dev] MBean persistence? I love you sacha! I can't seem to find the screen shot. I'll see if I can get this working on my apple. -dain On Monday, January 13, 2003, at 11:39 AM, Sacha Labourey wrote: Simpler console for common tasks The administrator the power of the JMX console, and think it is cool they can change the behavior of the entire system. On the other hand they are overwhelmed by the options. Most would like a very simple static interface that does 80% of the common tasks and the option to fire-up the full console for hard core hacking sessions. Basically they would like a static interface similar to the one supplied by Weblogic and JRun. (I have some ideas here if anyone is interested in working on this.) FYI I've commited such a framework and a basic implementation in HEAD two weeks ago: http://www.jboss.org/ modules.php?op=modloadname=phpBB_14file=indexaction= viewtopictopic=267852 There's even a screen snapshot --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
Jeremy, Specific comments are inline... On Monday, January 13, 2003, at 11:33 AM, Jeremy Boynes wrote: Like Matt, I have concerns about modifying the files in the deployment as well. I think his concerns about division of roles are valid - I'd go further and say this needs to be able to handle a split between 'deployer' and 'operator/sys admin' as well (where e.g. deployer defines which database to use, the sys admin defines the connection pool size). Every place has a different distinction between what a developer and an admin does. At some places the developers defines the entire db pool, at some the developer really only specifiec the pool name, and there are places in between the two. I am not making the claim that this is the solution for everyone, especially developers. I am saying that the average admin wants this feature. There are also circumstances where the SAR will be unmodifyable - e.g. if it is set read-only on the OS or if it is loaded from an http: URL. If a attribute is not persistable, then we don't persist it. We should modify the jmx-console to notify the user if an attribute is persistent or not. One possibility might be to store the local changes as a transform applied against the original file e.g. an XSLT. There are very few developers that understand XSLT, I would guess even less admins. This also has the advantage that local changes don't get lost when a new version is received from development. Also the same file can be rolled dev-test-stage-prod without needing to modify the deployment descriptor each time (one of the biggest compaints I've had from sys admins). The admins I spoke with were willing to accept this. It is a common problem. When I give them the option of looking in multiple places, or looking in some database, or dealing with lost config options across upgades, they all chose the last. I personally would have gone for the second option, but I'm not an admin. -dain --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
Our admin here thinks that Dain is spot on with this analysis. From: Dain Sundstrom [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Mon, 13 Jan 2003 11:27:07 -0600 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] MBean persistence? Matt, I have meet with many system administrators over the past few months, so I'll try to support their opinion. If there are any admins on this list, please speak up. Simpler console for common tasks The administrator the power of the JMX console, and think it is cool they can change the behavior of the entire system. On the other hand they are overwhelmed by the options. Most would like a very simple static interface that does 80% of the common tasks and the option to fire-up the full console for hard core hacking sessions. Basically they would like a static interface similar to the one supplied by Weblogic and JRun. (I have some ideas here if anyone is interested in working on this.) Persistence in general -- The real problem they see with the JMX console is it does not save changes. Almost unamiously, they find the console useless because the changes are not persistent. They usually say that it is a good developer debugging tool but don't think it will work for administration. Persistence back to the original file - When I get to the above point, I always ask the admins how they would like the configuration information stored, and everyone has said they want the original file modified (some suggest a rolling backup first). They especially don't want this information stored in a binary format or in a database because it makes the configuration way to hard to get to. These are text editor (vi and emacs) guys, and binary simply doesn't cut it. When I suggest that we could write out a new different xml file that has the configuration changes, they all hated it. They want to be able to goto one file and know what is going on. I really just want to make 80% of the admins happy and I truly believe that this is the answer, but I admit I could be wrong. As for a use case... Say that database connection are being dropped by the database server way before the specified JBoss stale connection timeout. The admin wants to go into the running servers via the web JMX-console and reduce the max connection length. Once they change this setting in the console they want it to be permanent. They realize that when the developers release a new version the changes may be overwritten but they can deal with that, as production changes almost never live beyond a version. I hope I have represented the admins well. What do you think of this solution? -dain On Monday, January 13, 2003, at 10:46 AM, Matt Munz wrote: (copied from a message I sent direct to Bill) Bill, I couldn't figure out how to add a comment to the task, so I'm just emailing you. I think we want seemless integration here I think you're integrating apples and oranges ;) What you've described does not match the current behavior of the ObjectStreamPersistenceManager. Are you saying that the jboss-service.xml files should be dynamically modified? I think that this adds unneeded complexity. Here is how I currently use MBean Persistence in my applications. --- jboss-service.xml - describes the initial (deploy-time) configuration of the bean, and the location of the corresponding XMBean descriptor xml. *-xmbean.xml - describes the signature of the metadata for the MBean. Includes the persistence configuration. Specifies the persistence type (ObjectOutputStream) and the persistence store name. /$Persistence_Dir/$Persistence_Store_Name.oos - the file where the MBean Server stores the record of the dynamically changing state of the MBean. --- Exchange XML for ObjectOutputStream and .xml for .oos in the above, and I believe we have a production-ready MBean Persistence mechanism. MBean persistence and MBean deployment are two separate mechanisms/concepts. This separation of concerns is *very* important, IMO, to preserve flexibility and ease-of-use/development. There are all sorts of things that need to go into a deployment descriptor that have little to do with the persistent state of the MBean, and vice versa. Although I see the motivation for a Grand Unified Descriptor, I don't see a rationale for it. I think a use case would really help here. For example, I don't see an individual in the deployment role ever touching the deployed archive. Rather they would use the JMX Console to modify the MBean attributes, which would be recorded in the MBean Persistence Store (XML, JDBC, OOS, whatever), and that would be the extent of their configuration work. In the case of an extreme server failure (uncommon), they could hack the store directly when the server was off-line (XML
RE: [JBoss-dev] MBean persistence?
Dain, First off, thank you for providing much-needed field data for this work. Your comments on Persistence in general are identical to my reasons for working on MBean Persistence in the first place. When I suggest that we could write out a new different xml file that has the configuration changes, they all hated it. They want to be able to goto one file and know what is going on. Why do they want this specifically? It is important to take customer concerns and turn them into needs. Consider cooking at a restaurant. If the customer orders chocolate cake and you don't have it, do you bake a cake just because they want it? Perhaps we can give the sys admins chocolat pots de creme instead? They might even like it better... The admins I spoke with were willing to accept this. It is a common problem. When I give them the option of looking in multiple places, or looking in some database, or dealing with lost config options across upgades, they all chose the last. I personally would have gone for the second option, but I'm not an admin. I don't see the options this way. Losing stored MBean state across upgrades may end up being an application-specific detail at best. If the MBeans change, then the stored MBean state will likely be out of synch, regardless of where that state is stored. I don't see this as related to the issue of whether or not the mbean state store and the deployment descriptor should be merged. They want to be able to goto one file and know what is going on. Could you elaborate on this? Why would they be looking at files at all? I think we are running into a bit of a jam here, conceptually. They say they want to use the console to make persistent changes. Do they also want to use the filesystem to make changes? Two interfaces for the same device -- are they requesting any others? Why would they hack config files if they have the handy dandy console? ;) I can think of many possible answers to these questions, but how would the sys admins answer them? Please stick with me on this one. I think that if we can develop a solid use case for these things, we can get to some of the core issues, and perhaps you'll understand my rationale. The use case that you gave before is completely solved by my approach, BTW. Perhaps answering the questions above will help generate a use case that shows why two files is worse than one... - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 1:01 PM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? Jeremy, Specific comments are inline... On Monday, January 13, 2003, at 11:33 AM, Jeremy Boynes wrote: Like Matt, I have concerns about modifying the files in the deployment as well. I think his concerns about division of roles are valid - I'd go further and say this needs to be able to handle a split between 'deployer' and 'operator/sys admin' as well (where e.g. deployer defines which database to use, the sys admin defines the connection pool size). Every place has a different distinction between what a developer and an admin does. At some places the developers defines the entire db pool, at some the developer really only specifiec the pool name, and there are places in between the two. I am not making the claim that this is the solution for everyone, especially developers. I am saying that the average admin wants this feature. There are also circumstances where the SAR will be unmodifyable - e.g. if it is set read-only on the OS or if it is loaded from an http: URL. If a attribute is not persistable, then we don't persist it. We should modify the jmx-console to notify the user if an attribute is persistent or not. One possibility might be to store the local changes as a transform applied against the original file e.g. an XSLT. There are very few developers that understand XSLT, I would guess even less admins. This also has the advantage that local changes don't get lost when a new version is received from development. Also the same file can be rolled dev-test-stage-prod without needing to modify the deployment descriptor each time (one of the biggest compaints I've had from sys admins). The admins I spoke with were willing to accept this. It is a common problem. When I give them the option of looking in multiple places, or looking in some database, or dealing with lost config options across
Re: [JBoss-dev] MBean persistence?
On Monday, January 13, 2003, at 01:26 PM, Matt Munz wrote: Dain, First off, thank you for providing much-needed field data for this work. Your comments on Persistence in general are identical to my reasons for working on MBean Persistence in the first place. When I suggest that we could write out a new different xml file that has the configuration changes, they all hated it. They want to be able to goto one file and know what is going on. Why do they want this specifically? It is important to take customer concerns and turn them into needs. Consider cooking at a restaurant. If the customer orders chocolate cake and you don't have it, do you bake a cake just because they want it? Perhaps we can give the sys admins chocolat pots de creme instead? They might even like it better... Good point. To extend you analogy, if the customer wants a hamburger you don't give them cordon bleu, just because you think they will like it better (which they would :). The admins I spoke with were willing to accept this. It is a common problem. When I give them the option of looking in multiple places, or looking in some database, or dealing with lost config options across upgades, they all chose the last. I personally would have gone for the second option, but I'm not an admin. I don't see the options this way. Losing stored MBean state across upgrades may end up being an application-specific detail at best. If the MBeans change, then the stored MBean state will likely be out of synch, regardless of where that state is stored. I don't see this as related to the issue of whether or not the mbean state store and the deployment descriptor should be merged. Ok. How do you see the options? The point about the upgrade problem not being related to the MBean persistence method, I would state as *not necessarily related*. Certain persistence schemes will necessarily create an upgrade problem and some can mitigate it. They want to be able to goto one file and know what is going on. Could you elaborate on this? Why would they be looking at files at all? I think we are running into a bit of a jam here, conceptually. They say they want to use the console to make persistent changes. Do they also want to use the filesystem to make changes? Two interfaces for the same device -- are they requesting any others? Why would they hack config files if they have the handy dandy console? ;) Yes. They want it both ways. Some admins hate consoles, and some hate config files. A lot of times you have two admins, one that can't handle file configs and one that can't stand GUIs (even web GUIs). Anyway having a single config file has a big advantage, portability. You can check it into CVS, you can copy it to another machine. You can configure it with the GUI undeploy the admin screen (security and all) and still be able to config the system with vi. I can think of many possible answers to these questions, but how would the sys admins answer them? Please stick with me on this one. I think that if we can develop a solid use case for these things, we can get to some of the core issues, and perhaps you'll understand my rationale. The use case that you gave before is completely solved by my approach, BTW. Perhaps answering the questions above will help generate a use case that shows why two files is worse than one... I understand your point, and I suggest you go talk with some full time admins, or better watch them work for a day. It will be an eye opener. One file is a huge benefit to admins. There is nothing worse then picking through the config files, changing something and it has no effect. Then 8 hours to 1 week later you discover that the file is ignored if there is an override somewhere else in the system. Hey, I'm not an admin, and when a whole bunch of them at different companies tell me they want it a very specific way, I say lets do it. The solution the propose is very simple from a user perspective, as they get it both ways. I don't expect this to be the only solution or the default solution, but it should be an option. I just want to make the admins happy. -dain --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MBean persistence?
Dain, I like your give-them-what-they-want attitude. Rest assured that I am *very* aware of config file hell and am likewise motivated to avoid complexity. Please note that the current XMBean deployment involves at least *two* config files already. If the goal is to have only one, then perhaps the XMBean descriptor needs to be merged with jboss-service.xml? Ok. How do you see the options? To be honest, there are too many possibilities to enumerate here. Yes. They want it both ways. Some admins hate consoles, and some hate config files. A lot of times you have two admins, one that can't handle file configs and one that can't stand GUIs (even web GUIs). Sure. Well, the text guys are ok about the status quo, right? Or do they want a text-based dynamic interface to the JMX Server? ;) Anyway having a single config file has a big advantage, portability. Hmm. So you're saying that one file is more portable than two? I'm not sure that I buy that, especially if they are colocated or otherwise linked. In fact, when one big file with two distinct parts is separated into two files, I think it becomes *more* portable because it allows one to move only the relevant file, if needed. You can check it into CVS, you can copy it to another machine. Again, CVS is happy to take 2...n files. These are attributes of all files AFAIK. You can configure it with the GUI undeploy the admin screen (security and all) and still be able to config the system with vi. Now here is the beginning of a relevant use case. One admin uses the GUI, another uses the file system exclusively. We need to keep them in synch, right? GuiGuy browses the web to the relevant bean and modifies an attribute. The server then saves that to the persistence store. FileSystemGuy then browses the filesystem to the persistence store for that bean and also makes a change. On XMBean.load(), that change takes effect. Just as there is only one url for each mbean, there is one file system location for the record of its state. GuiGuy knows just where to look, and so does FileSystemGuy. So where's the beef? Yeah, FileSystemGuy may be used to looking at jboss-service.xml, but he doesn't have to look there anymore (Yea!). The *only* place he needs to go for server state records is the persistence store. State information in jboss-service.xml is thus used for default (deploy-time) values only. This is not confusing (at least not to me). I may not be explaining it correctly, however, so feel free to throw some questions my way. Hey, I'm not an admin, and when a whole bunch of them at different companies tell me they want it a very specific way, I say lets do it. I just don't agree with this at all. Your way right away may work at Burger King, but I don't think it works for creating lasting software. You're not an admin, but they're not software architects either. I fully respect this point of view, but also respectfully disagree. What if they all wanted to jump off a bridge? ;) If this approach is required, then perhaps someone else should take this task. The existing architecture aupports multiple persistence managers anyway... - Matt -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 2:59 PM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? On Monday, January 13, 2003, at 01:26 PM, Matt Munz wrote: Dain, First off, thank you for providing much-needed field data for this work. Your comments on Persistence in general are identical to my reasons for working on MBean Persistence in the first place. When I suggest that we could write out a new different xml file that has the configuration changes, they all hated it. They want to be able to goto one file and know what is going on. Why do they want this specifically? It is important to take customer concerns and turn them into needs. Consider cooking at a restaurant. If the customer orders chocolate cake and you don't have it, do you bake a cake just because they want it? Perhaps we can give the sys admins chocolat pots de creme instead? They might even like it better... Good point. To extend you analogy, if the customer wants a hamburger you don't give them cordon bleu, just because you think they will like it better (which they would :). The admins I spoke with were willing to accept this. It is a common problem. When I give them the option of looking in multiple places, or looking in some database, or dealing with lost config options
Re: [JBoss-dev] MBean persistence?
This should not be a black and white option. We need a logical seperation from configuration from the deployment at the JBoss core layer. If someone wants to persist configuration with the deployment, including runtime mods let them. If someone wants to access webdav, jdbc, jndi, etc. for the configuration, let them. Quit being purists and address the administration problem. This does need to be in 3.2. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 13, 2003 11:59 AM Subject: Re: [JBoss-dev] MBean persistence? ... --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MBean persistence?
Scott, Thanks. I think the common point to both strategies is the MBean - XML serializer. I'll get started on that. For what date is the 3.2 release planned? - Matt -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 5:07 PM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? This should not be a black and white option. We need a logical seperation from configuration from the deployment at the JBoss core layer. If someone wants to persist configuration with the deployment, including runtime mods let them. If someone wants to access webdav, jdbc, jndi, etc. for the configuration, let them. Quit being purists and address the administration problem. This does need to be in 3.2. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 13, 2003 11:59 AM Subject: Re: [JBoss-dev] MBean persistence? ... --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat
Re: [JBoss-dev] MBean persistence?
When it looks worth putting out. I was thinking the end of the month but given that I'm training the entire last week it won't be until the first week of Feb. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Matt Munz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 13, 2003 2:38 PM Subject: RE: [JBoss-dev] MBean persistence? Scott, Thanks. I think the common point to both strategies is the MBean - XML serializer. I'll get started on that. For what date is the 3.2 release planned? - Matt -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 5:07 PM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? This should not be a black and white option. We need a logical seperation from configuration from the deployment at the JBoss core layer. If someone wants to persist configuration with the deployment, including runtime mods let them. If someone wants to access webdav, jdbc, jndi, etc. for the configuration, let them. Quit being purists and address the administration problem. This does need to be in 3.2. Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
It should be developed in 4.0 and migrated to 3.2. It does not need to be in the initial release. It does need to be migrated into 3.2. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 13, 2003 3:39 PM Subject: RE: [JBoss-dev] MBean persistence? Matt, please don't rush this into 3.2 I think the 3.x series should be frozen for funtionality except in the case of a paying customer. We should start pushing for 4.0 Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Monday, January 13, 2003 6:30 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] MBean persistence? When it looks worth putting out. I was thinking the end of the month but given that I'm training the entire last week it won't be until the first week of Feb. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Matt Munz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 13, 2003 2:38 PM Subject: RE: [JBoss-dev] MBean persistence? Scott, Thanks. I think the common point to both strategies is the MBean - XML serializer. I'll get started on that. For what date is the 3.2 release planned? - Matt -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Mon 1/13/2003 5:07 PM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] MBean persistence? This should not be a black and white option. We need a logical seperation from configuration from the deployment at the JBoss core layer. If someone wants to persist configuration with the deployment, including runtime mods let them. If someone wants to access webdav, jdbc, jndi, etc. for the configuration, let them. Quit being purists and address the administration problem. This does need to be in 3.2. Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
What if changes to the DeploymentScanner was made to reflect : file - DeploymentScanner - Mbean jmx-console - DeploymentScanner - Mbean and file Then adding writes inside russian dolls could/should also revolve around the DeploymentScanner as hub. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
I'm not sure if you agree with my proposal or not. Do you think we should add the feature to persist the changes back out to the deployment descriptors? -dain On Monday, January 13, 2003, at 04:07 PM, Scott M Stark wrote: This should not be a black and white option. We need a logical seperation from configuration from the deployment at the JBoss core layer. If someone wants to persist configuration with the deployment, including runtime mods let them. If someone wants to access webdav, jdbc, jndi, etc. for the configuration, let them. Quit being purists and address the administration problem. This does need to be in 3.2. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 13, 2003 11:59 AM Subject: Re: [JBoss-dev] MBean persistence? ... --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
I'm saying this should be supported, but not the only mechanism for persisting configuration. The configuration could be completely outside of the deployment and loaded through an external store. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 13, 2003 8:22 PM Subject: Re: [JBoss-dev] MBean persistence? I'm not sure if you agree with my proposal or not. Do you think we should add the feature to persist the changes back out to the deployment descriptors? -dain On Monday, January 13, 2003, at 04:07 PM, Scott M Stark wrote: This should not be a black and white option. We need a logical seperation from configuration from the deployment at the JBoss core layer. If someone wants to persist configuration with the deployment, including runtime mods let them. If someone wants to access webdav, jdbc, jndi, etc. for the configuration, let them. Quit being purists and address the administration problem. This does need to be in 3.2. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 13, 2003 11:59 AM Subject: Re: [JBoss-dev] MBean persistence? ... --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
lördagen den 11 januari 2003 kl 19.42 skrev Dain Sundstrom: anyone working on it? When do you expect to In some sidesteps projects here ... it is easy when hsqldb is up ... or in a grid ... when one master is up to have configurations federated. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
