For #2, you might want to try your hand at creating your own config module: http://terracotta.org/confluence/display/integrations/Home Break your tc-config into several modules by grouping the instrumentations that belong together into a module by themselves...
For #4, not exactly a best-practice, but you might want to take a look at any one of the POJO samples run script. The BootJarTool tries to validate if it's out of sync with the current configuration and recreates the bootjar as necessary. On Sep 25, 2007, at 4:30 PM, Prasad Bopardikar wrote: > 1. Can we make run time changes to the tc-config.xml? > We have built a platform on which we deploy various > applications (kinda like deploying war files in Tomcat). We will > have a tc-config for the platform-application. I was wondering if > we deploy applications on this platform, can we modify the tc- > config.xml at runtime? Can it generate a new dso-boot-jar at run time? > > 2. Can we break tc-config into multiple xml files - like spring > config? A spring config (xml) can source other xml files - Can > Terracotta do the same with tc-config.xml? > > 3. Is there ANY difference in the boot jar created on Windows & > Linux - except the name? > > 4. Are there any best practices that can be followed for boot jar > creation? Currently, we create the boot jar using make-boot-jar.sh > towards the beginning of the script that launches our app (TC client). > > 5. We use Maven for our builds. Is the Terracotta-Maven-Plugin only > meant for creating boot jar, starting DSO server to enable running > tests while doing MVN INSTALL? Does it do anything more? > > Thanks in advance > > > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
