[Robert Varga]

Let’s use the following struts-config.xml:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE struts-config PUBLIC “-//Apache Software Foundation//DTD Struts Configuration 1.1//EN” “http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd”&gt;
<struts-config>
<data-sources />
<form-beans >
<form-bean name=”loginForm” type=”com.yourcompany.struts.form.LoginForm”>
<form-property name=”password” type=”java.lang.String” />
<form-property name=”username” type=”java.lang.String” />
</form-bean>

</form-beans>

<global-exceptions />
<global-forwards >
<forward
name=”/index”
path=”index.jsp”
redirect=”false”
contextRelative=”false” />

</global-forwards>

<action-mappings >
<action
attribute=”loginForm”
input=”index.jsp”
name=”loginForm”
path=”/login”
type=”com.yourcompany.struts.action.LoginAction”
unknown=”false”
validate=”true”>
<forward
name=”success”
path=”/loggedIn.do”
redirect=”false”
contextRelative=”false” />
<forward
name=”error”
path=”/index.do”
redirect=”false”
contextRelative=”false” />
</action>

</action-mappings>

<controller
bufferSize=”4096″
debug=”0″
locale=”false”
nocache=”false”
inputForward=”false” />
<message-resources null=”true” parameter=”com.yourcompany.struts.ApplicationResources” />
</struts-config>

There is a bug in interpreting global forwards name-s when resolving nodes to connect a link to:

1. There is a global forward /index which is accessible from the outside as /index.do

2. There is an action /login which has a forward named error pointing to /index.do.
This means linking to the global forward named /index in the current config.

3. However on the flow view there are two separate nodes:
– one magenta for the global forward named /index (correctly), and
– one grey for a hypothetical /index.do action to which the error forward from the login.do action links to

This is a mistake, since /index.do is handled by the global forward, and therefore the error should point to there, and the /index.do action should not appear on the flow view at all, and a separate /index.do action should not be hypothesized to exist, since the /index global forward is resolvable successfully.

That means that there is a bug in the code finding the node to which a forward should point to, specifically that it does not handle global forwards correctly, and does not recognize that when a /index global forward exists, that qualifies as a destination to an action forward with path=”/index.do”.

If I enter /index.do as the name for the global forward, which I should not do, because it would be accessible with a request /index.do.do, the flow view merges the two nodes.

Therefore the error lies in the code which tries to match a forward path to existing struts-config entries, which does not treat a global forward correctly (because it does not add the implied .do to the global forward name).

Regards,

Robert Varga

[Riyad Kalla]

Robert, we’ll look into this. Thank you for such a detailed problem report.

[support-michael]

Hi Rob,

We typically use forwarding actions to do what you describe, e.g., <action path=”/showIndex” forward=”/index.jsp” …/> and then access it with URL “/showIndex.do”. This works like a charm. I tried to replicate the sample that you provided with no success using Struts 1.1. Can you point me to documentation that describes configuring a global-forward to have an implicit “.do” suffix like an action?

[Robert Varga]

@support-michael wrote:

Hi Rob,

We typically use forwarding actions to do what you describe, e.g., <action path=”/showIndex” forward=”/index.jsp” …/> and then access it with URL “/showIndex.do”. This works like a charm. I tried to replicate the sample that you provided with no success using Struts 1.1. Can you point me to documentation that describes configuring a global-forward to have an implicit “.do” suffix like an action?

Hm, I don’t know why, I remembered that global forwards may be accessed from the outside. But it may be possible that they are not.

Anyway, forwarding action mappings (action with forward attribute) seem to do just what I want, and work perfectly in flow view, so we can close this bug.

[support-michael]

Thanks for the closure.

[Author]

Posts