[JBoss-dev] -service.xml generator
I am thinking about writting an MBean that will generate *-service.xml files for datasources. I see it the following way. - MBean attributes corresponding to values needed to construct -service.xml (such as url, driver, user, password, etc); - XML template with dummy/default values; - XSL stylesheet similar to what David wrote for -ds.xml; - managed operation 'generate' that will transform XML template, probably, mostly substituting dummy values with managed attribute values. Actually, I am looking for a nice way to configure datasources in FoeDeployer but I think it could be useful behind it. Also the same way any -service.xml file can be generated. Any thoughts? Thanks. alex Free Mail http://ua.fm --- 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
Re: [JBoss-dev] -service.xml generator
Alex Loubyansky wrote:
I am thinking about writting an MBean that will generate *-service.xml
files for datasources.
I see it the following way.
- MBean attributes corresponding to values needed to construct
-service.xml (such as url, driver, user, password, etc);
- XML template with dummy/default values;
- XSL stylesheet similar to what David wrote for -ds.xml;
- managed operation 'generate' that will transform XML template,
probably, mostly substituting dummy values with managed attribute values.
Actually, I am looking for a nice way to configure datasources in
FoeDeployer but I think it could be useful behind it.
Also the same way any -service.xml file can be generated.
Any thoughts?
Thanks.
I would strongly recommend using Jelly (from Apache) (found out about it
from Rickard Oberg's weblog). You take your service-xml file and just
replace values you might will need to change with expressions like
${varname}. Then you can run the XML file as a script in Jelly in a
JellyContext in which you set up all the needed variables, say, from the
MBean's attributes. The result of running it through Jelly is XML with
the expressions properly evaluated. (Jelly is a much better replacement
to JSPs and similar things, what is good about it you can run it w/o any
container nonsense). You can also create your custom tag libraries like
in JSPs, though it is much better than JSPs. There is not much
documentation but it is pretty straight forward. Get back to me if you
are having difficulties.
(You would not need XSLT either, actually, I am using Jelly in this way
to automatically reconfigure application components, like EJBs or others
and system-level components, like MBeans. If anyone is interested, I can
share some of that stuff)
Anatoly.
--
-
Anatoly Akkerman
Computer Science Dept.
Courant Institute of Mathematical Sciences, NYU
715 Broadway, #719 Tel: 212 998-3493
New York, NY 10003 Fax: 212 995-4123
-
---
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
Re: [JBoss-dev] -service.xml generator
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.
Thanks.
alex
On Sat, 26 Oct 2002 20:08:08 -0400
Anatoly Akkerman <[EMAIL PROTECTED]> wrote:
Alex Loubyansky wrote:
>I am thinking about writting an MBean that will generate *-service.xml
>files for datasources.
>I see it the following way.
>- MBean attributes corresponding to values needed to construct
>-service.xml (such as url, driver, user, password, etc);
>- XML template with dummy/default values;
>- XSL stylesheet similar to what David wrote for -ds.xml;
>- managed operation 'generate' that will transform XML template,
>probably, mostly substituting dummy values with managed attribute values.
>
>Actually, I am looking for a nice way to configure datasources in
>FoeDeployer but I think it could be useful behind it.
>Also the same way any -service.xml file can be generated.
>
>Any thoughts?
>Thanks.
I would strongly recommend using Jelly (from Apache) (found out about it
from Rickard Oberg's weblog). You take your service-xml file and just
replace values you might will need to change with expressions like
${varname}. Then you can run the XML file as a script in Jelly in a
JellyContext in which you set up all the needed variables, say, from the
MBean's attributes. The result of running it through Jelly is XML with the
expressions properly evaluated. (Jelly is a much better replacement to JSPs
and similar things, what is good about it you can run it w/o any container
nonsense). You can also create your custom tag libraries like in JSPs,
though it is much better than JSPs. There is not much documentation but it
is pretty straight forward. Get back to me if you are having difficulties.
(You would not need XSLT either, actually, I am using Jelly in this way to
automatically reconfigure application components, like EJBs or others and
system-level components, like MBeans. If anyone is interested, I can share
some of that stuff)
Anatoly.
Free Mail http://ua.fm
---
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
Re: [JBoss-dev] -service.xml generator
Hi, Alex 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: parametrized ejb-jar.xml contents go here parametrized jboss-xml contents go here 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
Re: [JBoss-dev] -service.xml generator
Anatoly Akkerman wrote:
Alex Loubyansky wrote:
I am thinking about writting an MBean that will generate
*-service.xml files for datasources.
I see it the following way.
- MBean attributes corresponding to values needed to construct
-service.xml (such as url, driver, user, password, etc);
- XML template with dummy/default values;
- XSL stylesheet similar to what David wrote for -ds.xml;
- managed operation 'generate' that will transform XML template,
probably, mostly substituting dummy values with managed attribute values.
Actually, I am looking for a nice way to configure datasources in
FoeDeployer but I think it could be useful behind it.
Also the same way any -service.xml file can be generated.
Any thoughts?
Thanks.
I would strongly recommend using Jelly (from Apache) (found out about
it from Rickard Oberg's weblog). You take your service-xml file and
just replace values you might will need to change with expressions
like ${varname}. Then you can run the XML file as a script in Jelly in
a JellyContext in which you set up all the needed variables, say, from
the MBean's attributes. The result of running it through Jelly is XML
with the expressions properly evaluated. (Jelly is a much better
replacement to JSPs and similar things, what is good about it you can
run it w/o any container nonsense). You can also create your custom
tag libraries like in JSPs, though it is much better than JSPs. There
is not much documentation but it is pretty straight forward. Get back
to me if you are having difficulties.
(You would not need XSLT either, actually, I am using Jelly in this
way to automatically reconfigure application components, like EJBs or
others and system-level components, like MBeans. If anyone is
interested, I can share some of that stuff)
Anatoly.
Anatoly, I would be interested to know more about how you used it to
automatically reconfigure your application components , so please share
some of that if you can ;-))
thnx
Werner
--
--
ir. Werner Ramaekers
Enterprise Java Solutions Architect - Shift@
Sun Certified Java Programmer - BeJUG steering commitee member
"May the source be with you."
Read my Blog at http://www.werner.be
--
---
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
Re: [JBoss-dev] -service.xml generator
how does what you want differ from the *-ds.xml deployer in 3.2 and 4? It uses a chainable xsl-sub-deployer that transforms dd's on the fly. I suspect there is considerable overlap with the foe-deployer transformation stuff. david jencks On 2002.10.26 09:11:31 -0400 Alex Loubyansky wrote: > I am thinking about writting an MBean that will generate *-service.xml > files > for datasources. > I see it the following way. > - MBean attributes corresponding to values needed to construct > -service.xml > (such as url, driver, user, password, etc); > - XML template with dummy/default values; > - XSL stylesheet similar to what David wrote for -ds.xml; > - managed operation 'generate' that will transform XML template, > probably, > mostly substituting dummy values with managed attribute values. > > Actually, I am looking for a nice way to configure datasources in > FoeDeployer > but I think it could be useful behind it. > Also the same way any -service.xml file can be generated. > > Any thoughts? > Thanks. > > alex > > Free Mail http://ua.fm > > > --- > 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 > > --- 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
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> AA> AA> AA> parametrized ejb-jar.xml contents go here AA> AA> AA> parametrized jboss-xml contents go here AA> AA> AA> 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
Re[4]: [JBoss-dev] -service.xml generator
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> >> AA> >> AA> >> AA> parametrized ejb-jar.xml contents go here >> AA> >> AA> >> AA> parametrized jboss-xml contents go here >> AA> >> AA> >> AA> >> >> 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.s
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> AA> AA> AA> parametrized ejb-jar.xml contents go here AA> AA> AA> parametrized jboss-xml contents go here AA> AA> AA> 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
Re[4]: [JBoss-dev] -service.xml generator
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> >> AA> >> AA> >> AA> parametrized ejb-jar.xml contents go here >> AA> >> AA> >> AA> parametrized jboss-xml contents go here >> AA> >> AA> >> AA> >> >> 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
Re[2]: [JBoss-dev] -service.xml generator
Hello David, DJ> how does what you want differ from the *-ds.xml deployer in 3.2 and 4? just dealing with JMX agent view and not XML files. I think, it would be easier, especially to start, to use some GUI instead of XML. I am not talking about datasources only. Do you really think it's an overlap? DJ> It uses a chainable xsl-sub-deployer that transforms dd's on the fly. I DJ> suspect there is considerable overlap with the foe-deployer transformation DJ> stuff. Not yet. It just transforms DDs and doesn't generate/setup other services like datasources, connection factories and so on. Thanks. alex DJ> david jencks DJ> On 2002.10.26 09:11:31 -0400 Alex Loubyansky wrote: >> I am thinking about writting an MBean that will generate *-service.xml >> files >> for datasources. >> I see it the following way. >> - MBean attributes corresponding to values needed to construct >> -service.xml >> (such as url, driver, user, password, etc); >> - XML template with dummy/default values; >> - XSL stylesheet similar to what David wrote for -ds.xml; >> - managed operation 'generate' that will transform XML template, >> probably, >> mostly substituting dummy values with managed attribute values. >> >> Actually, I am looking for a nice way to configure datasources in >> FoeDeployer >> but I think it could be useful behind it. >> Also the same way any -service.xml file can be generated. >> >> Any thoughts? >> Thanks. -- 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
RE: Re[2]: [JBoss-dev] -service.xml generator
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> > AA> > AA> > AA> parametrized ejb-jar.xml contents go here > AA> > AA> > AA> parametrized jboss-xml contents go here > AA> > AA> > AA> > > 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
RE: Re[2]: [JBoss-dev] -service.xml generator
... and making these changes persistent! ;) 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> > AA> > AA> > AA> parametrized ejb-jar.xml contents go here > AA> > AA> > AA> parametrized jboss-xml contents go here > AA> > AA> > AA> > > 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
RE: Re[4]: [JBoss-dev] -service.xml generator
Alex & group, I've meant to add some MBean persistence docs, but haven't gotten to it yet. IMO, *-service.xml *is* a form of persistence. It represents state of the server that is present after server restart. It is great, flexible, easy to understand, etc., but with all due respect, not overly robust or featureful as a persistence mechanism per se. The MBean persistence mechanism I've implemented includes a default persistence engine that uses Object Streams (derived from an example in Juha's JMX book). As I've mentioned before, this should be supplemented with XML and possibly JDBC versions. Since an Object Stream is not human-readible, I believe it provides a sub-optimal alternative for persistence in this case. As I also mentioned previously, there are several places in the JBoss codebase where text (de)serialization of MBeans occurs. Notably, this includes the *-service.xml reading and jmx-console writing parts of the server. One of the next steps to make MBean persistence widely usable is to re-use this serialization code for the purpose of reading and writing MBean info and MBean state XML. I believe that this code relies on the PropertyEditor mechanism -- a solution which appears to be a good fit for the job. I hope that someone familiar with this code/process might jump into this work. When appropriate for my current work, I'll try to do this myself, but the opportunity may not appear for a while. In the meantime, I'm happy to answer any questions on the subject... - Matt Munz -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Alex Loubyansky Sent: Monday, October 28, 2002 3:26 AM To: Sacha Labourey Subject: Re[4]: [JBoss-dev] -service.xml generator 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> >> AA> >> AA> >> AA> parametrized ejb-jar.xml contents go here >> AA> >> AA> >> AA> parametrized jboss-xml contents go here >> AA> >> AA> >> AA> >> >> AA> Set up the JellyContext for running this script with appropriately >> AA> configured variables (say from a DB of configurations or from >> attributes >> AA&
Re: Re[2]: [JBoss-dev] -service.xml generator
Alex, I'm also curious how this differs from the ServiceBindingManager. I have been using the ServiceBindingManager to put (almost) all of my configuration in a single, fairly simple file. I could give you a short wish list for the ServiceBindingManager, but I don't understand why we need a fourth configuration option in addition to 1) -service.xml files 2) xsl-sub-deployer 3) ServiceBindingManager. Regardless of the path you take, I think an understanding of the ServiceBindingManager would be a good starting point because it does much of what you are suggesting such as seperating out the MBean attribute values from the MBean XML templates. If you're interested, here's my wish list for the ServiceBindingManager. 1. As an option to the XMLServicesStoreFactory, I would like to see a PropertyFileServicesStoreFactory that uses Java property file format instead of XML. The reason for this is that I would like to be able to access some of my JBoss configuration properties in an Ant script. 2. The ability to use the ServiceBindingManager to turn MBeans on or off. 3. Improvements to the AttributeMappingDelegate for setting XML attributes. This would (in my case) completely eliminate the need to ever use the XSLTConfigDelegate. 4. As you suggest, some interaction with a GUI wouldn't hurt, although it is not really needed in my case. Thanks, Matt Cleveland - Original Message - From: "Alex Loubyansky" <[EMAIL PROTECTED]> To: "David Jencks" <[EMAIL PROTECTED]> Sent: Monday, October 28, 2002 12:04 PM Subject: Re[2]: [JBoss-dev] -service.xml generator > Hello David, > > DJ> how does what you want differ from the *-ds.xml deployer in 3.2 and 4? > > just dealing with JMX agent view and not XML files. I think, it > would be easier, especially to start, to use some GUI instead of XML. > I am not talking about datasources only. Do you really think it's an overlap? > > DJ> It uses a chainable xsl-sub-deployer that transforms dd's on the fly. I > DJ> suspect there is considerable overlap with the foe-deployer transformation > DJ> stuff. > > Not yet. It just transforms DDs and doesn't generate/setup other services > like datasources, connection factories and so on. > > Thanks. > > alex > > DJ> david jencks > > DJ> On 2002.10.26 09:11:31 -0400 Alex Loubyansky wrote: > >> I am thinking about writting an MBean that will generate *-service.xml > >> files > >> for datasources. > >> I see it the following way. > >> - MBean attributes corresponding to values needed to construct > >> -service.xml > >> (such as url, driver, user, password, etc); > >> - XML template with dummy/default values; > >> - XSL stylesheet similar to what David wrote for -ds.xml; > >> - managed operation 'generate' that will transform XML template, > >> probably, > >> mostly substituting dummy values with managed attribute values. > >> > >> Actually, I am looking for a nice way to configure datasources in > >> FoeDeployer > >> but I think it could be useful behind it. > >> Also the same way any -service.xml file can be generated. > >> > >> Any thoughts? > >> Thanks. > > > -- > 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
