Hello,
Exactly, it may help to solve one of the current biggest issue wrt
configuration: any configuration done through any GUI (or mbean, etc.) is
not persisted => only transient configuration can be started remotly or
programatically. Having a generic way to build new persisted mbean
definition is important.
But we spoke about this on this ML a few weeks ago and we still have some
issues wrt "implicit" dependencies. Anyway, we need a way to persist
configuration that is currently only transient.
cheers,
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
>
-------------------------------------------------------
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
