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]
