On Wednesday, January 28, 2015 at 9:45:04 AM UTC-5, jcbollinger wrote: > > > > On Tuesday, January 27, 2015 at 9:36:35 AM UTC-6, Dave Jablonski wrote: >> >> I am trying to generate separate jndi.xml files for a mule_config module >> I'm building. Current setup: >> >> > > Much of what you say seems quite reasonable, but bits of it are enough off > to make me scratch my head, starting with the title's reference to > non-nesting. How would nested defined types help here anyway? In any > case, do note that consensus best practice is to avoid nesting defined > types or other classes inside classes, too. Each class or defined type > should reside in its own file. >
Yes, thank you. I have moved all the defined types inside their own files at this point. May be moot since I like your doing the logic in the template suggestion. > > > >> Filesystem setup: >> /opt/mule-instance-a/conf/jndi.xml >> /opt/mule-instance-b/conf/jndi.xml >> etc, etc >> >> >> >> > I'm not sure I follow why you need a different template for each > instance. I suppose it must mean that the target contents differ in > structure, so that you could not transform one to the other simply by > substituting one set of data for another. In that case, however, you are > still generating all the content of each file from input data of the same > form, so it's unclear what the issue is. > That's correct. For each mule container it has a complete different set of queues needed and db connections. Though now that you mention it, it may make more sense to use loops in the template then to use concat to create the file. I will go that route and see how it works. > > > Structure your data so that they are suitable for a general template to > use to create your jndi.xml. Use nested hashes and/or arrays to model > repeatable elements where the number of repeats varies from one instance to > another. Use Ruby loops in your template to transform those repeated data > into repeated JNDI elements. Your module will be much simpler and more > reliable, and yet your data -- though perhaps structured differently -- > will be no more complex than you already envision. > > Yes, thank you, will do. Appreciate the direction. > > John > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9ad754c5-beb9-43f6-8531-2f298ccdbd34%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
