Yes the patch I put in just resloved the immediate issue but IMO having an ActionForm factory method in the config would be a good improvement - makes it simple/logical for people to understand that to get a new ActionForm all they have to do is retrieve the form config and call the factory method.
Its 10:25pm where I am so I wouldn't be doing anything tonight - so you go ahead if you want to. Also, I've been trying off and on over the last couple of weeks to get the Tomcat tests to run and haven't managed it. The ordinary junit tests run fine (target "test.junit" in build-tests.xml) but I've tried both the Tomcat 4.1 and Tomcat 5.0 tests and I can't get them to work. It's failing when it tries to start Tomcat, for 4.1 I see the message: "Starting Coyote HTTP/1.1 on port 8080" and then fails after the three minute time out. I ran it in "debug" mode like the message suggests, but all I see is loads of messages trying to connect to the test web app. Can anyone suggest how I can get more info on what the problem is? Niall ----- Original Message ----- From: "Craig McClanahan" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, May 05, 2004 9:53 PM Subject: Re: Struts-Faces and Version Dependencies > Thanks Niall. > > The original reason for grabbing the module prefix was to make the cache > keys unique, so that two modules that both defined a form bean named > "foo" (but perhaps with different properties) would not clash. > > The approach you recommend seems reasonable, and accomplishes that same > goal ... but if we're going to be a factory, we might as well be a > factory for action form instances (as you suggest), so the > FormBeanConfig method would be something like: > > public ActionForm createActionForm(ActionServlet servlet) > > instead. The dynamic create version would use the restored method > signature in DynaActionFormClass (which the struts-faces library routine > would still need to call in order to remain 1.1-compatible). > > Does that sound right? If so, I'm +1 for such a patch, and will do so > later tonight if you don't beat me. > > Craig > > Niall Pemberton wrote: > > >I just attached a patch to Bug[22207] which changes the method signiture > >back to its original form. > > > >http://issues.apache.org/bugzilla/show_bug.cgi?id=22207 > > > >Niall > > > >----- Original Message ----- > >From: "Niall Pemberton" <[EMAIL PROTECTED]> > >To: "Struts Developers List" <[EMAIL PROTECTED]> > >Sent: Wednesday, May 05, 2004 7:47 PM > >Subject: Re: Struts-Faces and Version Dependencies > > > > > > > > > >>The only reason for needing the ModuleConfig is to get the module prefix > >> > >> > >for > > > > > >>the key to store the DynaActionFormClass in the "static" cache in > >>DynaActionFormClass . > >> > >>My suggestion would to to get rid of the static "cache" of > >>DynaActionFormClasses and store them in their respective FormBeanConfig - > >>that way there would be no need for a reference to the ModuleConfig. > >> > >>Taking this further, you could then provide a method in the FormBeanConfig > >>to create a new DynaActionForm or in fact any ActionForm making it very > >> > >> > >easy > > > > > >>for someone to generate a new ActionForm in the Action if they required. > >> > >> > >But > > > > > >>I don't know what you think about turing the FormBeanConfig from just > >>containing the "config" info to making it also a "factory" for > >> > >> > >ActionForms? > > > > > >>Niall > >> > >> > >>----- Original Message ----- > >>From: "Craig McClanahan" <[EMAIL PROTECTED]> > >>To: <[EMAIL PROTECTED]> > >>Sent: Wednesday, May 05, 2004 6:41 PM > >>Subject: Struts-Faces and Version Dependencies > >> > >> > >> > >> > >>>I'm woefully behind in dealing with Struts issues due to "day job" > >>>responsibilities, but I finally took the time to discover why the > >>>Struts-Faces nightly builds have been failing. Unfortunately, we've > >>>created a public API discrepancy in the latest CVS code (versus 1.1) > >>>that affects the library. > >>> > >>>In Struts 1.1, the org.apache.struts.action.DynaActionFormClass included > >>>the method signature: > >>> > >>> public static DynaActionClass > >>> createDynaActionFormClass(FormBeanConfig config); > >>> > >>>But in version 1.18 of this class (as part of dealing with Bugzilla > >>>#22207[1] ), we changed the method signature to: > >>> > >>> public static DynaActionClass > >>> createDynaActionFormClass(FormBeanConfig config, ModuleConfig > >>>moduleConfig); > >>> > >>>The change was necessitated by the fact that a FormBeanConfig no longer > >>>has a reference to the ModuleConfig for the module containing it, so it > >>>had to be passed in. The net result is that the Struts-Faces library > >>>can be built against either Struts 1.1 or Struts 1.2, but not both :-(. > >>> > >>>I'd be willing to consider a 1.2 dependency if we had a GA quality > >>>release available; but I'd also rather not try to release struts-faces > >>>for 1.1 only and then have to rev it for Struts 1.2 solely to deal with > >>>this issue (in all other respects that I have tested, struts-faces seems > >>>to work fine on either). > >>> > >>>Any ideas? In particular, is there a way to deal with the serialization > >>>issue that was described in the bug report, without having to change > >>>this method signature? > >>> > >>>In the longer term, I think we do need to be somewhat more careful about > >>>public API changes in 1.x versions. One of the reasons Struts is > >>>powerful is precisely because there are many extensions built around it > >>>... and making life harder on people building those extensions isn't > >>>conducive to that continuing. > >>> > >>>Craig > >>> > >>>[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=22207 > >>> > >>> > >>>--------------------------------------------------------------------- > >>>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] > >> > >> > >> > >> > >> > > > > > > > >--------------------------------------------------------------------- > >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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
