Alex & group, I've meant to add some MBean persistence docs, but haven't gotten to it yet. IMO, *-service.xml *is* a form of persistence. It represents state of the server that is present after server restart. It is great, flexible, easy to understand, etc., but with all due respect, not overly robust or featureful as a persistence mechanism per se.
The MBean persistence mechanism I've implemented includes a default persistence engine that uses Object Streams (derived from an example in Juha's JMX book). As I've mentioned before, this should be supplemented with XML and possibly JDBC versions. Since an Object Stream is not human-readible, I believe it provides a sub-optimal alternative for persistence in this case. As I also mentioned previously, there are several places in the JBoss codebase where text (de)serialization of MBeans occurs. Notably, this includes the *-service.xml reading and jmx-console writing parts of the server. One of the next steps to make MBean persistence widely usable is to re-use this serialization code for the purpose of reading and writing MBean info and MBean state XML. I believe that this code relies on the PropertyEditor mechanism -- a solution which appears to be a good fit for the job. I hope that someone familiar with this code/process might jump into this work. When appropriate for my current work, I'll try to do this myself, but the opportunity may not appear for a while. In the meantime, I'm happy to answer any questions on the subject... - Matt Munz -----Original Message----- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Alex Loubyansky Sent: Monday, October 28, 2002 3:26 AM To: Sacha Labourey Subject: Re[4]: [JBoss-dev] -service.xml generator Hello Sacha, I thought about it too. As alternative or other implementation of MBean persistence. Though, I am not familiar with MBean persistence stuff yet. Are they meant to be serialized as java objects? I think, having MBeans persisted in xml form is much better. Because I can see what is persisted and change something manually. alex Monday, October 28, 2002, 10:06:36 AM, you wrote: SL> Hello, SL> Exactly, it may help to solve one of the current biggest issue wrt SL> configuration: any configuration done through any GUI (or mbean, etc.) is not persisted =>> only transient configuration can be started remotly or SL> programatically. Having a generic way to build new persisted mbean SL> definition is important. SL> But we spoke about this on this ML a few weeks ago and we still have some SL> issues wrt "implicit" dependencies. Anyway, we need a way to persist SL> configuration that is currently only transient. SL> cheers, SL> Sacha >> -----Message d'origine----- >> De : [EMAIL PROTECTED] >> [mailto:jboss-development-admin@;lists.sourceforge.net]De la part de Alex >> Loubyansky >> Envoye : lundi, 28 octobre 2002 07:17 >> A : Anatoly Akkerman >> Objet : Re[2]: [JBoss-dev] -service.xml generator >> >> >> Anatoly, this looks cool and draws other perspectives. I'm in thought. >> >> Any other thoughts/comments? >> Thanks. >> >> alex >> >> Sunday, October 27, 2002, 4:07:15 PM, you wrote: >> >> AA> Hi, Alex >> >> AA> Jelly would give you similar ease of use but without having >> to write any >> AA> XSL. You would initialize the JellyContext by creating in >> first and then >> AA> setting variables in it from attributes like this: >> AA> ctx.setVariable(name, value); >> >> AA> (values can be any Java objects) >> >> AA> you load your modified *-service.xml script from a URL into Jelly and >> AA> run it as a script in the context which you just set up. The >> result of >> AA> this operation is XML again. >> >> AA> This is simplest usage of Jelly. You do need a library, though, and >> AA> possibly, not one but a bunch from jakarta-commons. >> >> AA> I am using Jelly in a slightly more advanced fashion. I wrote >> a few very >> AA> simple tags that allow output of Jelly to be a jar file. >> Something like: >> AA> <j:jelly xmlns:j="jelly:core" xmlns:zipper="jelly:mypackage.MyTagLib"> >> AA> <zipper:zip> >> AA> <zipper:entry name="META-INF/ejb-jar.xml" > >> AA> parametrized ejb-jar.xml contents go here >> AA> </zipper:entry> >> AA> <zipper:entry name="META-INF/jboss.xml" > >> AA> parametrized jboss-xml contents go here >> AA> </zipper:entry> >> AA> </zipper:zip> >> AA> </j:jelly> >> >> AA> Set up the JellyContext for running this script with appropriately >> AA> configured variables (say from a DB of configurations or from >> attributes >> AA> of an MBean). Run the script in the context. >> AA> After running this script, the JellyContext contains a Jar >> archive (as a >> AA> byte[] stored under some variable name) of reconfigured descriptors. >> >> AA> The way I use it is to have a servlet that parses its path >> request and >> AA> deduces from the path request which script to run and which >> AA> configuration to pull from storage. The servlet outputs either XML or >> AA> JAR depending on the requested module and its script. >> >> AA> So, you can just point the JBoss deployer to deploy a URL of the kind: >> >> AA> myservlet/componentA/configX.jar >> AA> or >> AA> myservlet/serviceB/configY.xml >> AA> and the servlet automatically generates properly configured jar or xml >> AA> which the Deployer happily deploys. >> >> AA> Jelly has many usages this is just what I could come up with. >> It would >> AA> be more than adequate for what you need to do, but if you are >> AA> dissatisfied with JBoss library dependency growth, then, >> Jelly is out of >> AA> the picture. >> >> AA> Alex Loubyansky wrote: >> >> Thanks, Anatoly. I'll check it. Also I thought about Velocity which >> >> looks similar to Jelly from your description, though I am not familiar >> >> with the last one. >> >> >> >> Could you, please, look at the following idea with XML/XSL, compare it >> >> with Jelly and give your opinion? >> >> - before transformation, each MBean's attribute is set as a >> parameter to >> >> the Transformer with Transformer.setParameter(...) with the name equal >> >> to the corresponding parameter name used in XSL stylesheet; >> >> - transform XML template with Transformer and XSL stylesheet. >> >> >> >> As for me, XML/XSL requires two templates (XML and XSL) while >> >> Jelly/Velocity requires only one. >> >> >> >> Also, I wouldn't add any thirdparty library unless it really >> helps. The >> >> JBoss becomes so heavy. I think it's problem. >> >> >> -- >> Best regards, >> Alex Loubyansky >> >> >> >> >> ------------------------------------------------------- >> 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 >> -- Best regards, Alex Loubyansky ------------------------------------------------------- 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
