subject:"character encoding"


And I guess that the form bean attributes is set prior to any code in the
form class, so that you can't set the characterEncoding in the form class
(at, for example, the beginning of initialize() method), or...?

Joe Germuska wrote:
 
I had problem with character encoding in my web application. I was trying
to
display Polish characters using UTF-8 but data from forms was not getting
in
proper format to the business layer. I managed to solve this by setting
filter  which does request.setCharacterEncoding(encoding); But the
question
is: WHY it didn't work when I was using request.setCharacterEncoding() in
Action's execute() method??
 
 The request's character encoding can only be set before the input 
 values are read.  By the time the Action executes, the ActionForm has 
 already been populated, which means that the request has already 
 deserialized the request parameters from bytes on the wire into Java 
 Strings.  Thus, a ServletFilter is the best way to make sure that 
 this value is set at the earliest possible time.
 
 Hope this helps,
   Joe
 
 -- 
 Joe Germuska
 [EMAIL PROTECTED]  
 http://blog.germuska.com
 Narrow minds are weapons made for mass destruction  -The Ex
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Character-encoding...-tf297678.html#a9630453
Sent from the Struts - User mailing list archive at Nabble.com.


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

Re: Character encoding...

2007-03-23 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Riffla,

riffla wrote:
 And I guess that the form bean attributes is set prior to any code in the
 form class, so that you can't set the characterEncoding in the form class
 (at, for example, the beginning of initialize() method), or...?

Correct. You have to use a Filter to do this. Search the archives for
character encoding filter and you should find a lot of information,
including the code for the filter itself (or at least a link to the code).

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGA8QY9CaO5/Lv0PARAn7AAJ4vklzBFWc2/m2Go6EHv68eGoe6LQCgrNcX
peNhqvneyvg8Fsmbn99nwEI=
=LZZ+
-END PGP SIGNATURE-

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

Re: Character encoding...


Thanks for the reply

Actually, we do use a filter setting the encoding to UTF-8, though I'm not
sure if my problem is exactly the same as above.

Sending a request form a JSP using ISO-8859-1 with POST method (no problem
using GET method or UTF-8 on origin page) to either a Struts action or
another JSP (with either UTF-8 or ISO-8859-1, tried both) replaces my å,ä
and ö with '?', even though I've set the Connector property (Tomcat as
server) to UTF-8. So the problem seems to happen with the POST data in the
request when going from ISO to UTF using POST method... having ran my head
against this encoding wall too long now, I'm hoping to get some clues from
you guys...

/Riffla


Christopher Schultz-2 wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Riffla,
 
 riffla wrote:
 And I guess that the form bean attributes is set prior to any code in the
 form class, so that you can't set the characterEncoding in the form class
 (at, for example, the beginning of initialize() method), or...?
 
 Correct. You have to use a Filter to do this. Search the archives for
 character encoding filter and you should find a lot of information,
 including the code for the filter itself (or at least a link to the code).
 
 - -chris
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.7 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFGA8QY9CaO5/Lv0PARAn7AAJ4vklzBFWc2/m2Go6EHv68eGoe6LQCgrNcX
 peNhqvneyvg8Fsmbn99nwEI=
 =LZZ+
 -END PGP SIGNATURE-
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Character-encoding...-tf297678.html#a9634418
Sent from the Struts - User mailing list archive at Nabble.com.


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

Re: Character encoding...

2007-03-23 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Riffla,

riffla wrote:
 Sending a request form a JSP using ISO-8859-1 with POST method (no problem
 using GET method or UTF-8 on origin page) to either a Struts action or
 another JSP (with either UTF-8 or ISO-8859-1, tried both) replaces my å,ä
 and ö with '?'

Where do you see the '?'? In a web page? In a log file? In the results
of a database query from a command-line tool? It's possible that your
output isn't sensitive to the character encoding (for instance, a
terminal window or log file).

 even though I've set the Connector property (Tomcat as
 server) to UTF-8.

URIEncoding=UTF-8 only affects the interpretation of the URL string in
the request, not the body of the request. The body of the request is
interpreted using the content-type HTTP header.

 So the problem seems to happen with the POST data in the
 request when going from ISO to UTF using POST method...

If you are submitting data with a content-type of ISO-8859-1 and then
forcing the request's encoding to be UTF-8, then you are introducing the
problem yourself. ISO != UTF-8, so you shouldn't be doing that. If you
really need to use non-ASCII characters at all, then you should convert
everything to UTF-8. Make sure that all your pages use UTF-8 as the
response encoding, and all POST forms should then use UTF-8 as the
request body encoding.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGBAxn9CaO5/Lv0PARAoNRAJ94LWHNQdZbzTd5wXq6Z/nGfZAsCwCgrkAC
ZupLQFeCLlyi/kit/l9EDxo=
=Gwxy
-END PGP SIGNATURE-

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

Re: Character encoding...


Of course, forgot to mention, mainly I mean as output on a JSP page (both
bean:write and %=...%, but also System.out.println() in different places,
always the same result...

/Riffla



Christopher Schultz-2 wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Riffla,
 
 riffla wrote:
 Sending a request form a JSP using ISO-8859-1 with POST method (no
 problem
 using GET method or UTF-8 on origin page) to either a Struts action or
 another JSP (with either UTF-8 or ISO-8859-1, tried both) replaces my å,ä
 and ö with '?'
 
 Where do you see the '?'? In a web page? In a log file? In the results
 of a database query from a command-line tool? It's possible that your
 output isn't sensitive to the character encoding (for instance, a
 terminal window or log file).
 
 even though I've set the Connector property (Tomcat as
 server) to UTF-8.
 
 URIEncoding=UTF-8 only affects the interpretation of the URL string in
 the request, not the body of the request. The body of the request is
 interpreted using the content-type HTTP header.
 
 So the problem seems to happen with the POST data in the
 request when going from ISO to UTF using POST method...
 
 If you are submitting data with a content-type of ISO-8859-1 and then
 forcing the request's encoding to be UTF-8, then you are introducing the
 problem yourself. ISO != UTF-8, so you shouldn't be doing that. If you
 really need to use non-ASCII characters at all, then you should convert
 everything to UTF-8. Make sure that all your pages use UTF-8 as the
 response encoding, and all POST forms should then use UTF-8 as the
 request body encoding.
 
 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.7 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFGBAxn9CaO5/Lv0PARAoNRAJ94LWHNQdZbzTd5wXq6Z/nGfZAsCwCgrkAC
 ZupLQFeCLlyi/kit/l9EDxo=
 =Gwxy
 -END PGP SIGNATURE-
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Character-encoding...-tf297678.html#a9642739
Sent from the Struts - User mailing list archive at Nabble.com.


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

Re: Character encoding...

2007-03-23 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Riffla,

