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
