RE: Anyone Got a Servlet 2.3 handy for Struts Upload Build?
At 9:35 AM + 11/23/04, Roberto Tyley wrote: I'd say the best way to get a copy of the Servlet 2.3 jar is to download the Tomcat 4 binary (which uses Servlet API 2.3): You can also download servlet API jars from: http://www.ibiblio.org/maven/servletapi/jars/ Joe http://jakarta.apache.org/site/binindex.cgi#tomcat-4 The servlet.jar can be found here: jakarta-tomcat-4.1.31\common\lib\servlet.jar If you want to have a nice set of matching source code for your servlet.jar, get the source to Tomcat 5 and build the stuff you find under this folder: jakarta-tomcat-5.0.28-src\jakarta-servletapi-5\jsr152 Hope this helps! Roberto (sitting behind a low-bandwidth connection and not about to e-mail stuff anywhere...!) -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: 23 November 2004 05:40 To: Struts Developers List Subject: Anyone Got a Servlet 2.3 handy for Struts Upload Build? I am trying to build 1_2_6 and Struts upload requires something prior to Servlet 2.4. Does someone have a Servlet 2.2 or 2.3 around that I can use for the build? I would appreciate that. Just email it, if you do and would like to donate tot he cause. I really don't want to go searching around for an entire j2ee for the one file. Thanks for any help ahead of time. Jack -- -- Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex
Re: Experiences with MockObjects for Servlet testing?
At 4:44 PM -0800 11/22/04, Martin Cooper wrote: On Mon, 22 Nov 2004 16:28:32 -0800, Don Brown [EMAIL PROTECTED] wrote: Perhaps this might be a good time to bring up the idea of bringing StrutsTestCase as a Struts subproject? They have an implementation of the servlet api for testing. Also, someone (Howard?) mentioned at ApacheCon that ServletUnit is a good, stable, full-featured framework for testing, well, servlet-based code. I'd like us to take a look at that before we make any hard decisions about testing frameworks. I thought I knew, but then when I went investigating, I ran into the question of just what (or which) is servletunit? There's a fairly dormant Sourceforge Project: http://servletunit.sourceforge.net/ where code is in the package com.kizna.servletunit It's the top-level package for StrutsTestCase: http://strutstestcase.sourceforge.net/api/index.html HTTPUnit has a servletunit package (com.meterware.servletunit): http://httpunit.sourceforge.net/doc/api/index.html I think one (or more) of these might be as good or better as having Cactus tests in Struts as a whole -- but I still would prefer to use MockObjects for the kind of isolated testing I was trying to do with the CreateAction yesterday, so as to minimize the amount of extraneous setup required. That is, I'd prefer to use MockObjects if it worked for the test I needed. I suppose if we were using a mock servlet environment, I might be able to use components from it without having to simulate an entire Struts installation. (I see that the ServletContextSimulator in StrutsTestCase simply returns null for an attribute which isn't in the servlet context, which would be all I needed...) Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex
DO NOT REPLY [Bug 32358] New: - Having one LookupDispatchAction mapping two Submit buttons with different actionKeys to two different Methods having equal Discription in Application.resources - always the first key ist used
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32358. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32358 Summary: Having one LookupDispatchAction mapping two Submit buttons with different actionKeys to two different Methods having equal Discription in Application.resources - always the first key ist used Product: Struts Version: 1.1RC2 Platform: PC OS/Version: Windows 95 Status: NEW Severity: normal Priority: P5 Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] $Id: README,v 1.16 2002/03/21 02:57:24 craigmcc Exp $ Having one LookupDispatchAction mapping two Submit buttons with different actionKeys to two different Methods having equal Description in Application.resources - always the first key ist used struts_conf.xml action name=DummyForm path=/backwardActionType parameter=action type=de.i2dm.action.BackwardDispatchAction forward name=SuccessBasic path=/page1.jsp / forward name=SuccessEdit path=/page2.jsp / /action SUBMIT on different pages html:form action=backwardActionType html:submit property=action bean:message key=button.one/ /html:submit /html:form AND html:form action=backwardActionType html:submit property=action bean:message key=button.two/ /html:submit /html:form ApplicationResource button.one=back button.two=back LookupDispatchAction map.put(button.one,proc_one); map.put(button.two,proc_two); Submit takes alway button.one because button.one and button.two have the same desciption in Application.resources and button.one stands first in the list. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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: Configuration and IoC (Re: Proposed Roadmap for 1.3.x and beyond [long])
Don Brown wrote: When you start looking at configuration for defining procedures, it can get messy quick - just look at Jelly. Many would argue XML is just not a good fit for procedural code/definitions. Good argument. Even if you liked XML for procedural configuration, I'm not sure chain's dtd would be a good idea either. I think Chain XML files are self describing, you can put in ANY properties, as long as it's valid XML. (so it's not a real DTD, it's open). It only can only be used to define a linear process - no braches, loops, or iterations. Instead, you'd have to code that logic inside your commands, further complicating them and making it even harder to deduce flow. Great argument, same point as above. When developers wrote something for me, it was harder to follow. Personally, I like the approach of using XML to define items, then letting how those items are processed be defined with chain or whatever else. Even then, I like using chain and CoR for defining one pretty static process like how Struts That is a good practice, Agree. handles requests, but leaving it up to Java or scripting languages for defining more dynamic, complex processes. Inversion of Control, however, is really a different beast as it seeks neither to define processes or conceptual elements, but rather *configures* actual classes which may be different. Key word is configures. You can configure chain and commands a lot in XML same as IoC and random proerties, declare xml elments in xml... (I do have chain dispatching based on a DispatchCommand that looks at the string passed, and then executes that Command from the Catalog, a bit like LookupDispatchAction- I think that's what its called) Adding IoC jar would add complexity for users (sometimes you use IoC, sometimes you use CoR - harder to teach), Struts would be heavyier (like Spring is popular, but they have 2 of everything in there). Struts I would like to be a light C (of MVC). Now back up. I agree that declaration is a good practice and process in XML is a bad practice BUT users should be allowed to use Struts wrong. No 2 Struts production are the same out there. So just becuase you can put your rope arround your neck in chain xml should not prevent user chains. I think once ActionCommand() is released, then it will be easier to see issues. On another topic, when convinient, try to keep Context clear of View API, so that many views are supported. (like formbean knows nothing of DAO) For example if we can have same UserAction that a user wrote be able to hanlde TilesAction request(5 arguments), Portlet requests, Jabber Request, JMS request, JSF request, etc. Imagine a user has a TilesAction or regular actions and updates to Struts v1.4. Then... same action... supports Portlet (or SoA in my case). Not sure how this would work out but... For what ever reason Struts is very DAO agnostic, but somehow Servlet API is in there. (I do not need JDBC to build Struts). Of course without breaking HTML tag. :-) In general Saint Something- st augstine said: perfection is achived not when you have nothing more to add, but when you have nothing more to remove .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
Chain enhancement idea
How would plugins work with the chain configuration? I've written ActionServlet/RequestProcessor extensions and plugins in the past. Often, the reason is to inject custom pre-, actual, or post-processing at specific steps. An example would Tiles, which IIRC intercepts the forward processing to see if the destination is a configured tile, otherwise lets the default forward processing continue. It would be nice if plugins can inject chain elements at specific points in the chain at startup, programatically. This way, plugins can be programmed to modify specific portions of the chain that it is concerned with, without affecting other portions of the chain or modifications of other plugins. Hubert - 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: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 enhancement idea
At 11:26 AM -0600 11/23/04, Hubert Rabago wrote: How would plugins work with the chain configuration? I've written ActionServlet/RequestProcessor extensions and plugins in the past. Often, the reason is to inject custom pre-, actual, or post-processing at specific steps. An example would Tiles, which IIRC intercepts the forward processing to see if the destination is a configured tile, otherwise lets the default forward processing continue. It would be nice if plugins can inject chain elements at specific points in the chain at startup, programatically. This way, plugins can be programmed to modify specific portions of the chain that it is concerned with, without affecting other portions of the chain or modifications of other plugins. I don't think you could do this with zero modifications to the chain-config, but it would be easy enough to add one or more LookupCommands like the one in the current example chain-config which look for injected commands under specific names and in specific catalogs. If you thought that there were some clear logical ways to group the base chain-config.xml, we could have it run as a series of lookup commands. I already am thinking that we should partition it into an action-chain and view-chain, but maybe it should be more finely grained? On the other hand, why not just specify an alternate chain-config file which does exactly what you need it to do? Or are you looking for a more comprehensive and flexible solution, like Maven's preGoal and postGoal definitions which allow you to add arbitrary goals anywhere. This would be tricky right now because commands aren't required to have names. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex
Re: Chain enhancement idea
Inline. On Tue, 23 Nov 2004 11:42:37 -0600, Joe Germuska [EMAIL PROTECTED] wrote: At 11:26 AM -0600 11/23/04, Hubert Rabago wrote: It would be nice if plugins can inject chain elements at specific points in the chain at startup, programatically. This way, plugins can be programmed to modify specific portions of the chain that it is concerned with, without affecting other portions of the chain or modifications of other plugins. I don't think you could do this with zero modifications to the chain-config, but it would be easy enough to add one or more LookupCommands like the one in the current example chain-config which look for injected commands under specific names and in specific catalogs. If you thought that there were some clear logical ways to group the base chain-config.xml, we could have it run as a series of lookup commands. I already am thinking that we should partition it into an action-chain and view-chain, but maybe it should be more finely grained? The extreme case I have in mind would be one chain for each step that the current request processor does. Yes, I know, it's extreme. At this point, it's just an idea I'm bringing up. On the other hand, why not just specify an alternate chain-config file which does exactly what you need it to do? Specific apps would be able to do this, but I was trying to think from the perspective of a plugin developer. I haven't looked at an example yet, but would the use of tiles require both a struts-config change to activate the plugin, as well as a chain-config change to modify the chain? What if an app were to use multiple plugins that inject their own commands at different points? Do we leave the changes to the end-user/app-developer? Or are you looking for a more comprehensive and flexible solution, like Maven's preGoal and postGoal definitions which allow you to add arbitrary goals anywhere. This would be tricky right now because commands aren't required to have names. Joe Hubert - 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 enhancement idea
At 11:58 AM -0600 11/23/04, Hubert Rabago wrote: Specific apps would be able to do this, but I was trying to think from the perspective of a plugin developer. I haven't looked at an example yet, but would the use of tiles require both a struts-config change to activate the plugin, as well as a chain-config change to modify the chain? What if an app were to use multiple plugins that inject their own commands at different points? Do we leave the changes to the end-user/app-developer? Yes, right now you must configure the TilesPlugIn and you must also uncomment the TilesPreProcessor command in the chain. It would be easy enough to leave the TilesPreProcessor command on by default, since it doesn't complain if it can't find a tile -- but that doesn't really address your larger question. Still, I think it would probably be better to wait for some plugins to materialize before guessing at exactly how to serve their needs. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex
RE: Experiences with MockObjects for Servlet testing?
You may want to try EasyMock instead of these mock servlet api implementations http://www.easymock.org/ Once you get your head around how this works, you may not go back to using concrete Mock objects again. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 6:15 AM To: Martin Cooper; Struts Developers List Subject: Re: Experiences with MockObjects for Servlet testing? At 4:44 PM -0800 11/22/04, Martin Cooper wrote: On Mon, 22 Nov 2004 16:28:32 -0800, Don Brown [EMAIL PROTECTED] wrote: Perhaps this might be a good time to bring up the idea of bringing StrutsTestCase as a Struts subproject? They have an implementation of the servlet api for testing. Also, someone (Howard?) mentioned at ApacheCon that ServletUnit is a good, stable, full-featured framework for testing, well, servlet-based code. I'd like us to take a look at that before we make any hard decisions about testing frameworks. I thought I knew, but then when I went investigating, I ran into the question of just what (or which) is servletunit? There's a fairly dormant Sourceforge Project: http://servletunit.sourceforge.net/ where code is in the package com.kizna.servletunit It's the top-level package for StrutsTestCase: http://strutstestcase.sourceforge.net/api/index.html HTTPUnit has a servletunit package (com.meterware.servletunit): http://httpunit.sourceforge.net/doc/api/index.html I think one (or more) of these might be as good or better as having Cactus tests in Struts as a whole -- but I still would prefer to use MockObjects for the kind of isolated testing I was trying to do with the CreateAction yesterday, so as to minimize the amount of extraneous setup required. That is, I'd prefer to use MockObjects if it worked for the test I needed. I suppose if we were using a mock servlet environment, I might be able to use components from it without having to simulate an entire Struts installation. (I see that the ServletContextSimulator in StrutsTestCase simply returns null for an attribute which isn't in the servlet context, which would be all I needed...) 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]
Re: Experiences with MockObjects for Servlet testing?
Joe Germuska [EMAIL PROTECTED] wrote: My main question is how is the development community? From a user point of view, it's dead. Occasionally a bug fix might be committed to cvs, but no new development is occurring. The last closed RFE was April of 2003. From what I understand, what you're asking to be able to do requires the ability to extend or customize ServletContextSimulator (and other classes -- HttpServletRequestSimulator, HttpServletRequestSimulator, HttpServletResponseSimulator, ServletConfigSimulator). Most of the StrutsTestCase RFEs ask for the ability to extend those classes. -Mike - 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 enhancement idea
On Tue, 23 Nov 2004 11:26:16 -0600, Hubert Rabago [EMAIL PROTECTED] wrote: How would plugins work with the chain configuration? I've written ActionServlet/RequestProcessor extensions and plugins in the past. Often, the reason is to inject custom pre-, actual, or post-processing at specific steps. An example would Tiles, which IIRC intercepts the forward processing to see if the destination is a configured tile, otherwise lets the default forward processing continue. It would be nice if plugins can inject chain elements at specific points in the chain at startup, programatically. This way, plugins can be programmed to modify specific portions of the chain that it is concerned with, without affecting other portions of the chain or modifications of other plugins. You can actually accomplish this kind of thing today (and an example of it is in the chain-config.xml file for Struts-Chain), but it's a little indirect. In your standard processing chain, do something like this: command className=org.apache.commons.chain.generic.LookupCommand catalogName=foo name=bar optional=true/ What this does, in English, is: * Look up a command named bar in a catalog named foo. * If such a command exists, delegate control to it (and do all the right stuff about filters if this is a chain) * If such a command does not exist, silently continue Therefore, it's very easy for your standard chain to provide extension points. If you want to require that the named command exist, set optional to false instead. Hubert Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chain enhancement idea
Joe Germuska [EMAIL PROTECTED] wrote: into an action-chain and view-chain, but maybe it should be more finely grained? Hubert Rabago [EMAIL PROTECTED] wrote: The extreme case I have in mind would be one chain for each step that the current request processor does. Yes, I know, it's extreme. At this point, it's just an idea I'm bringing up. I'd also like to see this. I need to have a hook into processValidate() on validation failure. Currently that can only be done by copy-and-pasting the processValidate() method from RequestProcessor into a subclass and sticking a hook into the middle of the code. When I asked about this on the dev list long ago, it was confirmed that there was no other way to do this, but that chain would eventually provide this flexibility. If the chain isn't configured at a fine-grain level, then it's not all that much more functional than the existing RequestProcessor. -Mike - 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]
[Commons Validator] Javascript Proposal
I've put forward a proposal to Commons Validator to add a facility to render the dynamic javascript for form validation. If considered a good idea, and Struts wanted to use it then most of the code in the JavascriptValidatorTag would disappear. IMO it has significant improvements over the current Struts javascript validation and I've listed them here... http://www.niallp.pwp.blueyonder.co.uk/validatorjs.html#benefits Bugzilla ticket is here: http://issues.apache.org/bugzilla/show_bug.cgi?id=32343 Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chain enhancement idea
On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska [EMAIL PROTECTED] wrote: I need to have a hook into processValidate() on validation failure. Currently that can only be done by copy-and-pasting the processValidate() method from RequestProcessor into a subclass and sticking a hook into the middle of the code. When I asked about this on the dev list long ago, it was confirmed that there was no other way to do this, but that chain would eventually provide this flexibility. If the chain isn't configured at a fine-grain level, then it's not all that much more functional than the existing RequestProcessor. The chain is configured at as fine-grained a level as you like, in XML. Hubert is talking about configuring the chain programatically as well, or at least in some way independent of the configuration of the primary processing chain. Programmatic configuration is certainly feasible ... there's no requirement in [chain] that you use the XML format at all. It's just one option. As long as you're willing to copy the base chain-config.xml file and make a few modifications, then you could simply add your own command which retrieves a value from the context under a well-known key and inspects the value to see if validation passed or not. This exact logic is the first thing executed in the CreateAction's execute method, which doesn't lookup or create an action unless the form validated. There's actually quite a few different ways to approach this, including the optionally invoke some other command at this point mentioned earlier in the thread, so you don't even *have* to cut-n-paste the standard version of the chain. You can start experimenting with commons-chain and struts-chain from CVS Head if you want to see what's going on. You don't have to wait for Struts 1.3. Indeed, Struts-Chain directly illustrates the fine-grained approach to defining the standard request processing chain that Joe describes. Nightly builds are available at: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/ Joe Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
