Yes. And by the way there are to ways. The first is MBean persistence. The second is changing the app's DDs themself. As I understand right, Anatoly uses the last one.
alex Monday, October 28, 2002, 11:46:57 AM, you wrote: SL> ... and making these changes persistent! ;) SL> Yes, that would be really cool >> -----Message d'origine----- >> De : [EMAIL PROTECTED] >> [mailto:jboss-development-admin@;lists.sourceforge.net]De la part de Alex >> Loubyansky >> Envoye : lundi, 28 octobre 2002 10:03 >> A : Anatoly Akkerman >> Objet : Re[2]: [JBoss-dev] -service.xml generator >> >> >> I am thinking about this stuff of reconfiguring and redeployment. >> It would be cool to have metadata of the deployed apps to be exposed >> for modifications through jmx-console. And not only for changing >> existing attributes but adding some resource references etc. >> Then one can modify some stuff and redeploy the app. >> >> 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
