Well, that's an option. Another thing I would need to get is the Remote 
Address. That can be complicated, since sometimes -specially when you are 
behind a proxy, or something like that- the IP address you get is not correct. 
In those cases with a proxy usually the IP is in a header in the request(For 
example, if you are using Apache, you will get a "x-forwarded-for" header in 
the request). I was thinking about doing an interceptor that can be setup to 
look for that header(Or one similar, that can be setup in the struts xml) and 
if it's not present, set the IP into the action. What do you think?

Jose

-----Original Message-----
From: Li Ying [mailto:liying.cn.2...@gmail.com] 
Sent: Tuesday, October 26, 2010 3:32 AM
To: Struts Users Mailing List
Subject: Re: RequestHeaderAware in Struts 2?

What Chris has said is right.

But what Jose Luis asked for is a inject mechanism likes ParameterAware which 
takes all the request params through one Map, but not through several property.

So I think the simpler (also more Quick And Dirty) way is:

(1)Create a interface, likes:
public interface HeaderAware {
        /**
         * Sets the map of request headers in the implementing class.
         *
         * @param headers
         *            a Map of headers (name/value Strings).
         */
        public void setHeaders(final Map<String, String[]> headers); }

(2)implement this interface in your action class (or the common super class of 
all of your actions)

(3)create a interceptor, which inject the headers map to your action class 
likes what ServletConfigInterceptor is doing, the code will likes:

public class RequestHeaderInterceptor extends AbstractInterceptor {
        @Override
        public String intercept(final ActionInvocation invocation) throws 
Exception {
                final Object action = invocation.getAction();

                if (action instanceof HeaderAware) {
                        Map<String, String[]> requestHeaders =
                                        
this.getRequestHeaders(ServletActionContext.getRequest());
                        ((HeaderAware) action).setHeaders(requestHeaders);
                }

                return invocation.invoke();
        }

        private Map<String, String[]> getRequestHeaders(
                        final HttpServletRequest request) {
                Map<String, String[]> headers = new HashMap<String, String[]>();

                // TODO: retrieve all the request headers by
                // HttpServletRequest.getHeaderNames(), 
HttpServletRequest.getHeaders()
                // and put them into Map

                return headers;
        }
}

(4)add RequestHeaderInterceptor into your interceptor-stack



2010/10/26 Chris Pratt <thechrispr...@gmail.com>:
> As far as I'm aware, there's not.  But it wouldn't be hard to write one.
> You could use the ParameterInterceptor as a pattern, but have it take 
> it's data from the headers rather than the parameters and you'd be 
> done in 1/2 hr.  You could get fancier, to make sure Parameters and 
> Headers with the same name don't clash, and use an Annotation to 
> identify which headers to inject into which methods, but that would 
> definitely take more than 1/2 hr.
> =8^)
>  (*Chris*)
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org


Internet communications are not secure and therefore Banco
Santander International does not accept legal responsibility for
the contents of this message. Any views or opinions presented
are
solely those of the author and do not necessarily represent those
of Banco Santander International unless otherwise specifically
stated.

Las comunicaciones via Internet no son seguras y por lo tanto
Banco Santander International no asume responsabilidad legal
ni
de ningun otro tipo por el contenido de este mensaje. Cualquier
opinion transmitida pertenece unicamente al autor y no
necesariamente representa la opinion del Banco Santander
International a no ser que este expresamente detallado.



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Reply via email to