Re: chain in trunk for builds?
On Tue, 23 Nov 2004 09:30:20 -0800, Martin Cooper wrote: struts-chain is in struts/sandbox/trunk, yes, and it will likely be moved into struts/core/trunk as part of Struts 1.3. However, since we instituted a policy of not depending on any other components that are unreleased, that's not going to happen until Commons Chain is released - which is exactly why I'm pushing to get that released. ;-) I agree that we should roll a release before changing a dependency. Case in point is rolling 1.2.6 *before* moving to the next release Commons Validator. I also agree that we should roll and release before making a major change to the code base. Case in point is getting a stable 1.2.x line before adding Chain in 1.3.x. Since we are at 1.3.0 (dot-zero), and that Chain is *the* 1.3 feature, I would have no qualms in using a 0.x build from Commons Chain. As a practical matter, I don't think any of us are going to +1 a 1.3.x release until we sort out Commons Chain, so bringing in a pre-GA chain is not going to hold us up. We've released everything else we have checked-in to date, so there is nothing to lose. (As contrast to 1.1, where we started making significant internal changes *before* releasing other code that had been checked-in for months.) In practice, adding a Chain dependency to core it is more likely to help us along, especially now that we are having API discussions regarding Chain. On the Chain thread, I'm going to suggest that we roll a 0.2.0 release of what we have, before considering any API changes. This will also give a JAR that Struts can use now. We could then also look at making changes to the API and compare them to the 0.2.0 Chain baseline. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: chain in trunk for builds?
Vic wrote: I think Martin said chain is in trunk. I would assume that the nighly bulids would then have chain in there, and that it not be a separate download? .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: chain in trunk for builds?
repost I think Martin said chain is in trunk. I would assume that the nighly bulids would then have chain in there, and that it not be a separate download? .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: chain in trunk for builds?
The Struts nightly build contains whatever the result of running ant clean dist in the struts/core/trunk directory produces. Until now, that hasn't included Struts Chain, but that's easy to fix. In the mean time, there is a nightly build of Struts Chain being produced separately: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/ that you can grab the code from. It is created by running ant clean dist in the struts/sandbox/trunk/struts-chain directory. Craig On Tue, 23 Nov 2004 09:07:02 -0600, Vic Cekvenich [EMAIL PROTECTED] wrote: Vic wrote: I think Martin said chain is in trunk. I would assume that the nighly bulids would then have chain in there, and that it not be a separate download? .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: chain in trunk for builds?
I think Martin said chain is in trunk. I would assume that the nighly bulids would then have chain in there, and that it not be a separate download? Chain is not yet in the core, but getting it there is something I'm interested in working on. It may also be just as well to wait a few days until commons-chain 1.0 is formally released. Meanwhile, I am still looking for more feedback on some of my questions. I'm restating/clarifying them below. Items two and three seem the most controversial. [1] Chain initialization: Pending any objection, I would remove the need for the ChainConfiguratorPlugIn and instead have the ActionServlet receive an init parameter, chains which would be one or more (comma-separated) paths to XML files. I would follow Don's recent changes so that each path would be tested first as a servlet resource, and, if that failed, as a classpath resource. If a URL were found in either source, it would be passed to o.a.s.chain.config.ConfigParser.parse(URL) If a URL were found in neither source, a ServletUnavailableException would be thrown. [2] RequestProcessor Configuration: In the current ChainConfiguratorPlugIn, the catalog name and initial command are settable with servlet init parameters. It seems to me that this should be a per-Module setting, and so I'd argue those should be properties on the RequestProcessor. This is not a high priority to me, but it seems more right. To achieve this would require either adding yet more properties to ControllerConfig or, my preferred solution, allowing ControllerConfig to hold a reference to an actual RequestProcessor object which could be instantiated and configured by Digester. (Would this involve some ClassLoader issues? the Struts digester instance uses the contextClassLoader when it has been set, as does RequestUtils.applicationInstance(...) so perhaps not a great risk?) I guess the alternative would be a RequestProcessorConfig object that carried the properties -- but this is an example of where I would rather turn away from the config objects and towards something more IoC-like... The other question here is simply whether to change the behavior of the class named RequestProcessor (probably copying the current behavior to a LegacyRequestProcessor) or rather to change the default class used to point to a new class which implements the Chain-based processing. [3] Default Chain Do we import all the classes in struts-chain into core? Or do we pack them as a jar and use them by reference? Based on our stated interest in reducing core dependencies on the Servlet API, I would argue for the first. If we did the first, I think it would be interesting (but low priority) to consider a mechanism for including the chain-config.xml in the JAR and having it be auto-discovered. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex
Re: chain in trunk for builds?
On Tue, 23 Nov 2004 09:07:02 -0600, Vic Cekvenich [EMAIL PROTECTED] wrote: Vic wrote: I think Martin said chain is in trunk. Huh? No, I don't think so... struts-chain is in struts/sandbox/trunk, yes, and it will likely be moved into struts/core/trunk as part of Struts 1.3. However, since we instituted a policy of not depending on any other components that are unreleased, that's not going to happen until Commons Chain is released - which is exactly why I'm pushing to get that released. ;-) -- Martin Cooper I would assume that the nighly bulids would then have chain in there, and that it not be a separate download? .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: chain in trunk for builds?
Comments inline... Joe Germuska wrote: I think Martin said chain is in trunk. I would assume that the nighly bulids would then have chain in there, and that it not be a separate download? Chain is not yet in the core, but getting it there is something I'm interested in working on. It may also be just as well to wait a few days until commons-chain 1.0 is formally released. Meanwhile, I am still looking for more feedback on some of my questions. I'm restating/clarifying them below. Items two and three seem the most controversial. [1] Chain initialization: Pending any objection, I would remove the need for the ChainConfiguratorPlugIn and instead have the ActionServlet receive an init parameter, chains which would be one or more (comma-separated) paths to XML files. I would follow Don's recent changes so that each path would be tested first as a servlet resource, and, if that failed, as a classpath resource. If a URL were found in either source, it would be passed to o.a.s.chain.config.ConfigParser.parse(URL) If a URL were found in neither source, a ServletUnavailableException would be thrown. Sounds good. I would take it a step further, and, if no init parameter, look for the chain config as /chain-config.xml, making it possible to provide an intelligent default. We could then, take your idea in #3, and bundle our own /chain-config.xml inside Struts. Since it would be on the classpath, it could still be easily overridden by creating a chain-config.xml in the servlet context w/o adding any configuration to web.xml. [2] RequestProcessor Configuration: In the current ChainConfiguratorPlugIn, the catalog name and initial command are settable with servlet init parameters. It seems to me that this should be a per-Module setting, and so I'd argue those should be properties on the RequestProcessor. This is not a high priority to me, but it seems more right. Works for me. To achieve this would require either adding yet more properties to ControllerConfig or, my preferred solution, allowing ControllerConfig to hold a reference to an actual RequestProcessor object which could be instantiated and configured by Digester. (Would this involve some ClassLoader issues? the Struts digester instance uses the contextClassLoader when it has been set, as does RequestUtils.applicationInstance(...) so perhaps not a great risk?) I guess the alternative would be a RequestProcessorConfig object that carried the properties -- but this is an example of where I would rather turn away from the config objects and towards something more IoC-like... The other question here is simply whether to change the behavior of the class named RequestProcessor (probably copying the current behavior to a LegacyRequestProcessor) or rather to change the default class used to point to a new class which implements the Chain-based processing. I like for former. We continue to use RequestProcessor, but deprecate it, and make LegacyRequestProcessor the default. This allows Struts extensions to make the transition easier. Don [3] Default Chain Do we import all the classes in struts-chain into core? Or do we pack them as a jar and use them by reference? Based on our stated interest in reducing core dependencies on the Servlet API, I would argue for the first. If we did the first, I think it would be interesting (but low priority) to consider a mechanism for including the chain-config.xml in the JAR and having it be auto-discovered. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: chain in trunk for builds?
On Tue, 23 Nov 2004 09:58:11 -0800, Don Brown [EMAIL PROTECTED] wrote: Sounds good. I would take it a step further, and, if no init parameter, look for the chain config as /chain-config.xml, making it possible to provide an intelligent default. We could then, take your idea in #3, and bundle our own /chain-config.xml inside Struts. Since it would be on the classpath, it could still be easily overridden by creating a chain-config.xml in the servlet context w/o adding any configuration to web.xml. Maybe default to /WEB-INF/chain-config.xml instead? That way the developer can easily provide overrides by dropping a chain-config.xml file into /WEB-INF, without making the chain configuration a publicly available static file that can be retrieved by a browser (which would be the case if it was in the top-level directory of the WAR). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: chain in trunk for builds?
The other question here is simply whether to change the behavior of the class named RequestProcessor (probably copying the current behavior to a LegacyRequestProcessor) or rather to change the default class used to point to a new class which implements the Chain-based processing. I like for former. We continue to use RequestProcessor, but deprecate it, and make LegacyRequestProcessor the default. This allows Struts extensions to make the transition easier. When I said copy, I meant copy o.a.s.action.RequestProcessor to o.a.s.action.LegacyRequestProcessor, but of course that's a no-go, because any classes which extend it (including ComposableRequestProcessor) would be knocked out of whack. I clearly wasn't thinking. I think it would probably be adequate to move the ComposableRequestProcessor into struts-core (changing the name or package if appropriate) and making it the default classname returned by ControllerConfig.getProcessorClass: /** * The fully qualified class name of the RequestProcessor implementation * class to be used for this module. */ protected String processorClass = org.apache.struts.action.RequestProcessor; Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
