J T wrote:
From: Laurie Harper <laurie <at> holoweb.net>
Subject: Re: Leading slash on forward causes problem in proxied
environments<http://news.gmane.org/find-root.php?message_id=%3cdrop13%24ipn%241%40sea.gmane.org%3e>
Newsgroups: 
gmane.comp.jakarta.struts.user<http://news.gmane.org/gmane.comp.jakarta.struts.user>
Date: 2006-01-31 22:40:35 GMT (23 hours ago)

J T wrote:
We have four environments: dev, int, stg, and prod. Each of these is fronted
by an apache server
that proxies to our weblogic application server.

The URLs to the apps look like this
(dev) http://devserver.com/dev/Application
(int) http://intserver.com/int/Application
(stg) http://stgserver.com/stg/Application
(prod) http://prodserver.com/Application (no directory)


Two of my actions look like this
<action
   path="/viewMain"
   parameter=".Main"
   name="myForm"
   validate="false"
   type="org.apache.struts.actions.ForwardAction"
   scope="session">
</action>

<action
   path="/processMain"
   name="myForm"
   input=".Main"
   type="com.company.action.ProcessFormAction"
   scope="session"
   validate="true">
    <forward name="success" path="/viewNew.do"/>
</action>


When my jsp is rendered in the dev environment it looks like this…

...
<head>
    <base href="http://devserver.com/Application/jsp/mainLayout.jsp";>

...
</head>

...
<form name="myForm" method="POST" action="/Application/processMain.do">
    <input type="text" name="mynbr" value="">
    <input type="submit" value="Submit">
</form>

...

So when I click submit the POST goes to http://devserver.com/Application/
and not http://devserver.com/dev/Application

I don't want to hard code my struts-config since this needs be
deployed to 4 places.

I have read through the mailing list archives and the only viable
solution that I have seen is to create a base action that strips the
leading slash off of the forwards so that the POST goes back to
the right place.

Is there a better way of doing this?

See:

http://struts.apache.org/struts-doc-1.2.x/userGuide/struts-html.html#base
<http://struts.apache.org/struts-doc-1.2.x/userGuide/struts-html.html#base>
html:base tag, will set up your <base> element for you so you can use
relative URLs

http://struts.apache.org/struts-doc-1.2.x/userGuide/struts-html.html#link
<http://struts.apache.org/struts-doc-1.2.x/userGuide/struts-html.html#link>
html:link tag, helps construct URLs without having to know the
deployment context path, etc.

Between the two, you should be able to make your application independent
of the path under which you deploy it.

L.


<html:base> did not work in this case because the leading slash on the
form action
would always send the browser back to /Application (e.g. even if
changed my base to

http://devserver.com/dev <http://devserver.com/Application/jsp/mainLayout.jsp>
the form would still submit to

http://devserver.com/Application
<http://devserver.com/Application/jsp/mainLayout.jsp>

Well, yes, the HTML 'base' element only affects how the browser deals with *relative* URLs.
I ended up creating my own struts-html.tld that specified my class for
FormTag so I ended up with some like
this:

public class MyFormTag extends FormTag {

protected void renderAction(StringBuffer results) {
   HttpServletResponse response =(HttpServletResponse)
this.pageContext.getResponse();

   // call our config file to get intermediate directory
   String intmdir = "/dev";

   results.append(" action= " + intmdir );
        results.append(
            response.encodeURL(
                TagUtils.getInstance().getActionMappingURL(
                    this.action,
                    this.pageContext)));

        results.append("\"");
        }

}


I hope that this is a *good* way to do this. It seems to work ok.

It does have the disadvantage that you now have a config file to update as you move between deployment environments. The html:link tag is there to handle this sort of stuff for you so you don't *have* to write custom code.

If you want to go that route, though, I'd recommend at least using the HttpSerlvetRequest API to look up the context path rather than storing it in a config file you then have to maintain.

L.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to