Struts 1
  1. Struts 1
  2. STR-3009

ActionRedirect from ForwardConfig not redirecting properly?

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.5, 1.3.6, 1.3.7
    • Fix Version/s: 1.3.8
    • Component/s: Core
    • Labels:
      None

      Description

      While migrating from Struts 1.2.9 to Struts 1.3.5, I noticed ActionRedirect was no longer redirecting as expected.

      In the Struts 1.2.9, in

      public ActionRedirect(ForwardConfig baseConfig)

      setRedirect was always being set to TRUE, like it is in every other constructor.

      However, as of Struts 1.3.5 it is now being configured as

      setRedirect(baseConfig.getRedirect());

      This seems to defeat the purpose of a ActionRedirect if you are trying to generate one from a

      mapping.findForward();

        Issue Links

          Activity

          Hide
          Paul Benedict added a comment -

          1.3.8 will revert to setRedirect(true); if anyone is interested in pushing the parameter logic to ActionForward, it will go in 1.4

          Show
          Paul Benedict added a comment - 1.3.8 will revert to setRedirect(true); if anyone is interested in pushing the parameter logic to ActionForward, it will go in 1.4
          Hide
          Paul Benedict added a comment -

          As I think about it, I do believe the formulation logic belongs in an external class (perhaps RequestUtils). However, I think the exposed methods inside ActionRedirect should be bumped into ActionForward.

          Show
          Paul Benedict added a comment - As I think about it, I do believe the formulation logic belongs in an external class (perhaps RequestUtils). However, I think the exposed methods inside ActionRedirect should be bumped into ActionForward.
          Hide
          Hubert Rabago added a comment -

          > I don't know how did you get ActionMapping's purpose from
          > above description and how my suggestion is going farther
          > from it. IMHO, using ActionMapping for creating a
          > parameterized URL is cleaner than creating an ActionForward
          > directly.

          Like the description says, ActionMapping's purpose is to hold information about how an action is mapped. Your suggestion will give it processing duties as well, and not for an action's mapping, but for how an action's outcome can be converted to a URL.

          ActionMapping, ActionForward, these simply hold data from struts-config.xml. Having logic to formulate a URL is already a bit outside the purpose of ActionForward. I don't agree that such logic belongs to the class whose duty is to hold data about how an action is configured.

          If you were to insist, I'd suggest putting that logic in RequestUtils or your suggested ActionTransfer class, but not ActionMapping.

          > In any case, what's up with new features? Whenever someone
          > suggests a fully backwards compatible extension, somebody
          > else would inevitably come up with "it is against original
          > class purpose and therefore should not be implemented".

          You're barking at the wrong tree. I was dreaming of a whole slew of new features. The pronouncement that S2 is the way forward to Ti left no room for S1 and poured cold water on all that. But all that's OT for this ticket.

          >to me the following /code sample with String array/ is simpler than /ActionRedirect code sample/.

          It isn't about simplicity. Actually, I wouldn't mind changing ActionRedirect to accept a string array like in your example to make it simpler. It's about putting it in the right place. In this case, it's also trying to understand what a new class would bring that struts-config's <forward> and ActionRedirect doesn't already provide.

          Show
          Hubert Rabago added a comment - > I don't know how did you get ActionMapping's purpose from > above description and how my suggestion is going farther > from it. IMHO, using ActionMapping for creating a > parameterized URL is cleaner than creating an ActionForward > directly. Like the description says, ActionMapping's purpose is to hold information about how an action is mapped. Your suggestion will give it processing duties as well, and not for an action's mapping, but for how an action's outcome can be converted to a URL. ActionMapping, ActionForward, these simply hold data from struts-config.xml. Having logic to formulate a URL is already a bit outside the purpose of ActionForward. I don't agree that such logic belongs to the class whose duty is to hold data about how an action is configured. If you were to insist, I'd suggest putting that logic in RequestUtils or your suggested ActionTransfer class, but not ActionMapping. > In any case, what's up with new features? Whenever someone > suggests a fully backwards compatible extension, somebody > else would inevitably come up with "it is against original > class purpose and therefore should not be implemented". You're barking at the wrong tree. I was dreaming of a whole slew of new features. The pronouncement that S2 is the way forward to Ti left no room for S1 and poured cold water on all that. But all that's OT for this ticket. >to me the following / code sample with String array / is simpler than / ActionRedirect code sample /. It isn't about simplicity. Actually, I wouldn't mind changing ActionRedirect to accept a string array like in your example to make it simpler. It's about putting it in the right place. In this case, it's also trying to understand what a new class would bring that struts-config's <forward> and ActionRedirect doesn't already provide.
          Hide
          Michael Jouravlev added a comment -

          Missed it: ActionRedirect.addParameter returns THIS, so I can easily chain calls to addParameter.

          I suppose the solution is creating ActionTransfer out of ActionRedirect, and rolling ActionRedirect back to 1.2.9 state.

          Show
          Michael Jouravlev added a comment - Missed it: ActionRedirect.addParameter returns THIS, so I can easily chain calls to addParameter. I suppose the solution is creating ActionTransfer out of ActionRedirect, and rolling ActionRedirect back to 1.2.9 state.
          Hide
          Niall Pemberton added a comment -

          OK - you guys have stronger opnions on this than me - so ignore my earlier comment, I'll leave it up to you. I was mainly trying to point out that it appeared to be a concious change.

          Show
          Niall Pemberton added a comment - OK - you guys have stronger opnions on this than me - so ignore my earlier comment, I'll leave it up to you. I was mainly trying to point out that it appeared to be a concious change.
          Hide
          Michael Jouravlev added a comment -

          > 1) Do not modify ForwardConfig. It's nothing but a mapping and does not
          > indicate the type of mapping, so it's wrong to assume it is a forward
          > or redirect (although it generally always is).

          It does indicate redirect/forward in the config file. An optional parameter would help to override this value.

          > 2) Do not add parameter adding directly to ActionForward. Although
          > ActionRedirect is a subclass of ActionForward, the hierarchy is wrong
          > because a redirect is not a philosophical subset of a forward. They are
          > just differing but similar technologies.

          Agreed.

          > 3) Create a new subclass between ActionMapping and ActionForward called
          > ActionParameterized and place the functionality there. Just take the code
          > in ActionRedirect and move it up the hierarchy.

          This is what I wanted to do at first, calling it ActionTransfer in terms that transfer is generalization of forward and redirect.

          But I think that sometimes too much OOP is too much. Here is the reasons why adding parameters to ActionMapping.findForward is simpler:

          • Users often do not think about ActionForward objects, I believe that many automatically write code like return mapping.findForward("success") without much thinking what exactly is returned.
          • Many users do not know that preconfigured mappings are frozen and can't be updated. Thy may be tempted to do so, especially considering that ActionMapping has methods for that. By passing parameters to findForward the framework will automatically decide whether to return a canned object or to create a new instance.
          • to me the following

          return mapping.findForward("success", true,
          new String[][] "objid",objid},{"mode","VIEW");

          or

          return mapping.findForward("success", true,
          new ActionParam(new String[][] "objid",objid},{"mode","VIEW"));

          is simpler than

          ActionRedirect redirect =
          new ActionRedirect(mapping.findForward("success"));
          redirect.addParameter("objid",objid);
          redirect.addParameter("mode","VIEW");
          return redirect;

          But I don't care too much about this particular aspect of Struts to push my suggestion. ActionTransfer a.k.a. ActionParameterized will work for me too.

          Show
          Michael Jouravlev added a comment - > 1) Do not modify ForwardConfig. It's nothing but a mapping and does not > indicate the type of mapping, so it's wrong to assume it is a forward > or redirect (although it generally always is). It does indicate redirect/forward in the config file. An optional parameter would help to override this value. > 2) Do not add parameter adding directly to ActionForward. Although > ActionRedirect is a subclass of ActionForward, the hierarchy is wrong > because a redirect is not a philosophical subset of a forward. They are > just differing but similar technologies. Agreed. > 3) Create a new subclass between ActionMapping and ActionForward called > ActionParameterized and place the functionality there. Just take the code > in ActionRedirect and move it up the hierarchy. This is what I wanted to do at first, calling it ActionTransfer in terms that transfer is generalization of forward and redirect. But I think that sometimes too much OOP is too much. Here is the reasons why adding parameters to ActionMapping.findForward is simpler: Users often do not think about ActionForward objects, I believe that many automatically write code like return mapping.findForward("success") without much thinking what exactly is returned. Many users do not know that preconfigured mappings are frozen and can't be updated. Thy may be tempted to do so, especially considering that ActionMapping has methods for that. By passing parameters to findForward the framework will automatically decide whether to return a canned object or to create a new instance. to me the following return mapping.findForward("success", true, new String[][] "objid",objid},{"mode","VIEW" ); or return mapping.findForward("success", true, new ActionParam(new String[][] "objid",objid},{"mode","VIEW" )); is simpler than ActionRedirect redirect = new ActionRedirect(mapping.findForward("success")); redirect.addParameter("objid",objid); redirect.addParameter("mode","VIEW"); return redirect; But I don't care too much about this particular aspect of Struts to push my suggestion. ActionTransfer a.k.a. ActionParameterized will work for me too.
          Hide
          Paul Benedict added a comment -

          Let me take the solution back The architecture is wrong. This is what I think should be done:

          1) Do not modify ForwardConfig. It's nothing but a mapping and does not indicate the type of mapping, so it's wrong to assume it is a forward or redirect (although it generally always is).

          2) Do not add parameter adding directly to ActionForward. Although ActionRedirect is a subclass of ActionForward, the hierarchy is wrong because a redirect is not a philosophical subset of a forward. They are just differing but similar technologies.

          3) Create a new subclass between ActionMapping and ActionForward called ActionParameterized and place the functionality there. Just take the code in ActionRedirect and move it up the hierarchy.

          Show
          Paul Benedict added a comment - Let me take the solution back The architecture is wrong. This is what I think should be done: 1) Do not modify ForwardConfig. It's nothing but a mapping and does not indicate the type of mapping, so it's wrong to assume it is a forward or redirect (although it generally always is). 2) Do not add parameter adding directly to ActionForward. Although ActionRedirect is a subclass of ActionForward, the hierarchy is wrong because a redirect is not a philosophical subset of a forward. They are just differing but similar technologies. 3) Create a new subclass between ActionMapping and ActionForward called ActionParameterized and place the functionality there. Just take the code in ActionRedirect and move it up the hierarchy.
          Hide
          Paul Benedict added a comment -

          An ActionRedirect should default to "redirect=true" – the 1.3.5 behavior is an error imo – and I do not mind investigating the revert. I'd leave ActionMapping as it is, but add the parameter adding functionality onto ActionForward – since it's the property of a forward or redirect (not mapping) that parameters can be added.

          Show
          Paul Benedict added a comment - An ActionRedirect should default to "redirect=true" – the 1.3.5 behavior is an error imo – and I do not mind investigating the revert. I'd leave ActionMapping as it is, but add the parameter adding functionality onto ActionForward – since it's the property of a forward or redirect (not mapping) that parameters can be added.
          Hide
          Michael Jouravlev added a comment -

          >> Basically, if ActionMapping.findForward is
          >> called with name only it will return a frozen instance of
          >> ActionForward, otherwise it will create a new instance on the
          >> fly, with optional parameters and redirect flag. The URL
          >> parameters can be sent as a separate parameter object, this
          >> code can pulled out of ActionRedirect class.
          >>
          > I think that's even farther from ActionMapping's purpose than forming
          > a URL is from ActionRedirect's, so I'm -1 on that.

          From ActionMapping Javadoc: "An ActionMapping represents the information that the controller, RequestProcessor, knows about the mapping of a particular request to an instance of a particular Action class. The ActionMapping instance used to select a particular Action is passed on to that Action, thereby providing access to any custom configuration information included with the ActionMapping object."

          I don't know how did you get ActionMapping's purpose from above description and how my suggestion is going farther from it. IMHO, using ActionMapping for creating a parameterized URL is cleaner than creating an ActionForward directly. It is also simpler, a user has to learn only one method, ActionMapping.findForward instead of learning about ActionRedirect class and its quirks.

          In any case, what's up with new features? Whenever someone suggests a fully backwards compatible extension, somebody else would inevitably come up with "it is against original class purpose and therefore should not be implemented". On the other hand, thanks for supporting action events

          Show
          Michael Jouravlev added a comment - >> Basically, if ActionMapping.findForward is >> called with name only it will return a frozen instance of >> ActionForward, otherwise it will create a new instance on the >> fly, with optional parameters and redirect flag. The URL >> parameters can be sent as a separate parameter object, this >> code can pulled out of ActionRedirect class. >> > I think that's even farther from ActionMapping's purpose than forming > a URL is from ActionRedirect's, so I'm -1 on that. From ActionMapping Javadoc: "An ActionMapping represents the information that the controller, RequestProcessor, knows about the mapping of a particular request to an instance of a particular Action class. The ActionMapping instance used to select a particular Action is passed on to that Action, thereby providing access to any custom configuration information included with the ActionMapping object." I don't know how did you get ActionMapping's purpose from above description and how my suggestion is going farther from it. IMHO, using ActionMapping for creating a parameterized URL is cleaner than creating an ActionForward directly. It is also simpler, a user has to learn only one method, ActionMapping.findForward instead of learning about ActionRedirect class and its quirks. In any case, what's up with new features? Whenever someone suggests a fully backwards compatible extension, somebody else would inevitably come up with "it is against original class purpose and therefore should not be implemented". On the other hand, thanks for supporting action events
          Hide
          Hubert Rabago added a comment -

          > What do you think about new
          > feature of ActionMapping described above? We can even pass
          > redirect flag. Basically, if ActionMapping.findForward is
          > called with name only it will return a frozen instance of
          > ActionForward, otherwise it will create a new instance on the
          > fly, with optional parameters and redirect flag. The URL
          > parameters can be sent as a separate parameter object, this
          > code can pulled out of ActionRedirect class.

          I think that's even farther from ActionMapping's purpose than forming a URL is from ActionRedirect's, so I'm -1 on that.

          Show
          Hubert Rabago added a comment - > What do you think about new > feature of ActionMapping described above? We can even pass > redirect flag. Basically, if ActionMapping.findForward is > called with name only it will return a frozen instance of > ActionForward, otherwise it will create a new instance on the > fly, with optional parameters and redirect flag. The URL > parameters can be sent as a separate parameter object, this > code can pulled out of ActionRedirect class. I think that's even farther from ActionMapping's purpose than forming a URL is from ActionRedirect's, so I'm -1 on that.
          Hide
          Michael Jouravlev added a comment -

          >> In regards to ActionRedirect, should not redirect/forward be defined
          >> in the config file after all? Was not it an original intent of Struts
          >> to externalize configuration?
          >>
          > You can't really just change a config file and have that dictate this
          > particular behavior. How the action is written can depend on whether
          > you're planning to redirect or forward. If you're redirecting, you modify
          > the outgoing URL; if you're forwarding, you put your data in request
          > attributes. (Well, that's one way to do it.)

          Right. When you want to send additional data to the target location, you either queue it into request object for forward, or add to URL for redirect. Well, one can also use session as temporary storage for redirect as well, but in this case no parameters are passed.

          So, ActionMapping can accept parameters along with mapping name, and depending on mapping configuration (redirect of forward) perform an appropriate parameter packing, either sticking them into request or adding them to URL. Seems clean and simple to me.

          > ActionRedirect's redirect attribute wasn't intended to be configurable.
          > I wouldn't recommend that an Action use ActionRedirect if the intention
          > is to do a forward. Just because we can do it that way doesn't make it
          > right.
          >
          > I agree with Jason that the change in behavior broke backward compatibility
          > and should be considered a bug.

          I guess I can agree with this. What do you think about new feature of ActionMapping described above? We can even pass redirect flag. Basically, if ActionMapping.findForward is called with name only it will return a frozen instance of ActionForward, otherwise it will create a new instance on the fly, with optional parameters and redirect flag. The URL parameters can be sent as a separate parameter object, this code can pulled out of ActionRedirect class.

          Show
          Michael Jouravlev added a comment - >> In regards to ActionRedirect, should not redirect/forward be defined >> in the config file after all? Was not it an original intent of Struts >> to externalize configuration? >> > You can't really just change a config file and have that dictate this > particular behavior. How the action is written can depend on whether > you're planning to redirect or forward. If you're redirecting, you modify > the outgoing URL; if you're forwarding, you put your data in request > attributes. (Well, that's one way to do it.) Right. When you want to send additional data to the target location, you either queue it into request object for forward, or add to URL for redirect. Well, one can also use session as temporary storage for redirect as well, but in this case no parameters are passed. So, ActionMapping can accept parameters along with mapping name, and depending on mapping configuration (redirect of forward) perform an appropriate parameter packing, either sticking them into request or adding them to URL. Seems clean and simple to me. > ActionRedirect's redirect attribute wasn't intended to be configurable. > I wouldn't recommend that an Action use ActionRedirect if the intention > is to do a forward. Just because we can do it that way doesn't make it > right. > > I agree with Jason that the change in behavior broke backward compatibility > and should be considered a bug. I guess I can agree with this. What do you think about new feature of ActionMapping described above? We can even pass redirect flag. Basically, if ActionMapping.findForward is called with name only it will return a frozen instance of ActionForward, otherwise it will create a new instance on the fly, with optional parameters and redirect flag. The URL parameters can be sent as a separate parameter object, this code can pulled out of ActionRedirect class.
          Hide
          Hubert Rabago added a comment -

          > In regards to ActionRedirect, should not redirect/forward be defined in the config file after all? Was not it an original intent of Struts to externalize configuration?

          You can't really just change a config file and have that dictate this particular behavior. How the action is written can depend on whether you're planning to redirect or forward. If you're redirecting, you modify the outgoing URL; if you're forwarding, you put your data in request attributes. (Well, that's one way to do it.)

          ActionRedirect's redirect attribute wasn't intended to be configurable. I wouldn't recommend that an Action use ActionRedirect if the intention is to do a forward. Just because we can do it that way doesn't make it right.

          I agree with Jason that the change in behavior broke backward compatibility and should be considered a bug.

          Show
          Hubert Rabago added a comment - > In regards to ActionRedirect, should not redirect/forward be defined in the config file after all? Was not it an original intent of Struts to externalize configuration? You can't really just change a config file and have that dictate this particular behavior. How the action is written can depend on whether you're planning to redirect or forward. If you're redirecting, you modify the outgoing URL; if you're forwarding, you put your data in request attributes. (Well, that's one way to do it.) ActionRedirect's redirect attribute wasn't intended to be configurable. I wouldn't recommend that an Action use ActionRedirect if the intention is to do a forward. Just because we can do it that way doesn't make it right. I agree with Jason that the change in behavior broke backward compatibility and should be considered a bug.
          Hide
          Michael Jouravlev added a comment -

          On a related note, should not ActionMapping have another findForward method that takes parameters? I think this would be a cleaner solution than creating ActionTransfer.

          In regards to ActionRedirect, should not redirect/forward be defined in the config file after all? Was not it an original intent of Struts to externalize configuration? In case an action needs both forward and redirect to the same location, two <forward> entries can be defined, with different names. I don't see major difference coding-wise between an if statement selecting a forward, and building a dynamic ActionForward object. Conceptually, I think that former is preferable.

          Show
          Michael Jouravlev added a comment - On a related note, should not ActionMapping have another findForward method that takes parameters? I think this would be a cleaner solution than creating ActionTransfer. In regards to ActionRedirect, should not redirect/forward be defined in the config file after all? Was not it an original intent of Struts to externalize configuration? In case an action needs both forward and redirect to the same location, two <forward> entries can be defined, with different names. I don't see major difference coding-wise between an if statement selecting a forward, and building a dynamic ActionForward object. Conceptually, I think that former is preferable.
          Hide
          Michael Jouravlev added a comment -

          Ok, how about reverting ActionRedirect to its 1.2.9 state, and adding ActionTransfer that would work exactly like ActionRedirect works in 1.3.5?

          Show
          Michael Jouravlev added a comment - Ok, how about reverting ActionRedirect to its 1.2.9 state, and adding ActionTransfer that would work exactly like ActionRedirect works in 1.3.5?
          Hide
          Jason Millard added a comment -

          its backward compatibility.

          If the ActionRedirect constructors do not default redirect to true, than in
          this case, Struts is not backwards compatible.

          I have existing code that no longer works unless I manually set redirect to
          true.

          On 2/27/07, Michael Jouravlev (JIRA) <jira@apache.org> wrote:

          Show
          Jason Millard added a comment - its backward compatibility. If the ActionRedirect constructors do not default redirect to true, than in this case, Struts is not backwards compatible. I have existing code that no longer works unless I manually set redirect to true. On 2/27/07, Michael Jouravlev (JIRA) <jira@apache.org> wrote:
          Hide
          Jason Millard added a comment -

          > As Neil points out, nothing can be done at this point, Struts is known for its backward compatibility.

          If the ActionRedirect constructors do not default redirect to true, than in this case, Struts is not backwards compatible.

          I have existing code that no longer works unless I manually set redirect to true.

          Show
          Jason Millard added a comment - > As Neil points out, nothing can be done at this point, Struts is known for its backward compatibility. If the ActionRedirect constructors do not default redirect to true, than in this case, Struts is not backwards compatible. I have existing code that no longer works unless I manually set redirect to true.
          Hide
          Hubert Rabago added a comment -

          (Fixed typo)
          If I created and returned an ActionRedirect from my action:
          return new ActionRedirect(mapping.findForward("success")
          .addParameter("foo", bar)
          .addParameter("baz", bat)

          ...then I'm specifying at that point that I'm doing a redirect.

          The redirect behavior of ActionForward was intended to be configurable, but not the redirect behavior of ActionRedirect.

          The change has only been around for one GA release (1.3.5), so it shouldn't be that big a deal if we decide that it's a bug and revert to the original behavior.

          Show
          Hubert Rabago added a comment - (Fixed typo) If I created and returned an ActionRedirect from my action: return new ActionRedirect(mapping.findForward("success") .addParameter("foo", bar) .addParameter("baz", bat) ...then I'm specifying at that point that I'm doing a redirect. The redirect behavior of ActionForward was intended to be configurable, but not the redirect behavior of ActionRedirect. The change has only been around for one GA release (1.3.5), so it shouldn't be that big a deal if we decide that it's a bug and revert to the original behavior.
          Hide
          Michael Jouravlev added a comment -

          I think the original decision to use the setting defined in the struts config file has ambiguated the ActionRedirect class name. As Neil points out, nothing can be done at this point, Struts is known for its backward compatibility.

          The only thing I can suggest is to disambiguate the class name and to create a marker ActionTransfer class, which will do nothing besides not implying a specific control transfer type (forward/redirect). ActionTransfer would be suggested for future use instead of ActionRedirect.

          Show
          Michael Jouravlev added a comment - I think the original decision to use the setting defined in the struts config file has ambiguated the ActionRedirect class name. As Neil points out, nothing can be done at this point, Struts is known for its backward compatibility. The only thing I can suggest is to disambiguate the class name and to create a marker ActionTransfer class, which will do nothing besides not implying a specific control transfer type (forward/redirect). ActionTransfer would be suggested for future use instead of ActionRedirect.
          Hide
          Niall Pemberton added a comment -

          Looking at STR-2538 and revision 390335[1] it appears that this was intentional - from the last but one comment from that issue ticket:

          "I like the ActionRedirect, but I find it lacking in two ways: 1. It requires that an HTTP redirect be done (i.e. no forwarding to another
          action on the server side with no client interaction). 2. ...."

          also

          "I would like to propose that these changes be made, and I would be glad to submit a patch. However, #1 is a pretty significant change, so I would like to ask anyone who reads this message to give me some feedback... would a new class be better (such as the one I have already attached to the bug), or should these changes be made to the existing ActionRedirect class?"

          Seems that ActionRedirect was adapted to suit purposes more than just redirect. Reverting back to the previous behaviour potentially breaks anyone relying on what currently happens in 1.3.5 - so it seems like a no-win situation to me and I would incline to leave things as they are.

          [1] http://svn.apache.org/viewvc?view=rev&revision=390335

          Show
          Niall Pemberton added a comment - Looking at STR-2538 and revision 390335 [1] it appears that this was intentional - from the last but one comment from that issue ticket: "I like the ActionRedirect, but I find it lacking in two ways: 1. It requires that an HTTP redirect be done (i.e. no forwarding to another action on the server side with no client interaction). 2. ...." also "I would like to propose that these changes be made, and I would be glad to submit a patch. However, #1 is a pretty significant change, so I would like to ask anyone who reads this message to give me some feedback... would a new class be better (such as the one I have already attached to the bug), or should these changes be made to the existing ActionRedirect class?" Seems that ActionRedirect was adapted to suit purposes more than just redirect. Reverting back to the previous behaviour potentially breaks anyone relying on what currently happens in 1.3.5 - so it seems like a no-win situation to me and I would incline to leave things as they are. [1] http://svn.apache.org/viewvc?view=rev&revision=390335

            People

            • Assignee:
              Unassigned
              Reporter:
              Jason Millard
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development