(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,
XXXXXXXXXXXXXXXX
Bill Burke
Chief Architect
JBoss Group, LLC
XXXXXXXXXXXXXXXX
-----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>>