riffla wrote:
 Of course, forgot to mention, mainly I mean as output on a JSP page (both
 bean:write and %=...%, but also System.out.println() in different places,
 always the same result...

The method of output is not relevant. Only the character encoding is.
Where do you set the character encoding of your pages?

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGBEen9CaO5/Lv0PARAg3FAJ950MJ6Y8XIqGmysRxtphNCETWzogCgq57d
pZH1HfI4X+5nuznbG/9UaXA=
=qVbS
-END PGP SIGNATURE-

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

Re: Character encoding...


Encoding set in:

JSP Page directive
Content inside Html Meta tag
And there is also a charsetFilter class used (see below)

Struts-config.xml contains:
===
controller  contentType=text/html;charset=UTF-8 
processorClass=org.apache.struts.tiles.TilesRequestProcessor/
===

web.xml contains:
===
filter
filter-nameCharacter Encoding/filter-name
filter-classse.telia.kontaktamig.web.util.CharsetFilter/filter-class
/filter

filter-mapping
filter-nameCharacter Encoding/filter-name
url-pattern/*/url-pattern
/filter-mapping

context-param
param-namePARAMETER_ENCODING/param-name
param-valueUTF-8/param-value
/context-param
//To be used and loaded as a common property from within Java/JSP code
===



And beside those alreade mentioned, there's also som lines in
struts-html.tld:
attribute
nameuseLocalEncoding/name
requiredfalse/required
rtexprvaluetrue/rtexprvalue
/attribute
for some tag elements (img, link and rewrite tags)

That's about it...

/Riffla


Christopher Schultz-2 wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Riffla,
 
 riffla wrote:
 Of course, forgot to mention, mainly I mean as output on a JSP page (both
 bean:write and %=...%, but also System.out.println() in different
 places,
 always the same result...
 
 The method of output is not relevant. Only the character encoding is.
 Where do you set the character encoding of your pages?
 
 - -chris
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.7 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFGBEen9CaO5/Lv0PARAg3FAJ950MJ6Y8XIqGmysRxtphNCETWzogCgq57d
 pZH1HfI4X+5nuznbG/9UaXA=
 =qVbS
 -END PGP SIGNATURE-
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Character-encoding...-tf297678.html#a9646134
Sent from the Struts - User mailing list archive at Nabble.com.


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

Re: Character encoding...

2007-03-23 Thread Martin Gainty

Riffla-
can we see the contents of se.telia.kontaktamig.web.util.CharsetFilter?
M--
--- 
This e-mail message (including attachments, if any) is intended for the use of 
the individual or entity to which it is addressed and may contain information 
that is privileged, proprietary , confidential and exempt from disclosure. If 
you are not the intended recipient, you are notified that any dissemination, 
distribution or copying of this communication is strictly prohibited.
--- 
Le présent message électronique (y compris les pièces qui y sont annexées, le 
cas échéant) s'adresse au destinataire indiqué et peut contenir des 
renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le 
destinataire de ce document, nous vous signalons qu'il est strictement interdit 
de le diffuser, de le distribuer ou de le reproduire.
- Original Message - 
From: riffla [EMAIL PROTECTED]
To: user@struts.apache.org
Sent: Friday, March 23, 2007 9:42 PM
Subject: Re: Character encoding...


 
 Encoding set in:
 
 JSP Page directive
 Content inside Html Meta tag
 And there is also a charsetFilter class used (see below)
 
 Struts-config.xml contains:
 ===
 controller  contentType=text/html;charset=UTF-8 
 processorClass=org.apache.struts.tiles.TilesRequestProcessor/
 ===
 
 web.xml contains:
 ===
 filter
 filter-nameCharacter Encoding/filter-name
 filter-classse.telia.kontaktamig.web.util.CharsetFilter/filter-class
 /filter
 
 filter-mapping
 filter-nameCharacter Encoding/filter-name
 url-pattern/*/url-pattern
 /filter-mapping
 
 context-param
 param-namePARAMETER_ENCODING/param-name
 param-valueUTF-8/param-value
 /context-param
 //To be used and loaded as a common property from within Java/JSP code
 ===
 
 
 
 And beside those alreade mentioned, there's also som lines in
 struts-html.tld:
 attribute
 nameuseLocalEncoding/name
 requiredfalse/required
 rtexprvaluetrue/rtexprvalue
 /attribute
 for some tag elements (img, link and rewrite tags)
 
 That's about it...
 
 /Riffla
 
 
 Christopher Schultz-2 wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Riffla,
 
 riffla wrote:
 Of course, forgot to mention, mainly I mean as output on a JSP page (both
 bean:write and %=...%, but also System.out.println() in different
 places,
 always the same result...
 
 The method of output is not relevant. Only the character encoding is.
 Where do you set the character encoding of your pages?
 
 - -chris
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.7 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFGBEen9CaO5/Lv0PARAg3FAJ950MJ6Y8XIqGmysRxtphNCETWzogCgq57d
 pZH1HfI4X+5nuznbG/9UaXA=
 =qVbS
 -END PGP SIGNATURE-
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 -- 
 View this message in context: 
 http://www.nabble.com/Character-encoding...-tf297678.html#a9646134
 Sent from the Struts - User mailing list archive at Nabble.com.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts2, tiles2 and character encoding problem

2007-02-08 Thread elin

Reported bug:

https://issues.apache.org/struts/browse/TILES-104

Let's continue any further conversation on the [EMAIL PROTECTED] mailing list.

Joe Germuska wrote:

OK, a few more notes:

just to be clear,

I have specified struts.i18n.encoding=UTF-8.

This is not used to directly set the response character encoding.

I use a CharacterEncodingFilter to set encoding to UTF-8.

In my experience, a CharacterEncodingFilter is used to control the request
content type, not the response content type. That's what the Spring class
called CharacterEncodingFilter does. Assuming yours is the same, it won't
come into play in debugging this problem.

I specify meta http-equiv=content-type content=text/html;
charset=UTF-8/ on the page.

I am not sure whether browsers allow this to override an explicit content
type set in the HTTP response, but in any case, it's more important that
the
HTTP response header be explicitly set. In a local test application I
have,
the servlet container is setting the header even when I don't explicitly
set
it.

Using the latest code, I've tested going directly to a JSP (no struts),
going to a default result (RequestDispatcher.forward) and going to a Tiles
result. I get an explicit content type in all three cases, even though
the
JSP itself doesn't set the content type. I think there's something about
that in the Servlet spec, that the container is required to set a content
type, although that's at odds with what I experienced when I filed
TILES-28
and with Elin's experience, so I'm not sure.

This discussion REALLY belongs on [EMAIL PROTECTED] -- user lists are meant to
discuss using the app, not fixing bugs in prereleased code. Elin, if you
want to pursue this, please file a bug with as much as you can offer for
reproducibility (especially since I just tried and can't reproduce it) and
if you want to have further email, please join the [EMAIL PROTECTED] mailing
list.
See http://tiles.apache.org/mail-lists.html

On 2/7/07, elin [EMAIL PROTECTED] wrote:

I double-checked that there is only one tiles-core jar.

Monitoring shows:

Conventional Struts result response's Content-Type header is
text/html;charset=utf-8

If I request a jsp directly, the response's Content-Type header is
text/html;charset=utf-8

Tiles Result response has no Content-Type header

Elin
--
View this message in context:
http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8845842
Sent from the Struts - User mailing list archive at Nabble.com.

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

--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com

The truth is that we learned from João forever to be out of tune.
-- Caetano Veloso

--
View this message in context:
http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8863903
Sent from the Struts - User mailing list archive at Nabble.com.

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

Re: Struts2, tiles2 and character encoding problem

2007-02-07 Thread elin


Thank you for your reply.

I upgraded from struts 2.0.4 to 2.0.5 but with the same result. I use maven
to build the project which gives me the tiles version
tiles-core-2.0-20070130.184344-3.jar. It seems to be the latest snapshot. Is
this the version where the bug you mentioned is fixed? Or do you mean that
it is fixed in the next build?

Monitoring the response with fiddler shows that there is no content-type
header.

I use a tiles definition file and the insertAttribute tag to build the tiles
result.

Elin
-- 
View this message in context: 
http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8841954
Sent from the Struts - User mailing list archive at Nabble.com.


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

Re: Struts2, tiles2 and character encoding problem

2007-02-07 Thread Joe Germuska

TILES-28 should be resolved in the SNAPSHOT version you indicate, while the
subsequent change (to the Taglib URI) hadn't been changed. I just deployed
a 2.0-SNAPSHOT rather than let it hang on as something less clear going
forward.

But back to your issue: it might seem that you've found a variation of the
problem that was fixed in TILES-28 Make absolutely sure you don't have more
than one version of the tiles-core JAR in your app, but assuming that you
don't, we'll have to sniff around some more and figure out what might be
different. You're doing the right kind of monitoring already -- what does
Fiddler say if you get a conventional Struts result
(ServletDispatcherResult) from your app? What about if you get a JSP
directly from the app without going through Struts?

Joe

On 2/7/07, elin [EMAIL PROTECTED] wrote:

Thank you for your reply.

I upgraded from struts 2.0.4 to 2.0.5 but with the same result. I use
maven
to build the project which gives me the tiles version
tiles-core-2.0-20070130.184344-3.jar. It seems to be the latest snapshot.
Is
this the version where the bug you mentioned is fixed? Or do you mean that
it is fixed in the next build?

Monitoring the response with fiddler shows that there is no content-type
header.

I use a tiles definition file and the insertAttribute tag to build the
tiles
result.

Elin
--
View this message in context:
http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8841954
Sent from the Struts - User mailing list archive at Nabble.com.

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

--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com

The truth is that we learned from João forever to be out of tune.
-- Caetano Veloso

Re: Struts2, tiles2 and character encoding problem

2007-02-07 Thread elin


I double-checked that there is only one tiles-core jar.

Monitoring shows:

Conventional Struts result response's Content-Type header is
text/html;charset=utf-8

If I request a jsp directly, the response's Content-Type header is
text/html;charset=utf-8

Tiles Result response has no Content-Type header



Elin
-- 
View this message in context: 
http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8845842
Sent from the Struts - User mailing list archive at Nabble.com.


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

Re: Struts2, tiles2 and character encoding problem

2007-02-07 Thread Joe Germuska

OK, a few more notes:

just to be clear,

I have specified struts.i18n.encoding=UTF-8.

This is not used to directly set the response character encoding.

I use a CharacterEncodingFilter to set encoding to UTF-8.

I specify meta http-equiv=content-type content=text/html;

charset=UTF-8/ on the page.

I am not sure whether browsers allow this to override an explicit content
type set in the HTTP response, but in any case, it's more important that the
HTTP response header be explicitly set. In a local test application I have,
the servlet container is setting the header even when I don't explicitly set
it.

Using the latest code, I've tested going directly to a JSP (no struts),
going to a default result (RequestDispatcher.forward) and going to a Tiles
result. I get an explicit content type in all three cases, even though the
JSP itself doesn't set the content type. I think there's something about
that in the Servlet spec, that the container is required to set a content
type, although that's at odds with what I experienced when I filed TILES-28
and with Elin's experience, so I'm not sure.

On 2/7/07, elin [EMAIL PROTECTED] wrote:

I double-checked that there is only one tiles-core jar.

Monitoring shows:

Conventional Struts result response's Content-Type header is
text/html;charset=utf-8

If I request a jsp directly, the response's Content-Type header is
text/html;charset=utf-8

Tiles Result response has no Content-Type header

Elin
--
View this message in context:
http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8845842
Sent from the Struts - User mailing list archive at Nabble.com.

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

--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com

The truth is that we learned from João forever to be out of tune.
-- Caetano Veloso

Struts2, tiles2 and character encoding problem

2007-02-06 Thread elin


Hi,

I use struts2 and tiles2 in my web application. When my tiles result
contains data with åäö and I write the data using el, the characters are not
displayed correctly. If I write the data with a struts tag, for example
s:property the characters are displayed correctly.

If I do not to use a tiles result, just a simple jsp, the characters are
displayed correctly when I use el.

I have specified struts.i18n.encoding=UTF-8.

I use a CharacterEncodingFilter to set encoding to UTF-8.

I specify meta http-equiv=content-type content=text/html;
charset=UTF-8/ on the page.

Any ideas?

/Elin



-- 
View this message in context: 
http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8828883
Sent from the Struts - User mailing list archive at Nabble.com.


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

Re: Struts2, tiles2 and character encoding problem

2007-02-06 Thread Joe Germuska

Are you using the newest version of Tiles? There was a bug in which the
content types were not being set in some cases; I was using a JSP page
attribute to set the content type, not the other options, but it may be
related.

For everyone who is using Tiles 2, note that very soon now, the SNAPSHOT
version of Tiles will be changing the URI for the TLD from
http://struts.apache.org/tags-tiles to http://tiles.apache.org/tags-tiles so
you will need to update the taglib declarations in your JSPs. (We use a JSP
include directive like this

%@ include file=/WEB-INF/tiles/_boilerplate.jsp %

so that we only have to change it in one place. If you don't do something
like that, then I hope you have a good global search/replace option... I
will probably build a new Maven SNAPSHOT in the next few days unless another
developer does it first. (Note that if you're using Tiles 2, you probably
ought to monitor the [EMAIL PROTECTED] list in case no one mentions things like
this
to the Struts user list. In general, Apache projects expect discussion of
pre-release software to occur on dev lists, not user lists.)

For reference, the bug to which I refer is
https://issues.apache.org/struts/browse/TILES-28

Joe

On 2/6/07, elin [EMAIL PROTECTED] wrote:

Hi,

I use struts2 and tiles2 in my web application. When my tiles result
contains data with åäö and I write the data using el, the characters are
not
displayed correctly. If I write the data with a struts tag, for example
s:property the characters are displayed correctly.

If I do not to use a tiles result, just a simple jsp, the characters are
displayed correctly when I use el.

I have specified struts.i18n.encoding=UTF-8.

I use a CharacterEncodingFilter to set encoding to UTF-8.

I specify meta http-equiv=content-type content=text/html;
charset=UTF-8/ on the page.

Any ideas?

/Elin

--
View this message in context:
http://www.nabble.com/Struts2%2C-tiles2-and-character-encoding-problem-tf3181491.html#a8828883
Sent from the Struts - User mailing list archive at Nabble.com.

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

--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com

The truth is that we learned from João forever to be out of tune.
-- Caetano Veloso

Re: multipart/form-data and character encoding

2006-05-30 Thread Martin Gainty

Good Morning Antonisis-

If you are sending data which is of UTF-8 characterset then you need to 
configure the request e.g. request.setCharacterEncoding(UTF-8) e.g.
http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletRequest.html#setCharacterEncoding(java.lang.String)

If you are receiving data from a UTF-8 configured server then set the response 
as in response.setCharacterEncoding(UTF-8) e.g.
http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletResponse.html#setCharacterEncoding(java.lang.String)

Martin -
*
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed.  If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy.  Thank you.



- Original Message - 
From: Antonis Lebesis [EMAIL PROTECTED]
To: Martin Gainty [EMAIL PROTECTED]
Cc: Struts Users Mailing List user@struts.apache.org
Sent: Monday, May 29, 2006 8:14 PM
Subject: Re: multipart/form-data and character encoding


 Martin,
 
 I' m not sure what you mean. In my Action's execute() method I get a
 request, a response and an ActionForm object. Whatever I do to the
 request or response objects, the values from the html form are already
 in the actionForm (encoded in a false way). The only way to alter the
 Strings in the actionForm is to change the method
 
 getMyString() {
  return this.myString;
 }
 to
 getMyString() {
  return new String(this.myString.getBytes(), UTF-8);
 },
 
 which I already tried and miserably failed :)
 
 Antonis
 
 On 5/30/06, Martin Gainty [EMAIL PROTECTED] wrote:
 Antonis-

 Did you set the characterEncoding for the response e.g.
 res.setCharacterEncoding(UTF-8)
 ???
 Martin --

 This email message and any files transmitted with it contain confidential
 information intended only for the person(s) to whom this email message is
 addressed.  If you have received this email message in error, please notify
 the sender immediately by telephone or email and destroy the original
 message without making a copy.  Thank you.

 - Original Message -
 From: Antonis Lebesis [EMAIL PROTECTED]
 To: Struts Users Mailing List user@struts.apache.org; Martin Gainty
 [EMAIL PROTECTED]
 Sent: Monday, May 29, 2006 7:26 PM
 Subject: Re: multipart/form-data and character encoding


  Hello Martin,
   I tried your suggestion but there is a difference in my case: The
  enctype in my form's declaration is multipart/form-data (I have to
  support file upload). If I leave it that way, I get the same results
  (no greek characters). If I change it to multipart/form-data;
  charset=iso-8859-7, I get a nice exception :(
 
  javax.servlet.ServletException: BeanUtils.populate
  org.apache.struts.util.RequestUtils.populate(RequestUtils.java:497)
  org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798)
  org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205)
  org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
  org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
  javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
  javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
 
  root cause
 
  java.lang.IllegalArgumentException: argument type mismatch
  sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  java.lang.reflect.Method.invoke(Method.java:585)
  org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.java:1789)
  org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.java:1684)
  org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java:1713)
  org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019)
  org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808)
  org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495)
  org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798)
  org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205)
  org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
  org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
  javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
  javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
 
  Any ideas?
 
  Thanks,
  Antonis
 
  On 5/29/06, Martin Gainty [EMAIL PROTECTED] wrote:
  Good Afternoon Antonis-
 
  This character encoding issue has been addressed
  http://issues.apache.org/struts/browse/STR-2117 as follows
 
  Set your page to use correct character encoding
  %@ page ;contentType=text/html charset=UTF-8

