You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Joe Germuska (JIRA)" <ji...@apache.org> on 2006/05/18 22:32:16 UTC
[jira] Created: (STR-2879) when used in modules, TilesPreProcessor
not backwards compatible with 1.2.x
when used in modules, TilesPreProcessor not backwards compatible with 1.2.x
----------------------------------------------------------------------------
Key: STR-2879
URL: http://issues.apache.org/struts/browse/STR-2879
Project: Struts Action 1
Type: Bug
Components: Tiles
Versions: 1.3.4
Reporter: Joe Germuska
Fix For: 1.3.5
When used in any "module" other than the "root" (or default), the implementation of TilesPreProcessor does not work in the same way that the TilesRequestProcessor did in earlier versions of Struts.
Specifically, because it does not dispatch the forward itself, it leaves the "module" unarticulated; this causes PerformForward to attempt to resolve the base Tiles JSP (or other path) relative to the current module, which is not how it used to be.
I think the best solution would be for the TilesPreProcessor to actually do the requestDispatcher.forward() (or include) in cases where it finds that the working ForwardConfig is for a tile definition, rather than returning a ForwardConfig. It can return "true" to signal that the chain should end.
The only argument against this would be if people thought they'd want to add more chain logic after the TilesPreProcessor. I suppose it could set the ForwardConfig to null and let the chain continue.
I'd love some opinions on this, and it'll be a couple of days before I could do a fix, so please weigh in if you have any. Also, module users are encouraged to step up and help clarify, as I only use them under protest :)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (STR-2879) when used in modules, TilesPreProcessor
not backwards compatible with 1.2.x
Posted by "Joe Germuska (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/STR-2879?page=all ]
Joe Germuska resolved STR-2879:
-------------------------------
Resolution: Fixed
Fixed in SVN commit 408085: TilesPreProcessor now handles forwarding itself with RequestDispatcher, more like what TilesRequestProcessor did in Struts 1.2.x
Also, TilesPreProcessor no longer stops execution of the chain when doing an include; instead, if tiles does either an include or a forward, it clears the forwardConfig from the ActionContext, but it allows the chain to continue processing. I can't think of any use cases myself where I'd need this, but it seemed better to leave it open, and since forwards (the more common case) were allowing the chain to continue before, I chose to preserve that and change the doInclude case to be consistent with the doForward case.
> when used in modules, TilesPreProcessor not backwards compatible with 1.2.x
> ---------------------------------------------------------------------------
>
> Key: STR-2879
> URL: http://issues.apache.org/struts/browse/STR-2879
> Project: Struts Action 1
> Type: Bug
> Components: Tiles
> Versions: 1.3.4
> Reporter: Joe Germuska
> Fix For: 1.3.5
>
> When used in any "module" other than the "root" (or default), the implementation of TilesPreProcessor does not work in the same way that the TilesRequestProcessor did in earlier versions of Struts.
> Specifically, because it does not dispatch the forward itself, it leaves the "module" unarticulated; this causes PerformForward to attempt to resolve the base Tiles JSP (or other path) relative to the current module, which is not how it used to be.
> I think the best solution would be for the TilesPreProcessor to actually do the requestDispatcher.forward() (or include) in cases where it finds that the working ForwardConfig is for a tile definition, rather than returning a ForwardConfig. It can return "true" to signal that the chain should end.
> The only argument against this would be if people thought they'd want to add more chain logic after the TilesPreProcessor. I suppose it could set the ForwardConfig to null and let the chain continue.
> I'd love some opinions on this, and it'll be a couple of days before I could do a fix, so please weigh in if you have any. Also, module users are encouraged to step up and help clarify, as I only use them under protest :)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (STR-2879) when used in modules,
TilesPreProcessor not backwards compatible with 1.2.x
Posted by "Lukasz Racon (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/STR-2879?page=comments#action_37373 ]
Lukasz Racon commented on STR-2879:
-----------------------------------
As a quick workaround, one can define forwardPattern in module's struts-config.xml, i.e.:
<controller forwardPattern="$P" />
That is just a temporary fix.
> when used in modules, TilesPreProcessor not backwards compatible with 1.2.x
> ---------------------------------------------------------------------------
>
> Key: STR-2879
> URL: http://issues.apache.org/struts/browse/STR-2879
> Project: Struts Action 1
> Type: Bug
> Components: Tiles
> Versions: 1.3.4
> Reporter: Joe Germuska
> Fix For: 1.3.5
>
> When used in any "module" other than the "root" (or default), the implementation of TilesPreProcessor does not work in the same way that the TilesRequestProcessor did in earlier versions of Struts.
> Specifically, because it does not dispatch the forward itself, it leaves the "module" unarticulated; this causes PerformForward to attempt to resolve the base Tiles JSP (or other path) relative to the current module, which is not how it used to be.
> I think the best solution would be for the TilesPreProcessor to actually do the requestDispatcher.forward() (or include) in cases where it finds that the working ForwardConfig is for a tile definition, rather than returning a ForwardConfig. It can return "true" to signal that the chain should end.
> The only argument against this would be if people thought they'd want to add more chain logic after the TilesPreProcessor. I suppose it could set the ForwardConfig to null and let the chain continue.
> I'd love some opinions on this, and it'll be a couple of days before I could do a fix, so please weigh in if you have any. Also, module users are encouraged to step up and help clarify, as I only use them under protest :)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (STR-2879) when used in modules,
TilesPreProcessor not backwards compatible with 1.2.x
Posted by "Lukasz Racon (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/STR-2879?page=comments#action_37373 ]
Lukasz Racon commented on STR-2879:
-----------------------------------
As a quick workaround, one can define forwardPattern in module's struts-config.xml, i.e.:
<controller forwardPattern="$P" />
That is just a temporary fix.
> when used in modules, TilesPreProcessor not backwards compatible with 1.2.x
> ---------------------------------------------------------------------------
>
> Key: STR-2879
> URL: http://issues.apache.org/struts/browse/STR-2879
> Project: Struts Action 1
> Type: Bug
> Components: Tiles
> Versions: 1.3.4
> Reporter: Joe Germuska
> Fix For: 1.3.5
>
> When used in any "module" other than the "root" (or default), the implementation of TilesPreProcessor does not work in the same way that the TilesRequestProcessor did in earlier versions of Struts.
> Specifically, because it does not dispatch the forward itself, it leaves the "module" unarticulated; this causes PerformForward to attempt to resolve the base Tiles JSP (or other path) relative to the current module, which is not how it used to be.
> I think the best solution would be for the TilesPreProcessor to actually do the requestDispatcher.forward() (or include) in cases where it finds that the working ForwardConfig is for a tile definition, rather than returning a ForwardConfig. It can return "true" to signal that the chain should end.
> The only argument against this would be if people thought they'd want to add more chain logic after the TilesPreProcessor. I suppose it could set the ForwardConfig to null and let the chain continue.
> I'd love some opinions on this, and it'll be a couple of days before I could do a fix, so please weigh in if you have any. Also, module users are encouraged to step up and help clarify, as I only use them under protest :)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (STR-2879) when used in modules, TilesPreProcessor
not backwards compatible with 1.2.x
Posted by "Joe Germuska (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/STR-2879?page=all ]
Joe Germuska resolved STR-2879:
-------------------------------
Resolution: Fixed
Fixed in SVN commit 408085: TilesPreProcessor now handles forwarding itself with RequestDispatcher, more like what TilesRequestProcessor did in Struts 1.2.x
Also, TilesPreProcessor no longer stops execution of the chain when doing an include; instead, if tiles does either an include or a forward, it clears the forwardConfig from the ActionContext, but it allows the chain to continue processing. I can't think of any use cases myself where I'd need this, but it seemed better to leave it open, and since forwards (the more common case) were allowing the chain to continue before, I chose to preserve that and change the doInclude case to be consistent with the doForward case.
> when used in modules, TilesPreProcessor not backwards compatible with 1.2.x
> ---------------------------------------------------------------------------
>
> Key: STR-2879
> URL: http://issues.apache.org/struts/browse/STR-2879
> Project: Struts Action 1
> Type: Bug
> Components: Tiles
> Versions: 1.3.4
> Reporter: Joe Germuska
> Fix For: 1.3.5
>
> When used in any "module" other than the "root" (or default), the implementation of TilesPreProcessor does not work in the same way that the TilesRequestProcessor did in earlier versions of Struts.
> Specifically, because it does not dispatch the forward itself, it leaves the "module" unarticulated; this causes PerformForward to attempt to resolve the base Tiles JSP (or other path) relative to the current module, which is not how it used to be.
> I think the best solution would be for the TilesPreProcessor to actually do the requestDispatcher.forward() (or include) in cases where it finds that the working ForwardConfig is for a tile definition, rather than returning a ForwardConfig. It can return "true" to signal that the chain should end.
> The only argument against this would be if people thought they'd want to add more chain logic after the TilesPreProcessor. I suppose it could set the ForwardConfig to null and let the chain continue.
> I'd love some opinions on this, and it'll be a couple of days before I could do a fix, so please weigh in if you have any. Also, module users are encouraged to step up and help clarify, as I only use them under protest :)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira