Re: [Proposal] Resurrecting storeconfig
Hi. I do not understand about StoreConfig well, but I have a question. As long as I read the code (r1442161), I think that storeconfig() seem to trigger a redeployment of Web applications. For example, new context.xml will be created when testApp/META-INF/context.xml is stored. And redeployment of this new context.xml will be done by HostConfig. Is this a design ? I think better that storeconfig () does not trigger a redeployment of the Web application. 2013/2/4 jean-frederic clere jfcl...@gmail.com: On 02/01/2013 09:47 PM, Remy Maucherat wrote: On Fri, 2012-12-14 at 17:26 +, Mark Thomas wrote: One issue I'm wondering about is the build system. After all that time, I've starting using Maven instead of Ant (unbelievable, I know ...), and while I am fine continuing using existing Ant build systems, I find adding ones to newer components quite useless. It shouldn't be too hard to add another JAR to the existing Ant build. Once the code is in place, I'm happy to take a look. I have ported it to trunk, where it builds as lib/catalina-storeconfig.jar. Should I commit it ? Yes please. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Keiichi.Fujino - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Resurrecting storeconfig
On Tue, 2013-02-05 at 19:27 +0900, Keiichi Fujino wrote: Hi. I do not understand about StoreConfig well, but I have a question. As long as I read the code (r1442161), I think that storeconfig() seem to trigger a redeployment of Web applications. For example, new context.xml will be created when testApp/META-INF/context.xml is stored. And redeployment of this new context.xml will be done by HostConfig. Is this a design ? I think better that storeconfig () does not trigger a redeployment of the Web application. Yes, storeconfig will saved these (settings could have been changed). Then the deployer sees the updated descriptor, and it redeploys the webapp. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Resurrecting storeconfig
On 02/01/2013 09:47 PM, Remy Maucherat wrote: On Fri, 2012-12-14 at 17:26 +, Mark Thomas wrote: One issue I'm wondering about is the build system. After all that time, I've starting using Maven instead of Ant (unbelievable, I know ...), and while I am fine continuing using existing Ant build systems, I find adding ones to newer components quite useless. It shouldn't be too hard to add another JAR to the existing Ant build. Once the code is in place, I'm happy to take a look. I have ported it to trunk, where it builds as lib/catalina-storeconfig.jar. Should I commit it ? Yes please. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Resurrecting storeconfig
On Fri, 2012-12-14 at 17:26 +, Mark Thomas wrote: One issue I'm wondering about is the build system. After all that time, I've starting using Maven instead of Ant (unbelievable, I know ...), and while I am fine continuing using existing Ant build systems, I find adding ones to newer components quite useless. It shouldn't be too hard to add another JAR to the existing Ant build. Once the code is in place, I'm happy to take a look. I have ported it to trunk, where it builds as lib/catalina-storeconfig.jar. Should I commit it ? Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Proposal] Resurrecting storeconfig
Hi, I would be willing to start maintaining again storeconfig, along with Jean-Frédéric. So after a hiatus, we would be able to bring back this functionality which allows tweaking the configuration (through JMX in particular) and then saving it to server.xml and context.xml files to make changes survive a restart. On the downside, storeconfig in Tomcat will always remain an introspection based system prone to (very rare, hopefully) failures and some unhandled special cases, a artifact of Tomcat's rather freeform configuration files. The proposal would be to move storeconfig7/trunk from the sandbox to modules/storeconfig in the Tomcat 7 branch [a port to trunk, aka Tomcat 8, would be coming shortly, since I believe its container API would now start to be more stable]. I don't recall Tomcat 6 having modules, so I don't see where storeconfig6 would live there, and as a result I propose leaving it in the sandbox. One issue I'm wondering about is the build system. After all that time, I've starting using Maven instead of Ant (unbelievable, I know ...), and while I am fine continuing using existing Ant build systems, I find adding ones to newer components quite useless. Comments ? Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Resurrecting storeconfig
On 14/12/2012 13:36, Remy Maucherat wrote: Hi, I would be willing to start maintaining again storeconfig, along with Jean-Frédéric. Nice. That is a really useful feature. Great to see it (and you) back. So after a hiatus, we would be able to bring back this functionality which allows tweaking the configuration (through JMX in particular) and then saving it to server.xml and context.xml files to make changes survive a restart. On the downside, storeconfig in Tomcat will always remain an introspection based system prone to (very rare, hopefully) failures and some unhandled special cases, a artifact of Tomcat's rather freeform configuration files. Indeed. As those issues appear we can look to see how best to address them. The proposal would be to move storeconfig7/trunk from the sandbox to modules/storeconfig in the Tomcat 7 branch [a port to trunk, aka Tomcat 8, would be coming shortly, since I believe its container API would now start to be more stable]. :) Merging Engine and Service are still on the Tomcat 8 TODO list but I'm increasingly coming to the view that it isn't worth doing. It would break lots of existing stuff and the benefit of the merge is marginal. The other largish looking changes (e.g. web.xml parsing) shouldn't impact much / at all on StoreConfig. How far away is the trunk version? I don't recall Tomcat 6 having modules, so I don't see where storeconfig6 would live there, and as a result I propose leaving it in the sandbox. We could create a modules in tc6.0.x/trunk One of your changes that I have really come to appreciate over the years is the single source tree. What was your reasoning for adding it in modules rather than the main source tree? One issue I'm wondering about is the build system. After all that time, I've starting using Maven instead of Ant (unbelievable, I know ...), and while I am fine continuing using existing Ant build systems, I find adding ones to newer components quite useless. It shouldn't be too hard to add another JAR to the existing Ant build. Once the code is in place, I'm happy to take a look. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Resurrecting storeconfig
On Fri, 2012-12-14 at 17:26 +, Mark Thomas wrote: The proposal would be to move storeconfig7/trunk from the sandbox to modules/storeconfig in the Tomcat 7 branch [a port to trunk, aka Tomcat 8, would be coming shortly, since I believe its container API would now start to be more stable]. :) Merging Engine and Service are still on the Tomcat 8 TODO list but I'm increasingly coming to the view that it isn't worth doing. It would break lots of existing stuff and the benefit of the merge is marginal. The other largish looking changes (e.g. web.xml parsing) shouldn't impact much / at all on StoreConfig. How far away is the trunk version? I didn't try porting or testing with trunk yet, but I don't expect it to be too difficult if the big changes were deferred. I thought they had already been done in trunk actually, I should have looked at the code I guess. I don't recall Tomcat 6 having modules, so I don't see where storeconfig6 would live there, and as a result I propose leaving it in the sandbox. We could create a modules in tc6.0.x/trunk One of your changes that I have really come to appreciate over the years is the single source tree. What was your reasoning for adding it in modules rather than the main source tree? There's a module for the JDBC pool in Tomcat 7, so I figured storeconfig could be a new module there, it did sound logical. But a JDBC pool is certainly more independent of Tomcat than storeconfig. If officially bringing it back to Tomcat 6 as well, maybe it could be in the main tree since creating a new modules location just for it is not going to be so nice. Having zillions of source trees is quite trendy these days, with Maven to glue all the pieces together. I find it harder to work with it though, and using Ant it is just quite crazy. So I guess there are benefits and issues. So either option is fine with me, it could be merged in the main tree, or it could be a module. Either way, it could create its own jar. One issue I'm wondering about is the build system. After all that time, I've starting using Maven instead of Ant (unbelievable, I know ...), and while I am fine continuing using existing Ant build systems, I find adding ones to newer components quite useless. It shouldn't be too hard to add another JAR to the existing Ant build. Once the code is in place, I'm happy to take a look. Yes, it should not be too hard. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