multipart/form-data and character encoding


Hi,
I 've searched the archives but haven't found any solution to my
latest problem. I have with a html:file input and a html:text
input. The problem is that request.getCharacterEncoding() returns null
and the text input is considered to be in iso-8859-1 encoding. In the
corresponding ActionForm's reset(), I have added the following line:
request.setCharacterEncoding(ISO-8859-7);

In forms that don't have a html:file input, the character set is
correct. The problem occurs only in this form and from what I 've
found it is caused by the fact that in the form declaration I have
added enctype=multipart/form-data.

Has anyone solved this problem?

Thanks,
Antonis

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

Re: multipart/form-data and character encoding

2006-05-29 Thread Martin Gainty

Good Afternoon Antonis-

This character encoding issue has been addressed 
http://issues.apache.org/struts/browse/STR-2117 as follows

Set your page to use correct character encoding 
%@ page ;contentType=text/html charset=UTF-8%

Set form to use correct form encoding 
html:form actionmethod...enctype=application/x-www-form-urlencoded; 
charset=UTF-8

Instruct web container to use selected charset when creating request (in 
server.xml)
Connector port..URIEncoding=UTF-8.../

HTH,
Martin --
- Original Message - 
From: Antonis Lebesis [EMAIL PROTECTED]
To: user@struts.apache.org
Sent: Monday, May 29, 2006 2:07 PM
Subject: multipart/form-data and character encoding


Hi,
 I 've searched the archives but haven't found any solution to my
latest problem. I have with a html:file input and a html:text
input. The problem is that request.getCharacterEncoding() returns null
and the text input is considered to be in iso-8859-1 encoding. In the
corresponding ActionForm's reset(), I have added the following line:
 request.setCharacterEncoding(ISO-8859-7);

In forms that don't have a html:file input, the character set is
correct. The problem occurs only in this form and from what I 've
found it is caused by the fact that in the form declaration I have
added enctype=multipart/form-data.

Has anyone solved this problem?

Thanks,
Antonis

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

Re: multipart/form-data and character encoding

2006-05-29 Thread Miguel Galves


Antonis,

we had the same problem with multi part forms. We tried everithing,
including enctype in the
form tag, URIEncoding, and request.setEncoding...in reset() method. All
theses solutions worked
fine with all kinds of requests, except for the mulipart, which is handled
in a different way.

The only solution that really worked for us was to create a subclass of
TilesRequestProcessor,
and override the handleRequest method as follows:

public class ScyllaRequestProcessor extends TilesRequestProcessor {

