nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

ContextRedirectForwardAction not working in preview

josephbreese

I'm on TeamSite 7.0 and LiveSite 3.1 or 7.0 (whatever the new numbering scheme is)

I'm trying to use a component controller to forward a request to another .page file. after processing a submit request. I've been successful at wiring up a controller to execute upon form submit/POST and I have gotten Http302LocationRedirectForwardAction and UrlRedirectForwardAction to redirect to a .page file in the preview environment, but I can't redirect the request, it must be FORWARDED to the apropriate .page file. All research leads towards using ContextRedirectForwardAction, setting the full redirect flag to "false" so it (the Request) just gets forwarded with no 302 Response back to the client.

I'm not having any luck with the ContextRedirectForwardAction in the preview environment, I keep getting a 404:
[html]
The requested resource (/iw-preview.seed) is not available.
[/html]

Any Suggestions?

Find more posts tagged with

Comments

AlexC

Can you post the code you are using to create the redirect and also an HTTP trace (from HttpWatch, HttpFox, Firebug, etc).

josephbreese

Alex, thanks for the reply.

Search Component
Appearance
[html]

[/html]
Content XML
[html]

com.sci.dm20.livesite.controllers.ObitSearchResultsController
execContextRedirectForwardAction

$PAGE_LINK[results]

com.sci.dm20.livesite.common.NullObject
returnNull

[/html]

Java:


public ForwardAction execContextRedirectForwardAction(RequestContext context)
 { 
  context.getSession().setAttribute("fullname", context.getParameterString("fullname", ""));
  String redirectUrl = context.getParameterString("redirectUrl");
  // this doesn't work
  return new ContextRedirectForwardAction(redirectUrl);
 }

Attached is a screen shot of error message

If there are any log files I need to provide, please let me know where I can find them. Also I don't have HttpWatch (don't have a license) or FireBug (no FF installed), I can provide logs from Fiddler (free), but they don't appear to be in a simple text format.

AlexC

That 404 means your iw-preview context is not working, can you please stop content center (servletd), backup content_center.log, servletd_out.log and livesite.preview.log. Then restart content center and check those 3 files for exceptions.

josephbreese

Alex, here are my logs after restarting the Interwoven TeamSite Service and Interwoven Servlet Engine.

If iw-preview is not working, what is allowing me to preview the component when I click on the component name within Content Center, and how do I explicitly know I'm using iw-preview?

AlexC

