DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192 forward element redirect and className attributes not honored [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-14 10:40 --- Thanks for sorting this out, Akos :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192 forward element redirect and className attributes not honored [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-01-24 19:25 --- Since Martin Cooper wrote me: Why did you mark this fixed? The code isn't going to get changed if the bug is already fixed! I re-open the bug, so that the fix will get included in the source code... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192 forward element redirect and className attributes not honored --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 12:56 --- Try it with controller nocache=true/ The HTTP server must be providing the page from the cache rather than issuing a formal redirect. Of course, whether that happens is outside the scope of Struts. I am certain the feature works, and the test is returning a false negative. Regardless of what is logged, (unfortunately) the only way for the address in the browser's location bar to change is for a redirect to be issued. It does indeed WORKSFORME. :) Otherwise, if you can provide a patch to alter the behavior so that it meets your requirements, we will gladly consider it. But as it stands, I feel like I'm spending a great deal of my very limited, volunteer time proving that something already works :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192 forward element redirect and className attributes not honored [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2004-01-19 08:06 --- unfortunately, there is no example for in the struts-blank or the struts-example applications for this behaviour. no forward tag in struts-config.xml contain the redirect=true attribute. as you're missing evidence, here's a wget log of what happens if I force the redirect property of the ActionForward element to be true by hand, by writing the following code into the action class: ActionForward forward = mapping.findForward(success); return new ActionForward(forward.getName(), forward.getPath(), true, forward.getContextRelative()); if I do a wget for this action, I get: $ wget http://localhost:8080/uts/deleteUrl.do?id=32 --08:57:11-- http://localhost:8080/uts/deleteUrl.do?id=32 = `deleteUrl.do?id=32' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://localhost:8080/uts/showUrlList.do;jsessionid=4394272D8874055019EDB0572462BA26 [following] --08:57:12-- http://localhost:8080/uts/showUrlList.do;jsessionid=4394272D8874055019EDB0572462BA26 = `showUrlList.do' Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 200 OK Length: 1,336 [text/html] 100%[] 1,336 1.27M/sETA 00:00 08:57:12 (1.27 MB/s) - `showUrlList.do' saved [1336/1336] please note the following part: HTTP request sent, awaiting response... 302 Moved Temporarily and that the original URL of deleteUrl.do?id=32 was redirected to showUrlList.do. this is the expected behaviour. on the other hand, if I don't create a new dummy ActionForward element, just use: return mapping.findForward(success); then I get the following: $ wget http://localhost:8080/uts/deleteUrl.do?id=32 --09:03:27-- http://localhost:8080/uts/deleteUrl.do?id=32 = `deleteUrl.do?id=32' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 200 OK Length: 1,330 [text/html] 100%[] 1,330 1.27M/sETA 00:00 09:03:28 (1.27 MB/s) - `deleteUrl.do?id=32' saved [1330/1330] clearly, there was no redirect sent to the client. in both of the above cases, the forward element in struct-config.xml was the same: forward name=success path=/showUrlList.do redirect=true/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192 forward element redirect and className attributes not honored [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2004-01-18 23:41 --- for your question, on what was displayed on the browser: the page that should have been forwarded, but with the 'old' action URL. which means, that it was just a forward, not a redirect. as for ActionForward elements are beans storing the configuration: yes, that was my assumption as well, this is why I see it as a problem that they do not represent the setting of the XML config file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192 forward element redirect and className attributes not honored [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-01-19 03:45 --- I don't mean to be rude, but I don't see that your approach to testing this feature is valid. These logging messages would print *before* the redirect has had a chance to execute and simply don't prove anything. The feature does work when appropriately. Please see the struts-blank application and the new examples application in the nightly build for examples as to appropriate usuage. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26192 forward element redirect and className attributes not honored [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-01-17 04:22 --- The redirect doesn't occur when the ActionForward is access, but when it is process by the controller, after it is returned by the Action class. The ActionForward beans are not actors, but merely descriptors that the RequestProcesor uses to execute the redirect later. The question is not what was printed to standard error, but what page was displayed in the browser. To the taglib exercise module of the new examples application, I added a test to the html:link page that shows a forward ... redirect=true path=/ / does work as expected. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