   public void process(HttpServletRequest request, HttpServletResponse
response) throws IOException,

ServletException {
   try {
   request.setCharacterEncoding(UTF-8);
   } catch (UnsupportedEncodingException e) {
   e.printStackTrace();
   }

   super.process(request, response);
   }

To use this processor, just change the controller entry in struts-config.xml

[]s

Miguel


On 5/29/06, Martin Gainty [EMAIL PROTECTED] wrote:


Good Afternoon Antonis-

This character encoding issue has been addressed
http://issues.apache.org/struts/browse/STR-2117 as follows

Set your page to use correct character encoding
%@ page ;contentType=text/html charset=UTF-8%

Set form to use correct form encoding
html:form actionmethod...enctype=application/x-www-form-urlencoded;
charset=UTF-8

Instruct web container to use selected charset when creating request (in
server.xml)
Connector port..URIEncoding=UTF-8.../

HTH,
Martin --
- Original Message -
From: Antonis Lebesis [EMAIL PROTECTED]
To: user@struts.apache.org
Sent: Monday, May 29, 2006 2:07 PM
Subject: multipart/form-data and character encoding


Hi,
I 've searched the archives but haven't found any solution to my
latest problem. I have with a html:file input and a html:text
input. The problem is that request.getCharacterEncoding() returns null
and the text input is considered to be in iso-8859-1 encoding. In the
corresponding ActionForm's reset(), I have added the following line:
request.setCharacterEncoding(ISO-8859-7);

In forms that don't have a html:file input, the character set is
correct. The problem occurs only in this form and from what I 've
found it is caused by the fact that in the form declaration I have
added enctype=multipart/form-data.

Has anyone solved this problem?

Thanks,
Antonis

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





--
Miguel Galves - Engenheiro de Computação
Já leu meus blogs hoje?
Para geeks http://log4dev.blogspot.com
Pra pessoas normais
http://miguelgalves.blogspot.com

Não sabendo que era impossível, ele foi lá e fez...

Re: multipart/form-data and character encoding


Hello Martin,
 I tried your suggestion but there is a difference in my case: The
enctype in my form's declaration is multipart/form-data (I have to
support file upload). If I leave it that way, I get the same results
(no greek characters). If I change it to multipart/form-data;
charset=iso-8859-7, I get a nice exception :(

javax.servlet.ServletException: BeanUtils.populate
org.apache.struts.util.RequestUtils.populate(RequestUtils.java:497)

org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798)

org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

root cause

java.lang.IllegalArgumentException: argument type mismatch
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)

org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.java:1789)

org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.java:1684)

org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java:1713)
org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019)
org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808)
org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495)

org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798)

org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

Any ideas?

Thanks,
Antonis

On 5/29/06, Martin Gainty [EMAIL PROTECTED] wrote:

Good Afternoon Antonis-

This character encoding issue has been addressed 
http://issues.apache.org/struts/browse/STR-2117 as follows

Set your page to use correct character encoding
%@ page ;contentType=text/html charset=UTF-8%

Set form to use correct form encoding
html:form actionmethod...enctype=application/x-www-form-urlencoded; 
charset=UTF-8

Instruct web container to use selected charset when creating request (in 
server.xml)
Connector port..URIEncoding=UTF-8.../

HTH,
Martin --
- Original Message -
From: Antonis Lebesis [EMAIL PROTECTED]
To: user@struts.apache.org
Sent: Monday, May 29, 2006 2:07 PM
Subject: multipart/form-data and character encoding


Hi,
 I 've searched the archives but haven't found any solution to my
latest problem. I have with a html:file input and a html:text
input. The problem is that request.getCharacterEncoding() returns null
and the text input is considered to be in iso-8859-1 encoding. In the
corresponding ActionForm's reset(), I have added the following line:
 request.setCharacterEncoding(ISO-8859-7);

In forms that don't have a html:file input, the character set is
correct. The problem occurs only in this form and from what I 've
found it is caused by the fact that in the form declaration I have
added enctype=multipart/form-data.

Has anyone solved this problem?

Thanks,
Antonis

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




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

Re: multipart/form-data and character encoding


Miguel,

 If you ever come to Greece, remind me to offer you some ouzo and
mousaka ;) It worked just fine! I' ll keep looking for a more
official solution, but until then you' ve saved me...

Thank you very very much,
Antonis

On 5/29/06, Miguel Galves [EMAIL PROTECTED] wrote:

Antonis,

we had the same problem with multi part forms. We tried everithing,
including enctype in the
form tag, URIEncoding, and request.setEncoding...in reset() method. All
theses solutions worked
fine with all kinds of requests, except for the mulipart, which is handled
in a different way.

The only solution that really worked for us was to create a subclass of
TilesRequestProcessor,
and override the handleRequest method as follows:

public class ScyllaRequestProcessor extends TilesRequestProcessor {

public void process(HttpServletRequest request, HttpServletResponse
response) throws IOException,

ServletException {
try {
request.setCharacterEncoding(UTF-8);
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}

super.process(request, response);
}

To use this processor, just change the controller entry in struts-config.xml

[]s

Miguel


On 5/29/06, Martin Gainty [EMAIL PROTECTED] wrote:

 Good Afternoon Antonis-

 This character encoding issue has been addressed
 http://issues.apache.org/struts/browse/STR-2117 as follows

 Set your page to use correct character encoding
 %@ page ;contentType=text/html charset=UTF-8%

 Set form to use correct form encoding
 html:form actionmethod...enctype=application/x-www-form-urlencoded;
 charset=UTF-8

 Instruct web container to use selected charset when creating request (in
 server.xml)
 Connector port..URIEncoding=UTF-8.../

 HTH,
 Martin --
 - Original Message -
 From: Antonis Lebesis [EMAIL PROTECTED]
 To: user@struts.apache.org
 Sent: Monday, May 29, 2006 2:07 PM
 Subject: multipart/form-data and character encoding


 Hi,
 I 've searched the archives but haven't found any solution to my
 latest problem. I have with a html:file input and a html:text
 input. The problem is that request.getCharacterEncoding() returns null
 and the text input is considered to be in iso-8859-1 encoding. In the
 corresponding ActionForm's reset(), I have added the following line:
 request.setCharacterEncoding(ISO-8859-7);

 In forms that don't have a html:file input, the character set is
 correct. The problem occurs only in this form and from what I 've
 found it is caused by the fact that in the form declaration I have
 added enctype=multipart/form-data.

 Has anyone solved this problem?

 Thanks,
 Antonis

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




--
Miguel Galves - Engenheiro de Computação
Já leu meus blogs hoje?
Para geeks http://log4dev.blogspot.com
Pra pessoas normais
http://miguelgalves.blogspot.com

Não sabendo que era impossível, ele foi lá e fez...




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

Re: multipart/form-data and character encoding

2006-05-29 Thread Miguel Galves


Antonis,

I`m glad to know that your problem is solved. If you find
a more official solution, please let me know. But,  as you, I spent
many hours looking for it, and I didn`t find anything at all.

[]s

miguel

On 5/29/06, Antonis Lebesis [EMAIL PROTECTED] wrote:


Miguel,

  If you ever come to Greece, remind me to offer you some ouzo and
mousaka ;) It worked just fine! I' ll keep looking for a more
official solution, but until then you' ve saved me...

Thank you very very much,
Antonis

On 5/29/06, Miguel Galves [EMAIL PROTECTED] wrote:
 Antonis,

 we had the same problem with multi part forms. We tried everithing,
 including enctype in the
 form tag, URIEncoding, and request.setEncoding...in reset() method. All
 theses solutions worked
 fine with all kinds of requests, except for the mulipart, which is