Component edit/preview is done inside the content center, the iw-preview context is a version of the actual runtime which renders pages (you can't preview components with runtime). If you are getting a 404 on it then something is not working right and I would lean towards config issues.

":10:55:56,328 WARN [TeamSiteServerStatus] TeamSite server is not yet up... trying again in a bit." - this seems odd.

Can you attach content_center.log it also has startup messages of the contexts.

josephbreese

not much in my logs, is there are way to expand logging?
-- contentcenter.log --
2009-12-07 15:45:03,439 [main] INFO com.interwoven.ui.base.util.LoggerLoader () - registering logger config

\Interwoven\TeamSite\httpd\webapps\content_center\WEB-INF\conf\base\log4j.xml
2009-12-07 15:45:03,455 [main] INFO com.interwoven.ui.base.util.LoggerLoader () - registering logger config

\Interwoven\TeamSite\httpd\webapps\content_center\WEB-INF\conf\teamsite\log4j.xml
2009-12-07 15:45:03,470 [main] INFO com.interwoven.ui.base.util.LoggerLoader () - registering logger config

\Interwoven\TeamSite\httpd\webapps\content_center\WEB-INF\conf\vpreview\log4j.xml
2009-12-07 15:45:03,486 [main] INFO com.interwoven.ui.base.util.LoggerLoader () - registering logger config

\Interwoven\TeamSite\httpd\webapps\content_center\WEB-INF\conf\datacapture\log4j.xml
2009-12-07 15:45:03,486 [main] INFO com.interwoven.ui.base.util.LoggerLoader () - registering logger config

\Interwoven\TeamSite\httpd\webapps\content_center\WEB-INF\conf\ccpro\log4j.xml

I'm very far from an expert in log4j configuration especially with all the log files and different ways to set up logging (xml files vs content center admin UI). I suspect I need to increase the level of detail in the logs, but I'm not sure how.

AlexC

You can set the logging level to DEBUG.

Look in the log4j.xml in iw-preview context (WEB-INF/classes if I remember correctly) and look for an entry for com.interwoven.livesite, it is WARN by default, change that to DEBUG and do "iwreset -ui" you will then see a lot more messages. You can do the same for the content_center/livesite file to get the sitepublisher to log debug level. You can set it back to WARN when done to avoid having the large log files when they are not needed.

AlexC

Looking at contentcenter.log, there is no entry for iw-preview context... I suspect your content center web.xml is misconfigured. You may need to contact support and have them set up a livemeeting session and diagnose the config problem.

josephbreese

Looking at contentcenter.log, there is no entry for iw-preview context... I suspect your content center web.xml is misconfigured. You may need to contact support and have them set up a livemeeting session and diagnose the config problem.

Alex, thanks for the logging info for dubugging.

Attached is a snippet of servletd.log obtained from the point of clicking on a component to preview it, and then clicking on a submit button that tries to ContextForward to the page selected by a PageLink Datum.

I had to 7zip and then append a .txt extension as the file was too large to directly include in this post or as attachment.

AlexC

According to the log it looks like the controller executed correctly and it detected a redirection. Nest step is to log all the HTTP requests.

Get the plugin for Firefox called HttpFox, Start it and then go through this flow, then export the URL list and post it, this would be helpful in knowing where the browser is being redirected.

josephbreese

here is the HttpFox URL list:


GET 200 text/html http://localhost/iw-preview/52616e646f6d495646e36574c9b4d376d29323df2177d61bf33d6980b01df4d0010fd040c62c53006af933562d59f0294732f624a1e78fa0eadf7b5293f33f6fca92953b3aa65108/g2z8dbxv.seed
GET 404 text/html http://localhost/iw/cci/meta/no-injection/iw-mount/iwadmin/main/livesite/test/WORKAREA/shared/sites/DignityMemorial20_Test/css/global.css
GET 200 application/x-javascript http://localhost/iw/cci/meta/no-injection/iw-mount/iwadmin/main/livesite/test/WORKAREA/shared/dm-resources/js/global.js
GET 200 application/x-javascript http://localhost/iw/cci/meta/no-injection/iw-mount/iwadmin/main/livesite/test/WORKAREA/shared/dm-resources/js/header_menus.js
GET 200 application/x-javascript http://localhost/iw/cci/meta/no-injection/iw-mount/iwadmin/main/livesite/test/WORKAREA/shared/dm-resources/js/header_type.js
POST 404 text/html http://localhost/iw-preview/52616e646f6d495646e36574c9b4d376d29323df2177d61bf33d6980b01df4d0010fd040c62c53006af933562d59f0294732f624a1e78fa0eadf7b5293f33f6fca92953b3aa65108/g2z8dbxv.seed?submit=true&componentID=1260310565296

this is previewing a page, and then clicking on a button that submits the form, executes a controller and then tries to use context forwarding.

SYSTEMTYPE.txt

AlexC

From the looks of this, it seems that the seed file is missing (that seed file contains preview data and is needed to render the page). I will ask the devs that worked on this and see what is going on.

AlexC

I checked and this is a known bug in preview only and works in runtime. I will file a bug to have this fixed for the next release.

josephbreese

wow, that's a bummer. can you supply the bug number when it's filed so I can track this?

Adam Stoller

wow, that's a bummer. can you supply the bug number when it's filed so I can track this?

Good luck - unless you work at Autonomy, the bug id values no longer seem to be trackable

AlexC

I dug through the code and have a few suggestions. The redirect you are doing is using the internal dispatcher which does not do a 302 redirect it does an internal redirect which I don't think you intended.

Can you try the following in your controller code (adding true to force a full redirect which invokes a 302:

return new ContextRedirectForwardAction(redirectUrl, true);

Use a different redirect class such as Http302LocationRedirectForwardAction or the older URLRedirectForwardAction. Difference is that Http302 one allows for malformed URLs (like relative ones) while URL one requires a valid well formed URL, either should work and that is what we use for redirecting our controllers, the context one is specific to one usecase (I forget which one at this time, it was written a long time ago to solve an issue with maybe workflows).

josephbreese

I dug through the code and have a few suggestions. The redirect you are doing is using the internal dispatcher which does not do a 302 redirect it does an internal redirect which I don't think you intended.

Can you try the following in your controller code (adding true to force a full redirect which invokes a 302:

return new ContextRedirectForwardAction(redirectUrl, true);

Use a different redirect class such as Http302LocationRedirectForwardAction or the older URLRedirectForwardAction. Difference is that Http302 one allows for malformed URLs (like relative ones) while URL one requires a valid well formed URL, either should work and that is what we use for redirecting our controllers, the context one is specific to one usecase (I forget which one at this time, it was written a long time ago to solve an issue with maybe workflows).

I'm not an expert in HTTP but as I understand it under some circumstances, it makes sense to forward requests without a 302 response, such as SEO ranks can being affected by redirects differently than non redirects or forwards. I really do want to have the ability to forward the request using a "request dispatcher", so it was not an unintentional coding mistake.

Is there any way to forward a request without sending a 302 response?

AlexC

The context redirect works in runtime, it is only during preview that it does not behave as expected. At the moment you can either use 302 which works in preview and runtime or use the dispatch in runtime only.

josephbreese

The context redirect works in runtime, it is only during preview that it does not behave as expected. At the moment you can either use 302 which works in preview and runtime or use the dispatch in runtime only.

Okay, from the previous message it sort or read like ContextRedirect wouldn't work in runtime either and the UrlRedirect or Http302 were my only options.

I'll give it a go today and post my results.

tec_iwov

there is currently an issue with doing redirects within the preview framework.