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