handled
 in a different way.

 The only solution that really worked for us was to create a subclass of
 TilesRequestProcessor,
 and override the handleRequest method as follows:

 public class ScyllaRequestProcessor extends TilesRequestProcessor {

 public void process(HttpServletRequest request, HttpServletResponse
 response) throws IOException,

 ServletException {
 try {
 request.setCharacterEncoding(UTF-8);
 } catch (UnsupportedEncodingException e) {
 e.printStackTrace();
 }

 super.process(request, response);
 }

 To use this processor, just change the controller entry in
struts-config.xml

 []s

 Miguel


 On 5/29/06, Martin Gainty [EMAIL PROTECTED] wrote:
 
  Good Afternoon Antonis-
 
  This character encoding issue has been addressed
  http://issues.apache.org/struts/browse/STR-2117 as follows
 
  Set your page to use correct character encoding
  %@ page ;contentType=text/html charset=UTF-8%
 
  Set form to use correct form encoding
  html:form
actionmethod...enctype=application/x-www-form-urlencoded;
  charset=UTF-8
 
  Instruct web container to use selected charset when creating request
(in
  server.xml)
  Connector port..URIEncoding=UTF-8.../
 
  HTH,
  Martin --
  - Original Message -
  From: Antonis Lebesis [EMAIL PROTECTED]
  To: user@struts.apache.org
  Sent: Monday, May 29, 2006 2:07 PM
  Subject: multipart/form-data and character encoding
 
 
  Hi,
  I 've searched the archives but haven't found any solution to my
  latest problem. I have with a html:file input and a html:text
  input. The problem is that request.getCharacterEncoding() returns null
  and the text input is considered to be in iso-8859-1 encoding. In the
  corresponding ActionForm's reset(), I have added the following line:
  request.setCharacterEncoding(ISO-8859-7);
 
  In forms that don't have a html:file input, the character set is
  correct. The problem occurs only in this form and from what I 've
  found it is caused by the fact that in the form declaration I have
  added enctype=multipart/form-data.
 
  Has anyone solved this problem?
 
  Thanks,
  Antonis
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 --
 Miguel Galves - Engenheiro de Computação
 Já leu meus blogs hoje?
 Para geeks http://log4dev.blogspot.com
 Pra pessoas normais
 http://miguelgalves.blogspot.com

 Não sabendo que era impossível, ele foi lá e fez...



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





--
Miguel Galves - Engenheiro de Computação
Já leu meus blogs hoje?
Para geeks http://log4dev.blogspot.com
Pra pessoas normais
http://miguelgalves.blogspot.com

Não sabendo que era impossível, ele foi lá e fez...

Re: multipart/form-data and character encoding

2006-05-29 Thread Martin Gainty


Antonis-

Did you set the characterEncoding for the response e.g.
res.setCharacterEncoding(UTF-8)
???
Martin --

This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed.  If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy.  Thank you.

- Original Message - 
From: Antonis Lebesis [EMAIL PROTECTED]
To: Struts Users Mailing List user@struts.apache.org; Martin Gainty 
[EMAIL PROTECTED]

Sent: Monday, May 29, 2006 7:26 PM
Subject: Re: multipart/form-data and character encoding



Hello Martin,
 I tried your suggestion but there is a difference in my case: The
enctype in my form's declaration is multipart/form-data (I have to
support file upload). If I leave it that way, I get the same results
(no greek characters). If I change it to multipart/form-data;
charset=iso-8859-7, I get a nice exception :(

javax.servlet.ServletException: BeanUtils.populate
org.apache.struts.util.RequestUtils.populate(RequestUtils.java:497)
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

root cause

java.lang.IllegalArgumentException: argument type mismatch
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.java:1789)
org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.java:1684)
org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java:1713)
org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019)
org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808)
org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495)
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

Any ideas?

Thanks,
Antonis

On 5/29/06, Martin Gainty [EMAIL PROTECTED] wrote:

Good Afternoon Antonis-

This character encoding issue has been addressed 
http://issues.apache.org/struts/browse/STR-2117 as follows


Set your page to use correct character encoding
%@ page ;contentType=text/html charset=UTF-8%

Set form to use correct form encoding
html:form actionmethod...enctype=application/x-www-form-urlencoded; 
charset=UTF-8


Instruct web container to use selected charset when creating request (in 
server.xml)

Connector port..URIEncoding=UTF-8.../

HTH,
Martin --
- Original Message -
From: Antonis Lebesis [EMAIL PROTECTED]
To: user@struts.apache.org
Sent: Monday, May 29, 2006 2:07 PM
Subject: multipart/form-data and character encoding


Hi,
 I 've searched the archives but haven't found any solution to my
latest problem. I have with a html:file input and a html:text
input. The problem is that request.getCharacterEncoding() returns null
and the text input is considered to be in iso-8859-1 encoding. In the
corresponding ActionForm's reset(), I have added the following line:
 request.setCharacterEncoding(ISO-8859-7);

In forms that don't have a html:file input, the character set is
correct. The problem occurs only in this form and from what I 've
found it is caused by the fact that in the form declaration I have
added enctype=multipart/form-data.

Has anyone solved this problem?

Thanks,
Antonis

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






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

Re: multipart/form-data and character encoding


Martin,

I' m not sure what you mean. In my Action's execute() method I get a
request, a response and an ActionForm object. Whatever I do to the
request or response objects, the values from the html form are already
in the actionForm (encoded in a false way). The only way to alter the
Strings in the actionForm is to change the method

getMyString() {
 return this.myString;
}
to
getMyString() {
 return new String(this.myString.getBytes(), UTF-8);
},

which I already tried and miserably failed :)

Antonis

On 5/30/06, Martin Gainty [EMAIL PROTECTED] wrote:

Antonis-

Did you set the characterEncoding for the response e.g.
res.setCharacterEncoding(UTF-8)
???
Martin --

This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed.  If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy.  Thank you.

- Original Message -
From: Antonis Lebesis [EMAIL PROTECTED]
To: Struts Users Mailing List user@struts.apache.org; Martin Gainty
[EMAIL PROTECTED]
Sent: Monday, May 29, 2006 7:26 PM
Subject: Re: multipart/form-data and character encoding


 Hello Martin,
  I tried your suggestion but there is a difference in my case: The
 enctype in my form's declaration is multipart/form-data (I have to
 support file upload). If I leave it that way, I get the same results
 (no greek characters). If I change it to multipart/form-data;
 charset=iso-8859-7, I get a nice exception :(

 javax.servlet.ServletException: BeanUtils.populate
 org.apache.struts.util.RequestUtils.populate(RequestUtils.java:497)
 
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798)
 org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205)
 org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
 org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

 root cause

 java.lang.IllegalArgumentException: argument type mismatch
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 java.lang.reflect.Method.invoke(Method.java:585)
 
org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.java:1789)
 
org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.java:1684)
 
org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java:1713)
 org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019)
 org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808)
 org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495)
 
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798)
 org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205)
 org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
 org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

 Any ideas?

 Thanks,
 Antonis

 On 5/29/06, Martin Gainty [EMAIL PROTECTED] wrote:
 Good Afternoon Antonis-

 This character encoding issue has been addressed
 http://issues.apache.org/struts/browse/STR-2117 as follows

 Set your page to use correct character encoding
 %@ page ;contentType=text/html charset=UTF-8%

 Set form to use correct form encoding
 html:form actionmethod...enctype=application/x-www-form-urlencoded;
 charset=UTF-8

 Instruct web container to use selected charset when creating request (in
 server.xml)
 Connector port..URIEncoding=UTF-8.../

 HTH,
 Martin --
 - Original Message -
 From: Antonis Lebesis [EMAIL PROTECTED]
 To: user@struts.apache.org
 Sent: Monday, May 29, 2006 2:07 PM
 Subject: multipart/form-data and character encoding


 Hi,
  I 've searched the archives but haven't found any solution to my
 latest problem. I have with a html:file input and a html:text
 input. The problem is that request.getCharacterEncoding() returns null
 and the text input is considered to be in iso-8859-1 encoding. In the
 corresponding ActionForm's reset(), I have added the following line:
  request.setCharacterEncoding(ISO-8859-7);

 In forms that don't have a html:file input, the character set is
 correct. The problem occurs only in this form and from what I 've
 found it is caused by the fact that in the form declaration I have
 added enctype=multipart/form-data.

 Has anyone solved this problem?

 Thanks,
 Antonis

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED

Problem with character encoding.

2006-03-21 Thread Anjishnu Bandyopadhyay


Hi all,



I am generating a MS Word document through a JSP, by setting the JSP's
content type as application/msword;.

The .doc that is generated contains accentuated French characters
(special French characters).



I use Websphere (WSAD) to develop the code, but use Tomcat server for
deployment  final testing.

In WSAD, the .doc file that is generated properly displays the special
characters. But, in Tomcat, these characters are broken (distorted).



The code snippet (in JSP) is as follows:

%@ page language=java contentType=application/msword; charset=UTF-8
pageEncoding=UTF-8 %

%

  String fileName = abc.doc;

  response.setContentType(application/msword);

  response.setLocale(java.util.Locale.FRENCH);

  response.setHeader(Content-Disposition,attachment;filename=+
fileName);

%



Can anyone give me some pointer, regarding the problem might be? Am I
missing out something?



Thanks for your time.



With best regards,

Anjishnu.





 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are 
not to copy, disclose, or distribute this e-mail or its contents to any other 
person and any such actions are unlawful. This e-mail may contain viruses. 
Infosys has taken every reasonable precaution to minimize this risk, but is not 
liable for any damage you may sustain as a result of any virus in this e-mail. 
You should carry out your own virus checks before opening the e-mail or 
attachment. Infosys reserves the right to monitor and review the content of all 
messages sent to or from this e-mail address. Messages sent to or from this 
e-mail address may be stored on the Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

Re: Problem with character encoding.

2006-03-21 Thread Antonio Petrelli


Anjishnu Bandyopadhyay ha scritto:

Hi all,

I am generating a MS Word document through a JSP, by setting the JSP's
content type as application/msword;.
  


Are you using a particular library to generate the file? Anyway 
generating an MS Word file through JSP seems odd to me...



The .doc that is generated contains accentuated French characters
(special French characters).
...

In WSAD, the .doc file that is generated properly displays the special
characters. But, in Tomcat, these characters are broken (distorted).
  


Maybe I am missing something. Does WSAD have something native that 
handles MS Word files? Because Tomcat doesn't!
Anyway, the character set (UTF-8) has nothing to do with the final 
generated file (for the browser it should be a binary file, that must be 
handled by a plugin or an external application).

Ciao
Antonio

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

Re: Problem with character encoding.

2006-03-21 Thread Dan Jas

Are you using WSAD on Windows and Tomcat on Unix/Linux?

