I'm assuming that UIPortlet do the same and use the query string
parser when it constructs the parameter passed to the portlet invoker.
Is that what you mean ?
On Mar 18, 2010, at 3:19 PM, Matthew Wringe wrote:
On Thu, 2010-03-18 at 15:04 +0100, Julien Viet wrote:
> are we talking here about Portlet parameters or something else ?
We are talking about request parameters. But if we are getting the
wrong
values from the request parameters, and passing on those values to the
pc, then we get back wrongly encoded portlet parameters.
> On Mar 18, 2010, at 2:20 PM, Matthew Wringe wrote:
>
>> On Wed, 2010-03-17 at 23:39 +0100, Julien Viet wrote:
>>> portlet request context are I believe different as they are never
>>> encoded to anything except they are passed in clear as a kind of
>>> Map<String,String[]>, so where would be the encoding problem ?
>>
>> there isn't (unless you are passing the wrongly encoded strings).
>> I have a patch ready, I just need to wait until its safe to start
>> committing again.
>>
>>> On Mar 17, 2010, at 11:08 PM, Matthew Wringe wrote:
>>>
>>>> On Wed, 2010-03-17 at 21:38 +0100, Julien Viet wrote:
>>>>> On Mar 17, 2010, at 8:54 PM, Julien Viet wrote:
>>>>>
>>>>>>
>>>>>> On Mar 17, 2010, at 8:48 PM, Matthew Wringe wrote:
>>>>>>
>>>>>>> On Wed, 2010-03-17 at 20:20 +0100, Julien Viet wrote:
>>>>>>>> Hi Matt
>>>>>>>>
>>>>>>>> in WCI there is code to decode query parameters using
UTF-8
>>>>>>>> charset:
>>>>>>>>
>>>>>>>>
http://anonsvn.jboss.org/repos/gatein/components/wci/trunk/wci/src/main/j...
>>>>>>>>
>>>>>>>> that delegates most of the job to :
>>>>>>>> org.gatein.common.http.QueryStringParser
>>>>>>>
>>>>>>> hmm, ok, so it handles the querystring parameters directly
from
>>>>>>> the
>>>>>>> url
>>>>>>> and not from the request properties. Which means we need to
>>>>>>> bypass
>>>>>>> the
>>>>>>> request parameters itself to add this feature. We can do this
>>>>>>> in
>>>>>>> the
>>>>>>> PortalRequestContext [or maybe we should wait to add this
>>>>>>> feature
>>>>>>> until
>>>>>>> a later date? with wci]
>>>>>>
>>>>>> I think you can handle the request query string at any time,
>>>>>> what
>>>>>> needs to be changed is how the portal consumer the query string
>>>>>> as a
>>>>>> parameter map.
>>>>>>
>>>>>
>>>>> i.e, the request parameter in webui should parse the query string
>>>>> in
>>>>> UTF8 and make them probably available via the class
>>>>> RequestContext:
>>>>>
>>>>> abstract public String getRequestParameter(String name);
>>>>>
>>>>> abstract public String[] getRequestParameterValues(String name);
>>>>>
>>>>> and any call to obtain a request parameter should use this.
>>>>
>>>> that will work for the PortalRequestContext, but not the
>>>> PortletRequestContext (since that uses the portlet responses
>>>> instead
>>>> of
>>>> the http ones).
>>>>
>>>> I have a patch for it that will make the PortalRequestContext work
>>>> this
>>>> way, and then makes the UIPortlet use the parameter map from the
>>>> PortalRequestContext which is used by the pc to set the
>>>> PortletRequestContext.
>>>>
>>>>
>>>>>>>
>>>>>>>> (somehow the code of WCI: WebRequest and WebResponse
should be
>>>>>>>> used in
>>>>>>>> GateIn in a later feature release, as it provides value
add
>>>>>>>> services
>>>>>>>> on top of HTTP request/response)
>>>>>>>
>>>>>>> yeah, it probably should, that code isn't being used
right now
>>>>>>>
>>>>>>
>>>>>> Thomas and myself will probably discuss about that in a near
>>>>>> future.
>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>>
>>>>>>>> On Mar 17, 2010, at 7:36 PM, Matthew Wringe wrote:
>>>>>>>>
>>>>>>>>> On Wed, 2010-03-17 at 18:59 +0100, Julien Viet
wrote:
>>>>>>>>>> actually it is servlet container specific so we
want to
>>>>>>>>>> avoid
>>>>>>>>>> it.
>>>>>>>>>
>>>>>>>>> ok, so that means we want to handle it in the portal
code
>>>>>>>>> completely
>>>>>>>>> then?
>>>>>>>>>
>>>>>>>>>> where does the encoding issue occur ?
>>>>>>>>>
>>>>>>>>> It occurs when the url is encoded to one value, but
we are
>>>>>>>>> expecting
>>>>>>>>> another. So when the servlet container handles
decoding
>>>>>>>>> something
>>>>>>>>> from
>>>>>>>>> the url (pathInfo, properties from query strings,
etc...) it
>>>>>>>>> will
>>>>>>>>> decode
>>>>>>>>> it using whatever encoding it has been configured to
use
>>>>>>>>> (iso-8859-1
>>>>>>>>> by
>>>>>>>>> default, or another value configured in the
server.xml).
>>>>>>>>>
>>>>>>>>> So we have the situation where something we set
something
>>>>>>>>> like
>>>>>>>>> 'thúy' in
>>>>>>>>> the url, the servlet container will take those bytes
and
>>>>>>>>> convert
>>>>>>>>> them
>>>>>>>>> into the iso-8859-1 standard (where the ú gets
converted into
>>>>>>>>> two
>>>>>>>>> bytes), and then the string value we get back is
'thúy' (it
>>>>>>>>> converts
>>>>>>>>> the two bytes back into utf-8 characters).
>>>>>>>>>
>>>>>>>>> If we set the url encoding to be UTF-8 in the
server.xml,
>>>>>>>>> then we
>>>>>>>>> don't
>>>>>>>>> get these encoding issues since everything is handled
in the
>>>>>>>>> same
>>>>>>>>> encoding.
>>>>>>>>>
>>>>>>>>> For the portal naming issue, I found a way to get
around that
>>>>>>>>> by
>>>>>>>>> using
>>>>>>>>> values not decoded by the servlet container. For the
>>>>>>>>> dashboard
>>>>>>>>> naming
>>>>>>>>> issue, it might be a bit more complex to handle.
>>>>>>>>>
>>>>>>>>> I really wish the javax.servlet classes/spec was
written
>>>>>>>>> better
>>>>>>>>> to
>>>>>>>>> handle encoding issue more nicely. Some methods allow
you to
>>>>>>>>> get
>>>>>>>>> the
>>>>>>>>> non-decoded values, other don't. Character
encoding only
>>>>>>>>> works on
>>>>>>>>> non-querystring properties, etc...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Mar 17, 2010, at 4:46 PM, Matthew Wringe
wrote:
>>>>>>>>>>
>>>>>>>>>>> There have been a few issues which have been
brought up in
>>>>>>>>>>> regards
>>>>>>>>>>> to
>>>>>>>>>>> portal and tab names not working properly if
they contain
>>>>>>>>>>> non
>>>>>>>>>>> ascii
>>>>>>>>>>> characters.
>>>>>>>>>>>
>>>>>>>>>>>
https://jira.jboss.org/jira/browse/GTNPORTAL-337
>>>>>>>>>>>
https://jira.jboss.org/jira/browse/GTNPORTAL-596
>>>>>>>>>>>
>>>>>>>>>>> These are due to the portal using utf-8,
while tomcat/jboss
>>>>>>>>>>> is
>>>>>>>>>>> configured to use iso-8859-1 encoding for the
url.
>>>>>>>>>>>
>>>>>>>>>>> In both cases if the URIEncoding is set to
UTF-8 in the
>>>>>>>>>>> server.xml
>>>>>>>>>>> (or
>>>>>>>>>>> if useBodyEncodingForURI is set to true) then
it works.
>>>>>>>>>>>
>>>>>>>>>>> For the portal naming issue it was possible
to get around
>>>>>>>>>>> it in
>>>>>>>>>>> the
>>>>>>>>>>> code, for the tab issue its going to be a bit
more complex.
>>>>>>>>>>>
>>>>>>>>>>> Can we just change the URIEncoding in the
server.xml for
>>>>>>>>>>> the
>>>>>>>>>>> bundles
>>>>>>>>>>> we
>>>>>>>>>>> create? or would it be better to find
workarounds for this
>>>>>>>>>>> issue in
>>>>>>>>>>> the
>>>>>>>>>>> portal code itself?
>>>>>>>>>>>
>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>> gatein-dev mailing list
>>>>>>>>>>> gatein-dev(a)lists.jboss.org
>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>