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
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
... 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[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: 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[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