- Original Message - 
From: Anjishnu Bandyopadhyay [EMAIL PROTECTED]

To: Struts Users Mailing List user@struts.apache.org
Sent: Tuesday, March 21, 2006 5:51 AM
Subject: Problem with character encoding.

Hi all,

I am generating a MS Word document through a JSP, by setting the JSP's
content type as application/msword;.

The .doc that is generated contains accentuated French characters
(special French characters).

I use Websphere (WSAD) to develop the code, but use Tomcat server for
deployment  final testing.

In WSAD, the .doc file that is generated properly displays the special
characters. But, in Tomcat, these characters are broken (distorted).

The code snippet (in JSP) is as follows:

%@ page language=java contentType=application/msword; charset=UTF-8
pageEncoding=UTF-8 %

%

 String fileName = abc.doc;

 response.setContentType(application/msword);

 response.setLocale(java.util.Locale.FRENCH);

 response.setHeader(Content-Disposition,attachment;filename=+
fileName);

%

Can anyone give me some pointer, regarding the problem might be? Am I
missing out something?

Thanks for your time.

With best regards,

Anjishnu.

 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, 
please notify the sender by e-mail and delete the original message. Further, 
you are not to copy, disclose, or distribute this e-mail or its contents to 
any other person and any such actions are unlawful. This e-mail may contain 
viruses. Infosys has taken every reasonable precaution to minimize this 
risk, but is not liable for any damage you may sustain as a result of any 
virus in this e-mail. You should carry out your own virus checks before 
opening the e-mail or attachment. Infosys reserves the right to monitor and 
review the content of all messages sent to or from this e-mail address. 
Messages sent to or from this e-mail address may be stored on the Infosys 
e-mail system.
***INFOSYS End of Disclaimer INFOSYS*** 

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

Re: Problem with character encoding.

2006-03-21 Thread Dave Newton

Anjishnu Bandyopadhyay wrote:
 I am generating a MS Word document through a JSP, by setting the JSP's
 content type as application/msword;.
   

I really don't understand why you persist in thinking that _calling_
something a Word document _makes_ it a Word document. As I have stated
several times a Word document is a _binary_file_format_.

What are you using to generate the Word document? If you're just
outputting an HTML template (e.g. a standard JSP template) you are NOT
generating a Word document. If you are using a particular library to
properly generate a Word document you'll probably want to ask on a list
for that library.

Dave



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

RE: Problem with character encoding.

2006-03-21 Thread Anjishnu Bandyopadhyay

Hi Dan,

Both are on Windows.

With best regards,
Anjishnu.

