You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Craig McClanahan <cr...@apache.org> on 2004/05/05 19:41:46 UTC
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts-Faces and Version Dependencies
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
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" <cr...@apache.org>
To: "Struts Developers List" <de...@struts.apache.org>
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" <ni...@blueyonder.co.uk>
> >To: "Struts Developers List" <de...@struts.apache.org>
> >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" <cr...@apache.org>
> >>To: <de...@struts.apache.org>
> >>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: dev-unsubscribe@struts.apache.org
> >>>For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts-Faces and Version Dependencies
Posted by Joe Germuska <Jo...@Germuska.com>.
At 1:53 PM -0700 5/5/04, Craig McClanahan wrote:
>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.
It's been a few months since I was looking at form bean creation, but
I'm pretty sure this is exactly what I thought would be a good idea
as well; I think that i brought it up on the dev list looking for
some encouragement -- at least, I think I would have been reluctant
to just make the change without some discussion. (Maybe I neglected
to bring it up.)
There was some discussion on the user list this week about making
truly dynamic forms at run time, and this would serve that use case.
In short, I'm +1 on it.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts-Faces and Version Dependencies
Posted by Craig McClanahan <cr...@apache.org>.
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" <ni...@blueyonder.co.uk>
>To: "Struts Developers List" <de...@struts.apache.org>
>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" <cr...@apache.org>
>>To: <de...@struts.apache.org>
>>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: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts-Faces and Version Dependencies
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
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" <ni...@blueyonder.co.uk>
To: "Struts Developers List" <de...@struts.apache.org>
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" <cr...@apache.org>
> To: <de...@struts.apache.org>
> 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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts-Faces and Version Dependencies
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
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" <cr...@apache.org>
To: <de...@struts.apache.org>
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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org