Is there a reason it has to happen in an action? This looks to be a bit
more suited for an interceptor. I try to separate (logically) the
processing by thinking along these lines - If the processing is
happening on a business object, handle it in an action. If the
processing is affecting the state of the user/request/server, do it in
an interceptor. Interceptors are a bit better suited for getting the raw
request and session objects.

That being said, you can mask the session by using the SessionAware
interface. This will make the session a Map, thus making it more POJOy.

http://struts.apache.org/2.x/docs/how-do-we-get-access-to-the-session.html

To get request parameters in a more POJOy way, you have a few choices.
First, add getters/setters to your action. The parameters will be passed
(and converted if necessary) to the action via the setters. If for some
reason you don't know the names of the parameters until runtime, you can
try the ParameterAware interface -

http://struts.apache.org/2.x/docs/how-can-we-access-request-parameters-passed-into-an-action.html

-Wes



On Sun, 2008-02-10 at 13:54 -0500, j alex wrote:
> Hi,
>
> What's the best practice to refer to request and session within an S2 Action
> without tying it to HttpServletRequest or HttpSession ?
>
> Assume that we need to capture values from certain request parameters and do
> some processing based on them, and set session attributes :
>
> Currently, i'm doing it like :
>
> HttpServletRequest request = ServletActionContext.getRequest();
> HttpSession session = request.getSession(true);
> if (null != request.getParameter("param1"))
> session.setAttribute("attr1" , true);
> else
> session.setAttribute("attr1" , false);
>
> This works, but we now have references to HttpServletRequest and HttpSession
> which goes against the S2 "POJO" action / testability benefits etc. (even
> though i may not write a TestCase at all)
>
> What's the best way to do this, so that the Action remains independent of
> http ?
>
> Thanks,
> Joseph

--- j alex <strutstwouser@(protected):
> HttpServletRequest request = ServletActionContext.getRequest();
> HttpSession session = request.getSession(true);
> if (null != request.getParameter("param1"))
> session.setAttribute("attr1" , true);
> else
> session.setAttribute("attr1" , false);
>
> This works, but we now have references to HttpServletRequest and
> HttpSession
> which goes against the S2 "POJO" action / testability benefits etc. (even
> though i may not write a TestCase at all)
>
> What's the best way to do this, so that the Action remains independent of
> http ?

There are several ways to do this, depending on your needs.