-Original Message-
From: Dan Jas [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 21, 2006 9:45 PM
To: Struts Users Mailing List
Subject: Re: Problem with character encoding.

Are you using WSAD on Windows and Tomcat on Unix/Linux?


- Original Message - 
From: Anjishnu Bandyopadhyay [EMAIL PROTECTED]
To: Struts Users Mailing List user@struts.apache.org
Sent: Tuesday, March 21, 2006 5:51 AM
Subject: Problem with character encoding.



Hi all,



I am generating a MS Word document through a JSP, by setting the JSP's
content type as application/msword;.

The .doc that is generated contains accentuated French characters
(special French characters).



I use Websphere (WSAD) to develop the code, but use Tomcat server for
deployment  final testing.

In WSAD, the .doc file that is generated properly displays the special
characters. But, in Tomcat, these characters are broken (distorted).



The code snippet (in JSP) is as follows:

%@ page language=java contentType=application/msword; charset=UTF-8
pageEncoding=UTF-8 %

%

  String fileName = abc.doc;

  response.setContentType(application/msword);

  response.setLocale(java.util.Locale.FRENCH);

  response.setHeader(Content-Disposition,attachment;filename=+
fileName);

%



Can anyone give me some pointer, regarding the problem might be? Am I
missing out something?



Thanks for your time.



With best regards,

Anjishnu.





 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
solely 
for the use of the addressee(s). If you are not the intended recipient, 
please notify the sender by e-mail and delete the original message.
Further, 
you are not to copy, disclose, or distribute this e-mail or its contents
to 
any other person and any such actions are unlawful. This e-mail may
contain 
viruses. Infosys has taken every reasonable precaution to minimize this 
risk, but is not liable for any damage you may sustain as a result of
any 
virus in this e-mail. You should carry out your own virus checks before 
opening the e-mail or attachment. Infosys reserves the right to monitor
and 
review the content of all messages sent to or from this e-mail address. 
Messages sent to or from this e-mail address may be stored on the
Infosys 
e-mail system.
***INFOSYS End of Disclaimer INFOSYS*** 


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


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

Re: So boring issues about character encoding in action ......

2005-10-18 Thread Deepesh Nandal


Hi,
   In the struts action you are setting character encoding on 'request' 
object req ,it however needs to be on 'response'  ie res.


Deepesh.


public class TestAction extends Action{
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest req,
HttpServletResponse res) throws Exception {

req.setCharacterEncoding(UTF-8);   // this should be 
res.setCharacterEncoding(UTF-8);


String description = req.getParameter(description);
description = (description == null?:description.trim());
try{
ItemDAO itemDao = ItemDAO.getInstance();
Item item = new Item();



- Original Message - 
From: Tony Lu [EMAIL PROTECTED]

To: user@struts.apache.org
Sent: Tuesday, October 18, 2005 11:14 AM
Subject: So boring issues about character encoding in action ..


I need to create an internationalized Web application by struts,mysql and
hibernate.
Each component Character Encoding is utf8.
It runs well when I run a pure servlet to save 'Chinese Character' to
database and load it from database.
But when I implement it with struts action, the application can not save
Chinese correctly.
I really don't know why struts action can not work well. I am sure there is
no difference between them.
Is there anywhere to set character encoding for action? Please help!
 --Pure Servlet ( It runs well)
-
public class UtfTest extends HttpServlet {
protected void doPost(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {

request.setCharacterEncoding(UTF-8);
String description = request.getParameter(description);
description = (description == null?:description.trim());

try{
ItemDAO itemDao = ItemDAO.getInstance();
Item item = new Item();
item.setDescription(description);
itemDao.save(item);
}catch(Exception e){
e.printStackTrace();
}
response.sendRedirect(test.jsp);
}
}

--Action for struts 

public class TestAction extends Action{
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest req,
HttpServletResponse res) throws Exception {

req.setCharacterEncoding(UTF-8);
String description = req.getParameter(description);
description = (description == null?:description.trim());
try{
ItemDAO itemDao = ItemDAO.getInstance();
Item item = new Item();

item.setDescription(description);
itemDao.save(item);
// Determine which action forward should be returned
return mapping.findForward(success);
}catch(Exception e){
}
}
}






No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.12.2/139 - Release Date: 10/17/2005


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

Re: So boring issues about character encoding in action ......

2005-10-18 Thread Tony Lu

I don't think so.
I have set 'controller contentType=text/html; charset=UTF-8 /' in
struts-config.xml
So the action don't need to specially add statement '
res.setCharacterEncoding(UTF-8)'.
I also have tested it like this. But it seems it's no use.

 On 10/18/05, Deepesh Nandal [EMAIL PROTECTED] wrote:

 Hi,
 In the struts action you are setting character encoding on 'request'
 object req ,it however needs to be on 'response' ie res.

 Deepesh.


 public class TestAction extends Action{
 public ActionForward execute(ActionMapping mapping,
 ActionForm form,
 HttpServletRequest req,
 HttpServletResponse res) throws Exception {

 req.setCharacterEncoding(UTF-8); // this should be
 res.setCharacterEncoding(UTF-8);

 String description = req.getParameter(description);
 description = (description == null?:description.trim());
 try{
 ItemDAO itemDao = ItemDAO.getInstance();
 Item item = new Item();



 - Original Message -
 From: Tony Lu [EMAIL PROTECTED]
 To: user@struts.apache.org
 Sent: Tuesday, October 18, 2005 11:14 AM
 Subject: So boring issues about character encoding in action ..


 I need to create an internationalized Web application by struts,mysql and
 hibernate.
 Each component Character Encoding is utf8.
 It runs well when I run a pure servlet to save 'Chinese Character' to
 database and load it from database.
 But when I implement it with struts action, the application can not save
 Chinese correctly.
 I really don't know why struts action can not work well. I am sure there
 is
 no difference between them.
 Is there anywhere to set character encoding for action? Please help!
 --Pure Servlet ( It runs well)
 -
 public class UtfTest extends HttpServlet {
 protected void doPost(HttpServletRequest request, HttpServletResponse
 response)
 throws ServletException, IOException {

 request.setCharacterEncoding(UTF-8);
 String description = request.getParameter(description);
 description = (description == null?:description.trim());

 try{
 ItemDAO itemDao = ItemDAO.getInstance();
 Item item = new Item();
 item.setDescription(description);
 itemDao.save(item);
 }catch(Exception e){
 e.printStackTrace();
 }
 response.sendRedirect(test.jsp);
 }
 }

 --Action for struts
 

 public class TestAction extends Action{
 public ActionForward execute(ActionMapping mapping,
 ActionForm form,
 HttpServletRequest req,
 HttpServletResponse res) throws Exception {

 req.setCharacterEncoding(UTF-8);
 String description = req.getParameter(description);
 description = (description == null?:description.trim());
 try{
 ItemDAO itemDao = ItemDAO.getInstance();
 Item item = new Item();

 item.setDescription(description);
 itemDao.save(item);
 // Determine which action forward should be returned
 return mapping.findForward(success);
 }catch(Exception e){
 }
 }
 }




 


 No virus found in this incoming message.
 Checked by AVG Anti-Virus.
 Version: 7.0.344 / Virus Database: 267.12.2/139 - Release Date: 10/17/2005


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

Re: So boring issues about character encoding in action ......

2005-10-18 Thread Joe Germuska


At 1:44 PM +0800 10/18/05, Tony Lu wrote:

I need to create an internationalized Web application by struts,mysql and
hibernate.
Each component Character Encoding is utf8.
 It runs well when I run a pure servlet to save 'Chinese Character' to
database and load it from database.
But when I implement it with struts action, the application can not save
Chinese correctly.
 I really don't know why struts action can not work well. I am sure there is
no difference between them.


By the time that your action class is executing, Struts has already 
read from the request input stream (to populate the ActionForm).


In any web application, if you want to set the request character 
encoding, you must arrange to do it before any code will read from 
the request input stream.  The best way to do this in a Servlet 2.3 
or later web environment is to use a ServletFilter.  In fact, most of 
the worked examples of writing ServletFilters on the web are to solve 
this problem.


You could also do it by extending RequestProcessor (or 
TilesRequestProcessor, if you use Tiles) and overriding the 
processPreprocess method.  However, in Struts 1.3 the 
processPreprocess method is no longer used.  Using a ServletFilter 
will apply to any application you write in any Struts version, or 
with a non-Struts approach.


Joe




 Is there anywhere to set character encoding for action? Please help!
  --Pure Servlet ( It runs well)
-
public class UtfTest extends HttpServlet {
protected void doPost(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {

request.setCharacterEncoding(UTF-8);
String description = request.getParameter(description);
description = (description == null?:description.trim());

try{
ItemDAO itemDao = ItemDAO.getInstance();
Item item = new Item();
item.setDescription(description);
itemDao.save(item);
}catch(Exception e){
e.printStackTrace();
}
response.sendRedirect(test.jsp);
}
}

--Action for struts 

public class TestAction extends Action{
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest req,
HttpServletResponse res) throws Exception {

req.setCharacterEncoding(UTF-8);
String description = req.getParameter(description);
description = (description == null?:description.trim());
try{
ItemDAO itemDao = ItemDAO.getInstance();
Item item = new Item();

item.setDescription(description);
itemDao.save(item);
// Determine which action forward should be returned
return mapping.findForward(success);
}catch(Exception e){
}
}
}



--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
Narrow minds are weapons made for mass destruction  -The Ex


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

So boring issues about character encoding in action ......

2005-10-17 Thread Tony Lu

I need to create an internationalized Web application by struts,mysql and
hibernate.
Each component Character Encoding is utf8.
 It runs well when I run a pure servlet to save 'Chinese Character' to
database and load it from database.
But when I implement it with struts action, the application can not save
Chinese correctly.
 I really don't know why struts action can not work well. I am sure there is
no difference between them.
 Is there anywhere to set character encoding for action? Please help!
  --Pure Servlet ( It runs well)
-
public class UtfTest extends HttpServlet {
protected void doPost(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {

request.setCharacterEncoding(UTF-8);
String description = request.getParameter(description);
description = (description == null?:description.trim());

try{
ItemDAO itemDao = ItemDAO.getInstance();
Item item = new Item();
item.setDescription(description);
itemDao.save(item);
}catch(Exception e){
e.printStackTrace();
}
response.sendRedirect(test.jsp);
}
}

--Action for struts 

public class TestAction extends Action{
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest req,
HttpServletResponse res) throws Exception {

req.setCharacterEncoding(UTF-8);
String description = req.getParameter(description);
description = (description == null?:description.trim());
try{
ItemDAO itemDao = ItemDAO.getInstance();
Item item = new Item();

item.setDescription(description);
itemDao.save(item);
// Determine which action forward should be returned
return mapping.findForward(success);
}catch(Exception e){
}
}
}

Re: Character encoding...

2005-09-11 Thread Joe Germuska


I had problem with character encoding in my web application. I was trying to
display Polish characters using UTF-8 but data from forms was not getting in
proper format to the business layer. I managed to solve this by setting
filter  which does request.setCharacterEncoding(encoding); But the question
is: WHY it didn't work when I was using request.setCharacterEncoding() in
Action's execute() method??


The request's character encoding can only be set before the input 
values are read.  By the time the Action executes, the ActionForm has 
already been populated, which means that the request has already 
deserialized the request parameters from bytes on the wire into Java 
Strings.  Thus, a ServletFilter is the best way to make sure that 
this value is set at the earliest possible time.


Hope this helps,
Joe

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
Narrow minds are weapons made for mass destruction  -The Ex


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

How to set character encoding of the incoming request in Struts 1.2.4

2005-05-19 Thread souravm

Hi All,
 
I want to set the chracter encoding of incoming http request by using 
HttpServletRequest.setCharacterEncoding() api. 
 
How do I do it using Struts 1.2.4 ? Does it provide any configuration parameter 
to do the same ? Or one has to subclass the RequestProcessor class to do the 
same ? Or is there any other way ?
 
Regards,
Sourav

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

Re: How to set character encoding of the incoming request in Struts 1.2.4

2005-05-19 Thread Jason Lea

I use a servlet filter to set the encoding before it reaches struts
souravm wrote:
Hi All,
I want to set the chracter encoding of incoming http request by using HttpServletRequest.setCharacterEncoding() api. 

How do I do it using Struts 1.2.4 ? Does it provide any configuration parameter 
to do the same ? Or one has to subclass the RequestProcessor class to do the 
same ? Or is there any other way ?
Regards,
Sourav
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

--
Jason Lea

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

Re: Character encoding problems after 1.1 to 1.2.4 upgrade

On 6 janv. 05, at 15:52, J.Patterson Waltz III wrote:

Now, I guess I'll just have to try using the character encoding filter 
Guillaume recommended.
Ack! I'm about to pull my hair out over these encoding issues. I added 
the SetCharacterEncodingFilter from the Tomcat 5 distribution to my web 
application, with just enough mods to get some logging output from it 
so I'd know it was doing its thing.

So now I have the following in place to ensure incoming and outgoing 
UTF-8 encoding:
- A %@ page pageEncoding=UTF-8 contentType=text/html;charset=UTF-8 
language=java % directive
- an acceptCharset=UTF-8 attribute on html:form tags
- an  enctype=application/x-www-form-urlencoded;charset=UTF-8 
attribute on html:form tags
- the SetCharacterEncodingFilter, configured to interpret UTF-8 no 
matter what

and yet I'm *still* getting non-decoded UTF-8 displayed in my pages 
(i.e. été is Ã©tÃ©).

Guillaume, did you actually get UTF-8 to work using the filter 
solution? If so, can you (or anyone) think of anything else I might 
have missed? Thanks in advance.

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

Re: Character encoding problems after 1.1 to 1.2.4 upgrade

2005-01-06 Thread Guillaume Cottenceau

J.Patterson Waltz III lists 'at' cerenit.com writes:

 On 6 janv. 05, at 15:52, J.Patterson Waltz III wrote:
 
 
  Now, I guess I'll just have to try using the character encoding
  filter Guillaume recommended.
 
 Ack! I'm about to pull my hair out over these encoding issues. I added
 the SetCharacterEncodingFilter from the Tomcat 5 distribution to my
 web application, with just enough mods to get some logging output from
 it so I'd know it was doing its thing.
 
 So now I have the following in place to ensure incoming and outgoing
 UTF-8 encoding:
 - A %@ page pageEncoding=UTF-8
 contentType=text/html;charset=UTF-8 language=java % directive
 - an acceptCharset=UTF-8 attribute on html:form tags
 - an  enctype=application/x-www-form-urlencoded;charset=UTF-8
 attribute on html:form tags
 - the SetCharacterEncodingFilter, configured to interpret UTF-8 no
 matter what
 
 and yet I'm *still* getting non-decoded UTF-8 displayed in my pages
 (i.e. été is Ã©tÃ©).
 
 Guillaume, did you actually get UTF-8 to work using the filter
 solution? If so, can you (or anyone) think of anything else I might
 have missed? Thanks in advance.

Yes, it works.

First, verify `tomcat-browser': please try to render your page
with wget -S to see precisely the headers (Content-Type must
specify UTF-8) and the contents (double-check the output is
UTF-8) (to verify your browser is not bugged).

Second, verify `browser-tomcat': use a proxy (or netcat in
listen mode) to precisely see what headers your browser is
sending (if you will use the filter to force UTF-8, that doesn't
matter much) and the encoding of the data. Typically, browsers
will encode in UTF-8 if the page containing the form was using
UTF-8 itself, but accept-charset can do no harm, but as you
noticed they don't set the charset in the Content-Type header
they use (according to mozilla's bugzilla, it's because it breaks
too many servers); but you have to double-check that (in my
experience, mozilla and MSIE do work).

-- 
Guillaume Cottenceau

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

Re: Character encoding problems after 1.1 to 1.2.4 upgrade

On 6 janv. 05, at 17:17, Guillaume Cottenceau wrote:
J.Patterson Waltz III lists 'at' cerenit.com writes:
On 6 janv. 05, at 15:52, J.Patterson Waltz III wrote:

Now, I guess I'll just have to try using the character encoding
filter Guillaume recommended.
Ack! I'm about to pull my hair out over these encoding issues. I added
the SetCharacterEncodingFilter from the Tomcat 5 distribution to my
web application, with just enough mods to get some logging output from
it so I'd know it was doing its thing.
So now I have the following in place to ensure incoming and outgoing
UTF-8 encoding:
- A %@ page pageEncoding=UTF-8
contentType=text/html;charset=UTF-8 language=java % directive
- an acceptCharset=UTF-8 attribute on html:form tags
- an  enctype=application/x-www-form-urlencoded;charset=UTF-8
attribute on html:form tags
- the SetCharacterEncodingFilter, configured to interpret UTF-8 no
matter what
and yet I'm *still* getting non-decoded UTF-8 displayed in my pages
(i.e. été is Ã©tÃ©).
Guillaume, did you actually get UTF-8 to work using the filter
solution? If so, can you (or anyone) think of anything else I might
have missed? Thanks in advance.
Yes, it works.
First, verify `tomcat-browser': please try to render your page
with wget -S to see precisely the headers (Content-Type must
specify UTF-8) and the contents (double-check the output is
UTF-8) (to verify your browser is not bugged).
Here's the tomcat-browser headers of the page which contains the form:
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Language: en
X-Transfer-Encoding: chunked
Date: Thu, 06 Jan 2005 16:30:08 GMT
Server: Apache-Coyote/1.1
Content-length: 16401
Second, verify `browser-tomcat': use a proxy (or netcat in
listen mode) to precisely see what headers your browser is
sending (if you will use the filter to force UTF-8, that doesn't
matter much) and the encoding of the data. Typically, browsers
will encode in UTF-8 if the page containing the form was using
UTF-8 itself, but accept-charset can do no harm, but as you
noticed they don't set the charset in the Content-Type header
they use (according to mozilla's bugzilla, it's because it breaks
too many servers); but you have to double-check that (in my
experience, mozilla and MSIE do work).
And here's the POST response from Firefox, including the form data  
(sensitive data manually replaced with x's):

POST http://127.0.0.1:8080/SAGE/correspondent.do HTTP/1.1
Host: 127.0.0.1:8008
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;  
rv:1.7.5) Gecko/20041107 Firefox/1.0
Accept:  
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/ 
plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: fr-fr,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://127.0.0.1:8008/SAGE/correspondent.do?retrieve=per=1
Cookie: lang=en; JSESSIONID=035AC799FB05BE35FE9B9E96D0664930
Content-Type: application/x-www-form-urlencoded
Content-Length: 841

personTO.type=correspondentpersonTO.subtype=correspondentTO.correspond 
entID=174personTO.personID=1personTO.salutation=mrpersonTO.lastName=W 
altzpersonTO.firstName=J.+PattersonpersonTO.status=activepersonTO.com 
ments=%C3%A9t%C3%A9personTO.address=personTO.city=personTO.postalCode 
=personTO.region=personTO.country=personTO.telephone1Label=personTO. 
telephone1=personTO.telephone2Label=personTO.telephone2=personTO.fax= 
personTO.email=x%40xxx.compersonTO.secondaryEmail=personT 
O.contactLanguage=enpersonTO.orgSummaryTO.organizationID=161personTO.e 
mployeeID=personTO.position=personTO.department=personTO.managerName= 
personTO.accountTO.login=x%40xxx.compersonTO.accountTO.pas 
sword=personTO.accountTO.loginEnabled=onpersonTO.accountTO.con 
nectionAttempts=0ID=174ID=1update=Save+Changes

Notice in the third line of the form data:  
personTO.comments=%C3%A9t%C3%A9
That's 'été' URLencoded as UTF-8.

So I'm still stumped. :-(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Character encoding problems after 1.1 to 1.2.4 upgrade

2005-01-06 Thread Guillaume Cottenceau

J.Patterson Waltz III lists 'at' cerenit.com writes:

 Notice in the third line of the form data:
 personTO.comments=%C3%A9t%C3%A9
 That's 'été' URLencoded as UTF-8.
 
 So I'm still stumped. :-(

But that's exactly what you want. The SetCharacterEncodingFilter
will set the character encoding of the HttpServletRequest before
data is retrieved from it, and when it's retrieved it should be
correctly decoded. Are you sure the filter is up and running?

-- 
Guillaume Cottenceau

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

Re: Character encoding problems after 1.1 to 1.2.4 upgrade

On 6 janv. 05, at 17:44, Guillaume Cottenceau wrote:
J.Patterson Waltz III lists 'at' cerenit.com writes:
Notice in the third line of the form data:
personTO.comments=%C3%A9t%C3%A9
That's 'été' URLencoded as UTF-8.
So I'm still stumped. :-(
But that's exactly what you want. The SetCharacterEncodingFilter
will set the character encoding of the HttpServletRequest before
data is retrieved from it, and when it's retrieved it should be
correctly decoded. Are you sure the filter is up and running?
I agree that that encoding is what I want. It's just that it's not 
getting decoded upon display. Or rather, it's getting URL-decoded, but 
not UTF-8 decoded.

I'm sure the filter is up and running because I added logging 
statements to the Apache example code. So in my log, I see:

2005-01-06 17:30:34,706 DEBUG 
[com.cerenit.sage.util.web.SetCharacterEncodingFilter] ignore = true, 
encoding = utf-8, request encoding is null
2005-01-06 17:30:34,706 DEBUG 
[com.cerenit.sage.util.web.SetCharacterEncodingFilter] setting encoding 
to utf-8

I have the filter set to match the url-patterns *.do and *.jsp.
I'm wondering if the fact that the form fields are all defined in 
subtiles could make any difference: I'd guess not, since it's the 
outermost tile which defines the page encoding.

I also have another filter, the ResponseOverrideFilter used by 
displaytag, which appears before the SetCharacterEncodingFilter in my 
web.xml. I wonder if it could be interfering with the 
SetCharacterEncodingFilter?

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

Re: Character encoding problems after 1.1 to 1.2.4 upgrade

2005-01-06 Thread Guillaume Cottenceau

J.Patterson Waltz III lists 'at' cerenit.com writes:

 On 6 janv. 05, at 17:44, Guillaume Cottenceau wrote:
 
  J.Patterson Waltz III lists 'at' cerenit.com writes:
 
  Notice in the third line of the form data:
  personTO.comments=%C3%A9t%C3%A9
  That's 'été' URLencoded as UTF-8.
 
  So I'm still stumped. :-(
 
  But that's exactly what you want. The SetCharacterEncodingFilter
  will set the character encoding of the HttpServletRequest before
  data is retrieved from it, and when it's retrieved it should be
  correctly decoded. Are you sure the filter is up and running?
 
 
 I agree that that encoding is what I want. It's just that it's not
 getting decoded upon display. Or rather, it's getting URL-decoded, but
 not UTF-8 decoded.

Display is different from decoding. Double check the decoding
first with log4j or anything. But beware that the JVM default
charset and console charset may interfer so you might make use of
my char decoder:

byte[] b = querystring.getBytes( UTF-8 );
String bytes = ;
for ( int i = 0; i  b.length; i++ ) {
int val = b[i];
if ( val  0 ) {
val += 256;
}
bytes += Integer.toHexString( val ) +  ;
}

 I'm sure the filter is up and running because I added logging
 statements to the Apache example code. So in my log, I see:
 
 2005-01-06 17:30:34,706 DEBUG
 [com.cerenit.sage.util.web.SetCharacterEncodingFilter] ignore = true,
 encoding = utf-8, request encoding is null
 2005-01-06 17:30:34,706 DEBUG
 [com.cerenit.sage.util.web.SetCharacterEncodingFilter] setting
 encoding to utf-8

Yep.
 
 I have the filter set to match the url-patterns *.do and *.jsp.
 
 I'm wondering if the fact that the form fields are all defined in
 subtiles could make any difference: I'd guess not, since it's the
 outermost tile which defines the page encoding.

Your previous email seems to show that browser-tomcat is ok
since you're really receiving URL encoded UTF8 strings, which is
what you want. There is something with url decoding and/or
decoding of byte content.

 I also have another filter, the ResponseOverrideFilter used by
 displaytag, which appears before the SetCharacterEncodingFilter in my
 web.xml. I wonder if it could be interfering with the
 SetCharacterEncodingFilter?

Yes, if it reads the request parameters or request stream (by
servlets specs). The SetCharacterEncodingFilter should be put
first. I think this might be your problem.

-- 
Guillaume Cottenceau

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

Re: Character encoding problems after 1.1 to 1.2.4 upgrade