Jelly would give you similar ease of use but without having to write any XSL. You would initialize the JellyContext by creating in first and then setting variables in it from attributes like this:
ctx.setVariable(name, value);
(values can be any Java objects)
you load your modified *-service.xml script from a URL into Jelly and run it as a script in the context which you just set up. The result of this operation is XML again.
This is simplest usage of Jelly. You do need a library, though, and possibly, not one but a bunch from jakarta-commons.
I am using Jelly in a slightly more advanced fashion. I wrote a few very simple tags that allow output of Jelly to be a jar file. Something like:
<j:jelly xmlns:j="jelly:core" xmlns:zipper="jelly:mypackage.MyTagLib">
<zipper:zip>
<zipper:entry name="META-INF/ejb-jar.xml" >
parametrized ejb-jar.xml contents go here
</zipper:entry>
<zipper:entry name="META-INF/jboss.xml" >
parametrized jboss-xml contents go here
</zipper:entry>
</zipper:zip>
</j:jelly>
Set up the JellyContext for running this script with appropriately configured variables (say from a DB of configurations or from attributes of an MBean). Run the script in the context.
After running this script, the JellyContext contains a Jar archive (as a byte[] stored under some variable name) of reconfigured descriptors.
The way I use it is to have a servlet that parses its path request and deduces from the path request which script to run and which configuration to pull from storage. The servlet outputs either XML or JAR depending on the requested module and its script.
So, you can just point the JBoss deployer to deploy a URL of the kind:
myservlet/componentA/configX.jar
or
myservlet/serviceB/configY.xml
and the servlet automatically generates properly configured jar or xml
which the Deployer happily deploys.
Jelly has many usages this is just what I could come up with. It would be more than adequate for what you need to do, but if you are dissatisfied with JBoss library dependency growth, then, Jelly is out of the picture.
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.
------------------------------------------------------- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development