Request parameters are set on your actions if you have JavaBean-style
properties exposed via names the same as the parameter name. In the above
example you could have a String property named "param1" with its associated
setter, setParam1(). Then you don't have to do *anything*; it's just set
(assuming you're using the default interceptor stack).

This is pretty basic S2 functionality, so you might want to check out the
tutorials and guides on the S2 wiki [1,2].

You can also access the request or session parameter maps by implementing the
ParameterAware or SessionAware interfaces [3,4].

You can also access the request or session parameter maps via the
ActionContext class using the getParameters() and getSession() methods,
avoiding all references to Servlet Spec-specific classes [5].

The S2 wiki and the JavaDocs are your friends.

Dave

[1] S2 Tutorials: http://struts.apache.org/2.x/docs/tutorials.html
[2] S2 Guides: http://struts.apache.org/2.x/docs/guides.html
[3]
ParameterAware:http://struts.apache.org/2.0.11/struts2-core/apidocs/org/apache/struts2/interceptor/ParameterAware.html
[4] SessionAware:
http://struts.apache.org/2.0.11/struts2-core/apidocs/org/apache/struts2/interceptor/SessionAware.html
[5] ActionContext: http://struts.apache.org/2.0.11/struts2-core/apidocs/com/opensymphony/xwork2/ActionContext.html

--- j alex <strutstwouser@(protected):
> Thanks , i didn't want to have the request parameters as javabeans within
> the Action because they are used only for one-time checks and based on
> their values, some other Action properties are set. The parameter names
> could change later, and i didn't want that to affect the Action.

You'd have to change the code anyway, and IMO it's messier and more
error-prone to use hard-coded strings like you're doing.

> Now, i tried the following to retrieve the params from ActionContext (did
> not implement ParametersAware or SessionAware)
>
> Map requestParams = ActionContext.getContext().getParameters();
>
> productCodes = new String[] {(String) requestParams.get("param1"), (String)
> requestParams.get("param2")},
>
> This gives the following exception :
>
> java.lang.ClassCastException: [Ljava.lang.String; incompatible with
> java.lang.String
>
> can't figure what's going on here..

...

When I run across something like that I take the following approach:

Q: Why am I getting a class-cast exception?
A: I'm getting String[] instead of a single String.

Q: What's in the String[] I'm actually getting?
A: [Uses logging or debugger to find out]

That's usually enough to answer the question.

Dave

Often parameters are sent over the wire as a group, think of a '<select
multiple="true"'. So, calls like requestParams.get(String) will return
an array (even when only one copy of a param is sent). So, just
reference the first index like this -

productCodes = new String[] {(String) requestParams.get("param1")[0],...

I'm pretty sure it's a primitive array, but it might be a more elegant
object. You can usually tell by the "[L."

On Sun, 2008-02-10 at 15:02 -0500, j alex wrote:
> Thanks , i didn't want to have the request parameters as javabeans within
> the Action because they are used only for one-time checks and based on
> their values, some other Action properties are set. The parameter names
> could change later, and i didn't want that to affect the Action.
>
> Now, i tried the following to retrieve the params from ActionContext (did
> not implement ParametersAware or SessionAware)
>
> Map requestParams = ActionContext.getContext().getParameters();
>
> productCodes = new String[] {(String) requestParams.get("param1"), (String)
> requestParams.get("param2")},
>
> This gives the following exception :
>
> java.lang.ClassCastException: [Ljava.lang.String; incompatible with
> java.lang.String
>
> can't figure what's going on here..
>
> On Feb 10, 2008 2:10 PM, Dave Newton <newton.dave@(protected):
>
> > --- j alex <strutstwouser@(protected):
> > > HttpServletRequest request = ServletActionContext.getRequest();
> > > HttpSession session = request.getSession(true);
> > > if (null != request.getParameter("param1"))
> > > session.setAttribute("attr1" , true);
> > > else
> > > session.setAttribute("attr1" , false);
> > >
> > > This works, but we now have references to HttpServletRequest and
> > > HttpSession
> > > which goes against the S2 "POJO" action / testability benefits etc.
> > (even
> > > though i may not write a TestCase at all)
> > >
> > > What's the best way to do this, so that the Action remains independent
> > of
> > > http ?
> >
> > There are several ways to do this, depending on your needs.
> >
> > Request parameters are set on your actions if you have JavaBean-style
> > properties exposed via names the same as the parameter name. In the above
> > example you could have a String property named "param1" with its
> > associated
> > setter, setParam1(). Then you don't have to do *anything*; it's just set
> > (assuming you're using the default interceptor stack).
> >
> > This is pretty basic S2 functionality, so you might want to check out the
> > tutorials and guides on the S2 wiki [1,2].
> >
> > You can also access the request or session parameter maps by implementing
> > the
> > ParameterAware or SessionAware interfaces [3,4].
> >
> > You can also access the request or session parameter maps via the
> > ActionContext class using the getParameters() and getSession() methods,
> > avoiding all references to Servlet Spec-specific classes [5].
> >
> > The S2 wiki and the JavaDocs are your friends.
> >
> > Dave
> >
> > [1] S2 Tutorials: http://struts.apache.org/2.x/docs/tutorials.html
> > [2] S2 Guides: http://struts.apache.org/2.x/docs/guides.html
> > [3]
> > ParameterAware:
> > http://struts.apache.org/2.0.11/struts2-core/apidocs/org/apache/struts2/interceptor/ParameterAware.html
> > [4] SessionAware:
> >
> > http://struts.apache.org/2.0.11/struts2-core/apidocs/org/apache/struts2/interceptor/SessionAware.html
> > [5] ActionContext:
> > http://struts.apache.org/2.0.11/struts2-core/apidocs/com/opensymphony/xwork2/ActionContext.html
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@(protected)
> > For additional commands, e-mail: user-help@(protected)
> >
> >

Hi friends
I'm using Struts 1.2.7 and Tomcat 5.5.25 server.
Can we forward a HttpRequest to the files under /WEB-INF folder? I've read
in "Struts Survival Guide" that we can do so with tomcat server but not with
other servers. Is that true?

I need the answer because I'm trying to move all my JSP files in /includes
folder to /WEB-INF/jsp for better security.

D.Sai Reddy
VNR VJIET.

--- Sai Reddy <dubbakasai@(protected):
> I'm using Struts 1.2.7 and Tomcat 5.5.25 server.
> Can we forward a HttpRequest to the files under /WEB-INF folder? I've read
> in "Struts Survival Guide" that we can do so with tomcat server but not
> with other servers. Is that true?

I'm not actually familiar with every other server (there are a lot). IIRC the
spec says that the container should be able to forward to JSPs under WEB-INF;
some earlier servers (again, IIRC) didn't allow that.

You'd be better off asking on a forum more relevant to generic JEE questions
or for whatever server you're targeting, as this isn't really Struts-related.

Dave

--- stanlick@(protected):
> OGNL is always involved

Except when it isn't, I suppose. Don't forget that the EL is pluggable in
S2.1 and AFAICT has been abstracted out of XW2.

The OGNL here is buried in the S2.0/XW1 parameters interceptor and the
corresponding S2 documentation for handling lists is in type conversion.

> On Feb 10, 2008 12:25 PM, Dave Newton <newton.dave@(protected):
> > --- stanlick@(protected):
> > > This might be old hat for some of you, but I recently had a scenario
> > where
> > > OGNL made the solution sweet!
> > >
> > > Check it out! <http://strutsschool.com//util/blog.action>
> >
> > I might classify that as type conversion rather than OGNL, since there
> > isn't
> > any OGNL involved.
> >
> > Dave
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@(protected)
> > For additional commands, e-mail: user-help@(protected)
> >
> >
>
>
> --
> Scott
> stanlick@(protected)
>

Thank you.


Jeromy Evans - Blue Sky Minds wrote:
>
> If <s:property> if failing to show any data this can only mean the data
> is blank (unlikely) or the object is not available on the Value Stack.
> If we look at your two use cases:
>  Case 1.data is posted to your application, the params are set in your
> action and your action is invoked. Your code in the action validates
> the values and sets an actionError. You return a result and the JSP is
> rendered including the user data and validation data. Everything is fine.
>
>  Case 2. data is posted to your application, the params are set in your
> action and the xml validation interceptor is invoked. The interceptor
> validates the values, sets an actionError and returns the input result.
> The JSP is rendered including the validation data but the user data is
> blank.
>
> The key difference is that in case 2 your action is never invoked so the
> user data is never prepared/loaded for the JSP. Clearly you need some
> way to ensure the user data is loaded without actually invoking action.
> One such approach is to use the "Prepare Interceptor" [1] that is
> typically invoked prior to validation.
>
> The key issue to understand is that if validation fails within the
> interceptor your action is instantiated but not invoked. You have to
> ensure that when your result calls the getter the data is available to it.
>
> Hope that helps,
> Jeromy Evans
>
> [1] http://struts.apache.org/2.x/docs/prepare-interceptor.html
> [2] http://struts.apache.org/2.x/docs/interceptors.html
>
> dfaulcon wrote:
>> I have an interesting problem that I'm dealing with in regards to struts
>> 2
>> validation. I have XML validation setup throughout my application that
>> appear to work fine. The validation returns the appropriate error
>> messages
>> when needed. However I have a user object that is created when a person
>> logs into this application. This object contains their login, business,
>> etc. When any page loads the business name and login are displayed at
>> the
>> top of the page. The code snippet below shows how I'm displaying the
>> user
>> information using the property tag:
>>      <s:property value="user.getBusiness()"/><br />
>>   User: <s:property value="user.getLogin()"/> </td>
>>
>> However when a user is returned to that page due to an error caught by
>> the
>> validation logic the "user" information is never displayed. In my action
>> form the "user" object has getter and setter methods defined. If I
>> validate
>> any data in the action class and set the actionError the error message is
>> displayed along with the user object information. Is there anything I
>> missed why the "user" object information will now show up when  XML
>> validation is used? Thanks.
>>
>>  
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@(protected)
> For additional commands, e-mail: user-help@(protected)
>
>
>

--
Sent from the Struts - User mailing list archive at Nabble.com.

Dave Newton wrote:
> --- stanlick@(protected):
> the EL is pluggable in S2.1 and AFAICT has been abstracted out of XW2.

Is this layer something clean? I have a handful of tags that I've built
that have to capture the attribute string arg, and at evaluation time
evaluate them all (when failing, populating with either the arg string
itself or sane defaults). It seems there must be a cleaner design. If
this abstraction is clean, maybe it's the model I'm looking for...

Where would I look to learn about it?

> The OGNL here is buried in the S2.0/XW1 parameters interceptor and the
> corresponding S2 documentation for handling lists is in type conversion.

I'll guess that this is where I should start looking :-)

-Dale

Dale Newfield wrote:
> tags [...] have to capture the attribute string arg, and at evaluation time
> evaluate them all (when failing, populating with either the arg string
> itself or sane defaults).

Just to clarify: This process is straight forward (and I think all
those steps have to happen somehow), but the way I'm doing it now makes
for lots of ugly cut and paste coding that seems error-prone.

-Dale

If your keys are just numbers, perhaps you could use the Int Validator

<field-validator type="int">
<param name="min">0</param>
<message key="required.country"></message>
</field-validator>

http://struts.apache.org/2.x/docs/int-validator.html

Otherwise I'd try some variations of the expression. It's operating on
the getUser().getCountry() property of your action so the expression
(user.country == '-1') must be valid for its type.

Raghuveer Rawat wrote:
> Hi, I need help for mandatory field validation for s:select.
> I am trying to do client side xml validation.
>
> jsp code for country list:
>
> <s:select name="user.country" headerKey="-1" headerValue="Select Country"
>                   list="countryList" listKey="code"
> listValue="name" required="true" />
>
> I tried with below validation code but it is not working.. Not sure what
> will be other approach..
>
> <field name="user.country">
>      <field-validator type="fieldexpression">
>         <param name="expression"><![CDATA[user.country ==
> '-1']]></param>
>         <message key="required.country"></message>
>      </field-validator>
>   </field>
>
>  Thanks a lot...
>
>  
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.19.21/1267 - Release Date: 8/02/2008 8:12 PM
>  

I have recently been struggling with a utf-8 to ISO-8859-1 problem with Ajax
and Struts2.

The problem is basically that our application requires iso-8859-1 characters
and Ajax is configured to only post utf-8 (ajax is utf-8 either way, can not
be changed). So some kind of conversion has to take place at some level.

My problem can be divided into two parts:
1. Make Struts2 understand that there is a incoming utf-8 POST, even though
struts.xml (which set the struts2 default encoding) is configured to use
iso-8859-1
2. Convert the characters from utf-8 to iso-8859-1

My first thought was to create an interceptor which could handle the
conversion. It would test if it was a utf-8 post, and then try to convert
it. In my jQuery.ajax function I sat contentType like this:
contentType: "application/x-www-form-urlencoded; charset=utf-8",
But when I debugged my interceptor I noticed that the request character
encoding was changed, even though I sat the charset explicit in the ajax
post. So all my characters were converted into something unreadable before I
was able to do my own conversion (this occurs when you just set the
character encoding without any conversion first).
But why did this happen?

In the class org.apache.struts2.dispatcher.Dispacter, method public void
prepare(HttpServletRequest request, HttpServletResponse response) there are
some logic concerning request character encoding. It looks like this:

public void prepare(HttpServletRequest request, HttpServletResponse
response) {
    String encoding = null;
    if (defaultEncoding != null) {
       encoding = defaultEncoding;
    }

    Locale locale = null;
    if (defaultLocale != null) {
       locale = LocalizedTextUtil.localeFromString(defaultLocale,
request.getLocale());
    }

    if (encoding != null) {
       try {
          request.setCharacterEncoding(encoding);
       } catch (Exception e) {
          LOG.error("Error setting character encoding to '" + encoding
+ "' - ignoring.", e);
       }
    }

    if (locale != null) {
       response.setLocale(locale);
    }

    if (paramsWorkaroundEnabled) {
       request.getParameter("foo"); // simply read any parameter
(existing or not) to "prime" the request
    }
  }

If you take a look at this piece of code, you can see that it overrides the
encoding if it is set as defaultEncoding (from struts.xml). This is OK, the
problem is this check:
if (encoding != null) {
       try {
          request.setCharacterEncoding(encoding);
       } catch (Exception e) {
          LOG.error("Error setting character encoding to '" + encoding
+ "' - ignoring.", e);
       }
    }

I think the correct thing would be to also do a check if the
request.getCharacterEncoding was already set. I should look like this:
if (encoding != null && request.getCharacterEncoding() == null ) {
       try {
          request.setCharacterEncoding(encoding);
       } catch (Exception e) {
          LOG.error("Error setting character encoding to '" + encoding
+ "' - ignoring.", e);
       }
    }
With this change utf-8 would be kept as the request character encoding and I
could do my conversion in my interceptor.
This would solve my problem number 1. Am I correct when I say this is a bug?

The way I went around it was to create a filter which is executed before
FilterDispatcher in struts2. In this filter I check if it is a uft-8 post
and if it is, I wrap the HttpServletRequest into my own
CharsetRequestWrapper. In my wrapper I will override getParameterMap which
converts my characters, put them back into the map and return them. I also
run a req.getParameter("foo"); after my wrapping to populate the parameters
on the request.

It works, but it took me a couple of days to work it out.

Any comments on this?

--
Sent from the Struts - User mailing list archive at Nabble.com.

2008/2/11, Marc Eckart <marc.eckart@(protected)>:
> But we are not so happy with this frame aproaches in general. But we don't
> know how to integrate the different (indepentend) applications transparent
> to the users without frames.

A portlet container?

Antonio

Hi!

Anyone knows why my javascript code is executed at the loading of a page
instead when it *should*??

For example, I have a .jspx page with a form:

<form>
  ...
  <input id="id" ...>
  ...
<form>

<script>
  alert('hi');
  alert(document.getElementById('id'));
</script>


'hi' is shown before the form and then 'undefined'.
But my js code is at the end of the page. How can it be possible? I´m
sure it is a dojo thing, but I don´t know how to solve it. I access to
this page from another one where I have executeScripts="true".

Thanks.

Try to put your JavaScript in page header and use onload

<header>

<script>
window.onload = function() {
alert('hi');
alert(document.getElementById('id'));
}
</script>
</header>


Regards
--
Lukasz

http://www.linkedin.com/in/lukaszlenart

What I want is to execute my js after the page is loaded (so, the normal
behabiour), not while it is loading. And I would like to add my
javascript behaviour when necessary (on demand, no in page header). Is
it possible? I have always done so but now with dojo and struts 2.

Lukasz Lenart escribió:
> Try to put your JavaScript in page header and use onload
>
> <header>
>
> <script>
> window.onload = function() {
>  alert('hi');
>  alert(document.getElementById('id'));
> }
> </script>
> </header>
>
>
> Regards
>  

--- Pablo Vázquez Blázquez <pvazquez@(protected):
> What I want is to execute my js after the page is loaded (so, the normal
> behabiour), not while it is loading.

"window.onload" does not execute while the page is loading; that wouldn't
make any sense: it executes after all page-related requests have been made. I
don't know if that necessarily means that every browser will have rendered
the entire DOM; you'd need to ask a question like that in a more appropriate
forum.

In any case, see my other response to your original question, which details a
more Dojo-friendly method.

Dave

Thanks Dave. I had already written this post before seeing your other
response.

I´ll try dojo.addOnLoad(fn).

Dave Newton escribió:
> --- Pablo Vázquez Blázquez <pvazquez@(protected):
>  
>> What I want is to execute my js after the page is loaded (so, the normal
>> behabiour), not while it is loading.
>>  
>
> "window.onload" does not execute while the page is loading; that wouldn't
> make any sense: it executes after all page-related requests have been made. I
> don't know if that necessarily means that every browser will have rendered
> the entire DOM; you'd need to ask a question like that in a more appropriate
> forum.
>
> In any case, see my other response to your original question, which details a
> more Dojo-friendly method.
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@(protected)
> For additional commands, e-mail: user-help@(protected)
>
>  

--- Pablo Vázquez Blázquez <pvazquez@(protected):
> Anyone knows why my javascript code is executed at the loading of a page
> instead when it *should*??

Mostly because of your definition of "should" ;)

> For example, I have a .jspx page with a form:
> <form>
>   ...
>   <input id="id" ...>
>   ...
> <form>
>
> <script>
>   alert('hi');
>   alert(document.getElementById('id'));
> </script>
>
> 'hi' is shown before the form and then 'undefined'.
> But my js code is at the end of the page. How can it be possible?

Just because your JavaScript is at the end of the page doesn't mean the
entire page (thus the DOM) will be rendered before your JavaScript executes,
and it may be browser-dependent.

As was pointed out you can put your JavaScript in a window.onload section;
IIRC this will wait until *everything* has loaded, including images etc.

However, putting such JavaScript in an "window.onload" handler *may*
interfere with Dojo's own onload handler, which may do DOM rewriting and so
on.

Instead try using Dojo's:

dojo.addOnLoad(aFunction)

where "aFunction" is either a function reference or an anonymous function.

See dojo.addOnLoad [1] and a short blog post [2] for some further
information.

Dave

[1] Dojo's dojo.addOnLoad function:
http://redesign.dojotoolkit.org/jsdoc/dojo/HEAD/dojo.addOnLoad
[2]
http://www.dev411.com/blog/2006/07/13/dojo-dojo-addonload-vs-body-onload-and-window-onload