You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Thorsten Berger (JIRA)" <je...@portals.apache.org> on 2005/10/09 20:18:47 UTC
[jira] Created: (JS2-376) request parameter encoding problem
request parameter encoding problem
----------------------------------
Key: JS2-376
URL: http://issues.apache.org/jira/browse/JS2-376
Project: Jetspeed 2
Type: Bug
Components: Components Core
Versions: 2.0-M4
Reporter: Thorsten Berger
I logged an issue for the struts bridge, but found out that this problem is specific to jetspeed.
Please see PB-14 (unable to post unicode characters in struts bridge) for an introduction.
The problem is the character decoding done in in o.a.j.engine.servlet.ServletRequestImpl (line 157):
try
{
paramValues[i] = new String(paramValues[i].getBytes("ISO-8859-1"), getCharacterEncoding());
}
catch (UnsupportedEncodingException e)
The struts bridge now does some further wrapping of the ServletRequest resulting in calling the code above twice (and decoding decoded parameter strings again). It's clear that this results in garbage characters.
The first call is done by jetspeed itself (providing parameters to the StrutsPortlet) and the second by the Struts RequestProcessor (to populate the form bean). However, I think this behaviour should be changed in Jetspeed.
I'd like to suggest two solutions:
1: setting a request attribute indicating that request parameters have already been decoded, which prevents the second decoding
2: Delegating the decoding to the servlet api. (my preferred solution)
I think hard-coding the encoding is unclean. The portal cannot count on "ISO-8859-1" parameter strings (which is especially true in the above case).
The delegation could be achieved by:
- removing the decoding from o.a.j.engine.servlet.ServletRequestImpl
- changing JetspeedRequestContext.setCharacterEncoding() to set the encoding also to the wrapped HttpServletRequest
- as you know this has to be done before the first getParameter() call is invoked, the following two calls must be removed to make this work:
line 60 in CapabilityValveImpl (the variable "requestMediaType" is never used) and line 192 in JetspeedEngine (noticed that "targetPipeline" is never set as request parameter rather than as request attribute)
-> results in the CapabilityValveImpl setting the characterEncoding before any getParameter() call
As I urgently need this to work for my portal I applied solution 2. I would provide a patch for this solution if you're in agreement.
Regards, Thorsten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: maven plugin cache
Posted by Zhong ZHENG <he...@gmail.com>.
Hi,
I don't know much about jetspeed, but on your second thought, i agree
partially.
When using ant, i feel that i can completely control it. But when using
maven, i have to cross my fingers and pray, because sometimes i may
encounter problems that i have no idea how to get through.
On the other hand, maven is (most of the time) powerful and convenient. It
is not necessary to abandon maven. Why not provide both project.xml and
build.xml to give users an alternative to perform the build?
Regards.
On 10/17/05, David Sean Taylor <da...@bluesunrise.com> wrote:
>
> David Sean Taylor wrote:
> > Im finding that I need to manually delete the plugin cache whenever I
> > change resources, such as SQL population scripts.
> >
> > Has anyone else experienced this too?
> >
> > Does anyone know a way to automate the deleting of the plugin cache
> > during the build?
> >
> Well, on second thought, anyone want to consider ditching Maven and
> going back to Ant?
>
> My 2 cents: Maven is more trouble than its worth, especially when
> training new users
>
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> [office] +01 707 773-4646
> [mobile] +01 707 529 9194
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
--
ZHENG Zhong
1 Avenue Alphand
75116 Paris, France
+33 6 76 80 45 90
Re: maven plugin cache
Posted by David Sean Taylor <da...@bluesunrise.com>.
David Sean Taylor wrote:
> Im finding that I need to manually delete the plugin cache whenever I
> change resources, such as SQL population scripts.
>
> Has anyone else experienced this too?
>
> Does anyone know a way to automate the deleting of the plugin cache
> during the build?
>
Well, on second thought, anyone want to consider ditching Maven and
going back to Ant?
My 2 cents: Maven is more trouble than its worth, especially when
training new users
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: maven plugin cache
Posted by David Sean Taylor <da...@bluesunrise.com>.
Choong Yong Koh wrote:
>>To complicate matters, I have M3 and M4 projects of Jetspeed on this
>>machine. So if I need to switch between M3 and M4 or visa versa, I have
>>scripts to clear the Maven cache and then rebuild and install
>>(plugin:install) the plugin.
>>
>>
>>Hi,
>
>
> Just a suggestion, you might want to have separate local maven repository
> for the different projects. Add the following property in your
> project.properties file:
>
> #Changing the local in which maven uses to write user specific details
> #such as expanded plugins and cache data
> maven.home.local=c:\\project1\\.maven
>
>
> Choong Yong, Koh
>
Yes, thats what Ate recommended too.
Good advice, thanks.
Think problems maybe rooted in a maven eclipse plugin holding on to
cache files. Ive uninstalled it, lets see how things go now...
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: maven plugin cache
Posted by Choong Yong Koh <ch...@gmail.com>.
>
> To complicate matters, I have M3 and M4 projects of Jetspeed on this
> machine. So if I need to switch between M3 and M4 or visa versa, I have
> scripts to clear the Maven cache and then rebuild and install
> (plugin:install) the plugin.
>
>
> Hi,
Just a suggestion, you might want to have separate local maven repository
for the different projects. Add the following property in your
project.properties file:
#Changing the local in which maven uses to write user specific details
#such as expanded plugins and cache data
maven.home.local=c:\\project1\\.maven
Choong Yong, Koh
Re: maven plugin cache
Posted by David Sean Taylor <da...@bluesunrise.com>.
David Jencks wrote:
>
> On Oct 17, 2005, at 10:48 AM, David Sean Taylor wrote:
>> Does anyone know a way to automate the deleting of the plugin cache
>> during the build?
>
> I'm wondering why you run into this problem... Do you build a plugin
> and try to use it during the same maven multiproject build? What
> relationship do the resources have to the plugin? Parameterized sources
> for the use of the plugin? Scripts that are used to build the plugin?
> Scripts that are run when the plugin is used?
>
All of these questions, I didn't expect the Maven Inquisition :)
We store resources in the plugin such as SQL scripts, and basically
everything under the src/webapp directory. Its part of our recent "Eat
our own Dogfood Initiative". Quite tasty really, until you choke on a
cached bone.
To complicate matters, I have M3 and M4 projects of Jetspeed on this
machine. So if I need to switch between M3 and M4 or visa versa, I have
scripts to clear the Maven cache and then rebuild and install
(plugin:install) the plugin.
Sometimes the cached files break, and I have zero length cache files.
I'm pretty used to that. Sometimes the Maven Plugin for Eclipse holds on
to resources, thats usually a tough one.
I know how to handle most of these maven cache issues, although
sometimes it can stump me for a bit. Yesterday I had several of my
client/developers all having Maven build/plugin related issues *all at
once*, and I was ready to throw Maven out the door. Hell, we are using a
deadend version (1.x), whereas version 2 doesn't fully support our
current Jelly scripts. Solution from Maven team: rewrite your plugin in
Java. Im sorry, please don't take any offence, but its just not good enough.
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: maven plugin cache
Posted by David Jencks <da...@yahoo.com>.
On Oct 17, 2005, at 10:48 AM, David Sean Taylor wrote:
> Im finding that I need to manually delete the plugin cache whenever I
> change resources, such as SQL population scripts.
>
> Has anyone else experienced this too?
>
> Does anyone know a way to automate the deleting of the plugin cache
> during the build?
I'm wondering why you run into this problem... Do you build a plugin
and try to use it during the same maven multiproject build? What
relationship do the resources have to the plugin? Parameterized
sources for the use of the plugin? Scripts that are used to build the
plugin? Scripts that are run when the plugin is used?
thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
maven plugin cache
Posted by David Sean Taylor <da...@bluesunrise.com>.
Im finding that I need to manually delete the plugin cache whenever I
change resources, such as SQL population scripts.
Has anyone else experienced this too?
Does anyone know a way to automate the deleting of the plugin cache
during the build?
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Resolved: (JS2-376) request parameter encoding problem
Posted by "Shinsuke SUGAYA (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-376?page=all ]
Shinsuke SUGAYA resolved JS2-376:
---------------------------------
Fix Version: 2.0-dev/cvs
Resolution: Fixed
submitted patch by Thorsten Berger.
> request parameter encoding problem
> ----------------------------------
>
> Key: JS2-376
> URL: http://issues.apache.org/jira/browse/JS2-376
> Project: Jetspeed 2
> Type: Bug
> Components: Components Core
> Versions: 2.0-M4
> Reporter: Thorsten Berger
> Assignee: Shinsuke SUGAYA
> Fix For: 2.0-dev/cvs
> Attachments: j2_character_encoding_jira376.txt
>
> I logged an issue for the struts bridge, but found out that this problem is specific to jetspeed.
> Please see PB-14 (unable to post unicode characters in struts bridge) for an introduction.
> The problem is the character decoding done in in o.a.j.engine.servlet.ServletRequestImpl (line 157):
> try
> {
> paramValues[i] = new String(paramValues[i].getBytes("ISO-8859-1"), getCharacterEncoding());
> }
> catch (UnsupportedEncodingException e)
>
> The struts bridge now does some further wrapping of the ServletRequest resulting in calling the code above twice (and decoding decoded parameter strings again). It's clear that this results in garbage characters.
> The first call is done by jetspeed itself (providing parameters to the StrutsPortlet) and the second by the Struts RequestProcessor (to populate the form bean). However, I think this behaviour should be changed in Jetspeed.
> I'd like to suggest two solutions:
> 1: setting a request attribute indicating that request parameters have already been decoded, which prevents the second decoding
> 2: Delegating the decoding to the servlet api. (my preferred solution)
> I think hard-coding the encoding is unclean. The portal cannot count on "ISO-8859-1" parameter strings (which is especially true in the above case).
> The delegation could be achieved by:
> - removing the decoding from o.a.j.engine.servlet.ServletRequestImpl
> - changing JetspeedRequestContext.setCharacterEncoding() to set the encoding also to the wrapped HttpServletRequest
> - as you know this has to be done before the first getParameter() call is invoked, the following two calls must be removed to make this work:
> line 60 in CapabilityValveImpl (the variable "requestMediaType" is never used) and line 192 in JetspeedEngine (noticed that "targetPipeline" is never set as request parameter rather than as request attribute)
> -> results in the CapabilityValveImpl setting the characterEncoding before any getParameter() call
> As I urgently need this to work for my portal I applied solution 2. I would provide a patch for this solution if you're in agreement.
> Regards, Thorsten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Updated: (JS2-376) request parameter encoding problem
Posted by "Thorsten Berger (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-376?page=all ]
Thorsten Berger updated JS2-376:
--------------------------------
Attachment: j2_character_encoding_jira376.txt
Patch attached for solution 2.
I could also provide a patch for solution 1, which would be much easier to implement.
But, as I'm still trying to get the big picture, maybe someone has a better suggestion of how to resolve this issue.
Regards, Thorsten
> request parameter encoding problem
> ----------------------------------
>
> Key: JS2-376
> URL: http://issues.apache.org/jira/browse/JS2-376
> Project: Jetspeed 2
> Type: Bug
> Components: Components Core
> Versions: 2.0-M4
> Reporter: Thorsten Berger
> Attachments: j2_character_encoding_jira376.txt
>
> I logged an issue for the struts bridge, but found out that this problem is specific to jetspeed.
> Please see PB-14 (unable to post unicode characters in struts bridge) for an introduction.
> The problem is the character decoding done in in o.a.j.engine.servlet.ServletRequestImpl (line 157):
> try
> {
> paramValues[i] = new String(paramValues[i].getBytes("ISO-8859-1"), getCharacterEncoding());
> }
> catch (UnsupportedEncodingException e)
>
> The struts bridge now does some further wrapping of the ServletRequest resulting in calling the code above twice (and decoding decoded parameter strings again). It's clear that this results in garbage characters.
> The first call is done by jetspeed itself (providing parameters to the StrutsPortlet) and the second by the Struts RequestProcessor (to populate the form bean). However, I think this behaviour should be changed in Jetspeed.
> I'd like to suggest two solutions:
> 1: setting a request attribute indicating that request parameters have already been decoded, which prevents the second decoding
> 2: Delegating the decoding to the servlet api. (my preferred solution)
> I think hard-coding the encoding is unclean. The portal cannot count on "ISO-8859-1" parameter strings (which is especially true in the above case).
> The delegation could be achieved by:
> - removing the decoding from o.a.j.engine.servlet.ServletRequestImpl
> - changing JetspeedRequestContext.setCharacterEncoding() to set the encoding also to the wrapped HttpServletRequest
> - as you know this has to be done before the first getParameter() call is invoked, the following two calls must be removed to make this work:
> line 60 in CapabilityValveImpl (the variable "requestMediaType" is never used) and line 192 in JetspeedEngine (noticed that "targetPipeline" is never set as request parameter rather than as request attribute)
> -> results in the CapabilityValveImpl setting the characterEncoding before any getParameter() call
> As I urgently need this to work for my portal I applied solution 2. I would provide a patch for this solution if you're in agreement.
> Regards, Thorsten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-376) request parameter encoding problem
Posted by "Shinsuke SUGAYA (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-376?page=comments#action_12331705 ]
Shinsuke SUGAYA commented on JS2-376:
-------------------------------------
I'll check the patch and this issue..
> request parameter encoding problem
> ----------------------------------
>
> Key: JS2-376
> URL: http://issues.apache.org/jira/browse/JS2-376
> Project: Jetspeed 2
> Type: Bug
> Components: Components Core
> Versions: 2.0-M4
> Reporter: Thorsten Berger
> Attachments: j2_character_encoding_jira376.txt
>
> I logged an issue for the struts bridge, but found out that this problem is specific to jetspeed.
> Please see PB-14 (unable to post unicode characters in struts bridge) for an introduction.
> The problem is the character decoding done in in o.a.j.engine.servlet.ServletRequestImpl (line 157):
> try
> {
> paramValues[i] = new String(paramValues[i].getBytes("ISO-8859-1"), getCharacterEncoding());
> }
> catch (UnsupportedEncodingException e)
>
> The struts bridge now does some further wrapping of the ServletRequest resulting in calling the code above twice (and decoding decoded parameter strings again). It's clear that this results in garbage characters.
> The first call is done by jetspeed itself (providing parameters to the StrutsPortlet) and the second by the Struts RequestProcessor (to populate the form bean). However, I think this behaviour should be changed in Jetspeed.
> I'd like to suggest two solutions:
> 1: setting a request attribute indicating that request parameters have already been decoded, which prevents the second decoding
> 2: Delegating the decoding to the servlet api. (my preferred solution)
> I think hard-coding the encoding is unclean. The portal cannot count on "ISO-8859-1" parameter strings (which is especially true in the above case).
> The delegation could be achieved by:
> - removing the decoding from o.a.j.engine.servlet.ServletRequestImpl
> - changing JetspeedRequestContext.setCharacterEncoding() to set the encoding also to the wrapped HttpServletRequest
> - as you know this has to be done before the first getParameter() call is invoked, the following two calls must be removed to make this work:
> line 60 in CapabilityValveImpl (the variable "requestMediaType" is never used) and line 192 in JetspeedEngine (noticed that "targetPipeline" is never set as request parameter rather than as request attribute)
> -> results in the CapabilityValveImpl setting the characterEncoding before any getParameter() call
> As I urgently need this to work for my portal I applied solution 2. I would provide a patch for this solution if you're in agreement.
> Regards, Thorsten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [jira] Commented: (JS2-376) request parameter encoding problem
Posted by Shinsuke SUGAYA <sh...@yahoo.co.jp>.
Hi Thorsten,
Thanks. I'll check my fix on it.
shinsuke
Thorsten Berger wrote:
>
>> Could you provide the sample struts bridge code and your
>> environment info to me? Since I do not encounter problems
>> on portlets though I did not try it on the struts bridge,
>> I would like to check the details.
>>
>>
> Hi Shinsuke,
>
> you can use the Struts MailReader Demo to reproduce the problem. Just
> produce some validation errors in e.g. the registration form and you'll
> see that unicode characters are not handled correctly.
>
> Regards, Thorsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
--------------------------------------
Know more about Breast Cancer
http://pr.mail.yahoo.co.jp/pinkribbon/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [jira] Commented: (JS2-376) request parameter encoding problem
Posted by Thorsten Berger <be...@imn.htwk-leipzig.de>.
> Could you provide the sample struts bridge code and your
> environment info to me? Since I do not encounter problems
> on portlets though I did not try it on the struts bridge,
> I would like to check the details.
>
>
Hi Shinsuke,
you can use the Struts MailReader Demo to reproduce the problem. Just
produce some validation errors in e.g. the registration form and you'll
see that unicode characters are not handled correctly.
Regards, Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [jira] Commented: (JS2-376) request parameter encoding problem
Posted by Shinsuke SUGAYA <sh...@yahoo.co.jp>.
Thorsten Berger wrote:
>
>> It would break Fusion as it exists today.
>> A complete patch would include fixes to Fusion as well
>>
>> Why is that the portal cannot rely on request parameters?
>> Seems like a very restrictive requirement
>>
> Maybe we're talking at crossed purposes.
>
> The character decoding currently implemented does not work correctly
> when using (at least) the struts bridge (due to some wrapping of the
> ServletRequest).
Could you provide the sample struts bridge code and your
environment info to me? Since I do not encounter problems
on portlets though I did not try it on the struts bridge,
I would like to check the details.
Thanks,
shinsuke
> One possible solution would be to let the servlet
> container do the decoding by setting
> ServletRequest#setCharacterEncoding() before any
> ServletRequest#getParameter() call. Since the
> ServletRequest#setCharacterEncoding() is called within the
> CapabilitiesValve, I searched for and found two earlier invocations of
> getParameter(), which must be removed to make this work.
>
> This change delegates the character decoding, which is currently done in
> ServletRequestImpl (and relies on ISO-8859-1 characters), to the servlet
> container.
>
> The invocation we're talking about is imho dispensable, as setting
> pipelines is done with request attributes (not parameters). Furthermore,
> the servlet api does not define a method to set request parameters
> programmatically if not transmitted by the browser request. So, is it
> really necessary to set the pipeline by a browser request parameter?
> e.g.:
> http://localhost:8080/jetspeed/?pipeline=test
> which of course throws an exception.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
--------------------------------------
Know more about Breast Cancer
http://pr.mail.yahoo.co.jp/pinkribbon/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [jira] Commented: (JS2-376) request parameter encoding problem
Posted by Thorsten Berger <be...@imn.htwk-leipzig.de>.
> It throws an exception because there is no pipeline named "test".
> I objected to taking out this line:
>
> String targetPipeline = context
> .getRequestParameter(PortalReservedParameters.PIPELINE);
>
> since it would break any URLs coming from the browser with the
> pipeline parameter on it. This is currently how Fusion works: the
> pipeline is passed on the URL, not as a request attribute.
> Additionally, any existing HTML/Javascript that depends on the
> pipeline request parameter will be broken. Again, your soluton seems
> disproportionate in tradeoffs: are you saying that, with your patch,
> the portal can no longer make use of request parameters? I must be
> missing something here
>
Ah OK, I see. I didn't know that this is required. So I agree, this
would really break Fusion and some HTML/Javascript.
Hence we have two possibilities:
- Find a way to invoke setCharacterEncoding() before
getRequestParameter(PortalReservedParameters.PIPELINE).
- I send you a patch for the other solution I suggested in the JIRA issue.
The first one should be difficult to implement as the CapabilitiesValve
should do this. Do you have an idea?
Regards, Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [jira] Commented: (JS2-376) request parameter encoding problem
Posted by Thorsten Berger <be...@imn.htwk-leipzig.de>.
> URL, not as a request attribute. Additionally, any existing
> HTML/Javascript that depends on the pipeline request parameter will be
> broken. Again, your soluton seems disproportionate in tradeoffs: are
> you saying that, with your patch, the portal can no longer make use of
> request parameters?
No, of course should the portal make use of request parameters. My patch
would only have removed the possibility to set the pipeline by a request
parameter. Just to clarify ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [jira] Commented: (JS2-376) request parameter encoding problem
Posted by David Sean Taylor <da...@bluesunrise.com>.
Thorsten Berger wrote:
>
>> It would break Fusion as it exists today.
>> A complete patch would include fixes to Fusion as well
>>
>> Why is that the portal cannot rely on request parameters?
>> Seems like a very restrictive requirement
>>
> Maybe we're talking at crossed purposes.
>
> The character decoding currently implemented does not work correctly
> when using (at least) the struts bridge (due to some wrapping of the
> ServletRequest). One possible solution would be to let the servlet
> container do the decoding by setting
> ServletRequest#setCharacterEncoding() before any
> ServletRequest#getParameter() call. Since the
> ServletRequest#setCharacterEncoding() is called within the
> CapabilitiesValve, I searched for and found two earlier invocations of
> getParameter(), which must be removed to make this work.
>
> This change delegates the character decoding, which is currently done in
> ServletRequestImpl (and relies on ISO-8859-1 characters), to the servlet
> container.
>
> The invocation we're talking about is imho dispensable, as setting
> pipelines is done with request attributes (not parameters). Furthermore,
> the servlet api does not define a method to set request parameters
> programmatically if not transmitted by the browser request. So, is it
> really necessary to set the pipeline by a browser request parameter?
> e.g.:
> http://localhost:8080/jetspeed/?pipeline=test
> which of course throws an exception.
>
It throws an exception because there is no pipeline named "test".
I objected to taking out this line:
String targetPipeline = context
.getRequestParameter(PortalReservedParameters.PIPELINE);
since it would break any URLs coming from the browser with the pipeline
parameter on it. This is currently how Fusion works: the pipeline is
passed on the URL, not as a request attribute. Additionally, any
existing HTML/Javascript that depends on the pipeline request parameter
will be broken. Again, your soluton seems disproportionate in
tradeoffs: are you saying that, with your patch, the portal can no
longer make use of request parameters? I must be missing something here
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [jira] Commented: (JS2-376) request parameter encoding problem
Posted by Thorsten Berger <be...@imn.htwk-leipzig.de>.
> It would break Fusion as it exists today.
> A complete patch would include fixes to Fusion as well
>
> Why is that the portal cannot rely on request parameters?
> Seems like a very restrictive requirement
>
Maybe we're talking at crossed purposes.
The character decoding currently implemented does not work correctly
when using (at least) the struts bridge (due to some wrapping of the
ServletRequest). One possible solution would be to let the servlet
container do the decoding by setting
ServletRequest#setCharacterEncoding() before any
ServletRequest#getParameter() call. Since the
ServletRequest#setCharacterEncoding() is called within the
CapabilitiesValve, I searched for and found two earlier invocations of
getParameter(), which must be removed to make this work.
This change delegates the character decoding, which is currently done in
ServletRequestImpl (and relies on ISO-8859-1 characters), to the servlet
container.
The invocation we're talking about is imho dispensable, as setting
pipelines is done with request attributes (not parameters). Furthermore,
the servlet api does not define a method to set request parameters
programmatically if not transmitted by the browser request. So, is it
really necessary to set the pipeline by a browser request parameter?
e.g.:
http://localhost:8080/jetspeed/?pipeline=test
which of course throws an exception.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [jira] Commented: (JS2-376) request parameter encoding problem
Posted by David Sean Taylor <da...@bluesunrise.com>.
Thorsten Berger wrote:
>
>>
>> -1
>> This will break Fusion and other solutions using alternate pipelines
>>
> I had concerns too removing this line when suggesting the patch, but the
> usage of alternate pipelines is still possible by using request
> attributes instead of request parameters. I had a look into Fusion and
> didn't find a location where the pipeline is set through a request
> parameter.
> If I do not have overlooked sth., they are set only through request
> attributes, so this patch wouldn't break Fusion.
>
>
It would break Fusion as it exists today.
A complete patch would include fixes to Fusion as well
Why is that the portal cannot rely on request parameters?
Seems like a very restrictive requirement
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [jira] Commented: (JS2-376) request parameter encoding problem
Posted by Thorsten Berger <be...@imn.htwk-leipzig.de>.
>>
>> Index:
>> components/portal/src/java/org/apache/jetspeed/engine/JetspeedEngine.java
>>
>> ===================================================================
>> ---
>> components/portal/src/java/org/apache/jetspeed/engine/JetspeedEngine.java
>> (revision 312749)
>> +++
>> components/portal/src/java/org/apache/jetspeed/engine/JetspeedEngine.java
>> (working copy)
>> @@ -189,12 +189,8 @@
>> public void service( RequestContext context ) throws
>> JetspeedException
>> {
>>
>> - String targetPipeline = context
>> -
>> .getRequestParameter(PortalReservedParameters.PIPELINE);
>> - if (null == targetPipeline)
>> - {
>> - targetPipeline =
>> (String)context.getAttribute(PortalReservedParameters.PIPELINE);
>> - }
>> + String targetPipeline =
>> (String)context.getAttribute(PortalReservedParameters.PIPELINE);
>> +
>
>
> -1
> This will break Fusion and other solutions using alternate pipelines
>
I had concerns too removing this line when suggesting the patch, but the
usage of alternate pipelines is still possible by using request
attributes instead of request parameters. I had a look into Fusion and
didn't find a location where the pipeline is set through a request
parameter.
If I do not have overlooked sth., they are set only through request
attributes, so this patch wouldn't break Fusion.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [jira] Commented: (JS2-376) request parameter encoding problem
Posted by David Sean Taylor <da...@bluesunrise.com>.
Shinsuke SUGAYA (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/JS2-376?page=comments#action_12331755 ]
>
> Shinsuke SUGAYA commented on JS2-376:
> -------------------------------------
>
> Hi developers,
>
> To fix this issue(needs to call ServletRequest#setCharacterEncoding before ServletRequest#getParameter), I have to apply the following patch. If you have any concerns when applying it, please let me know. I checked j1 and j2, but I did not find the related code.
>
> Index: components/portal/src/java/org/apache/jetspeed/engine/JetspeedEngine.java
> ===================================================================
> --- components/portal/src/java/org/apache/jetspeed/engine/JetspeedEngine.java (revision 312749)
> +++ components/portal/src/java/org/apache/jetspeed/engine/JetspeedEngine.java (working copy)
> @@ -189,12 +189,8 @@
> public void service( RequestContext context ) throws JetspeedException
> {
>
> - String targetPipeline = context
> - .getRequestParameter(PortalReservedParameters.PIPELINE);
> - if (null == targetPipeline)
> - {
> - targetPipeline = (String)context.getAttribute(PortalReservedParameters.PIPELINE);
> - }
> + String targetPipeline = (String)context.getAttribute(PortalReservedParameters.PIPELINE);
> +
-1
This will break Fusion and other solutions using alternate pipelines
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-376) request parameter encoding problem
Posted by "Shinsuke SUGAYA (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-376?page=comments#action_12331755 ]
Shinsuke SUGAYA commented on JS2-376:
-------------------------------------
Hi developers,
To fix this issue(needs to call ServletRequest#setCharacterEncoding before ServletRequest#getParameter), I have to apply the following patch. If you have any concerns when applying it, please let me know. I checked j1 and j2, but I did not find the related code.
Index: components/portal/src/java/org/apache/jetspeed/engine/JetspeedEngine.java
===================================================================
--- components/portal/src/java/org/apache/jetspeed/engine/JetspeedEngine.java (revision 312749)
+++ components/portal/src/java/org/apache/jetspeed/engine/JetspeedEngine.java (working copy)
@@ -189,12 +189,8 @@
public void service( RequestContext context ) throws JetspeedException
{
- String targetPipeline = context
- .getRequestParameter(PortalReservedParameters.PIPELINE);
- if (null == targetPipeline)
- {
- targetPipeline = (String)context.getAttribute(PortalReservedParameters.PIPELINE);
- }
+ String targetPipeline = (String)context.getAttribute(PortalReservedParameters.PIPELINE);
+
// tlRequestContext.set(context);
Pipeline pipeline = getPipeline();
if (targetPipeline != null)
> request parameter encoding problem
> ----------------------------------
>
> Key: JS2-376
> URL: http://issues.apache.org/jira/browse/JS2-376
> Project: Jetspeed 2
> Type: Bug
> Components: Components Core
> Versions: 2.0-M4
> Reporter: Thorsten Berger
> Attachments: j2_character_encoding_jira376.txt
>
> I logged an issue for the struts bridge, but found out that this problem is specific to jetspeed.
> Please see PB-14 (unable to post unicode characters in struts bridge) for an introduction.
> The problem is the character decoding done in in o.a.j.engine.servlet.ServletRequestImpl (line 157):
> try
> {
> paramValues[i] = new String(paramValues[i].getBytes("ISO-8859-1"), getCharacterEncoding());
> }
> catch (UnsupportedEncodingException e)
>
> The struts bridge now does some further wrapping of the ServletRequest resulting in calling the code above twice (and decoding decoded parameter strings again). It's clear that this results in garbage characters.
> The first call is done by jetspeed itself (providing parameters to the StrutsPortlet) and the second by the Struts RequestProcessor (to populate the form bean). However, I think this behaviour should be changed in Jetspeed.
> I'd like to suggest two solutions:
> 1: setting a request attribute indicating that request parameters have already been decoded, which prevents the second decoding
> 2: Delegating the decoding to the servlet api. (my preferred solution)
> I think hard-coding the encoding is unclean. The portal cannot count on "ISO-8859-1" parameter strings (which is especially true in the above case).
> The delegation could be achieved by:
> - removing the decoding from o.a.j.engine.servlet.ServletRequestImpl
> - changing JetspeedRequestContext.setCharacterEncoding() to set the encoding also to the wrapped HttpServletRequest
> - as you know this has to be done before the first getParameter() call is invoked, the following two calls must be removed to make this work:
> line 60 in CapabilityValveImpl (the variable "requestMediaType" is never used) and line 192 in JetspeedEngine (noticed that "targetPipeline" is never set as request parameter rather than as request attribute)
> -> results in the CapabilityValveImpl setting the characterEncoding before any getParameter() call
> As I urgently need this to work for my portal I applied solution 2. I would provide a patch for this solution if you're in agreement.
> Regards, Thorsten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-376) request parameter encoding problem
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-376?page=comments#action_12331694 ]
Ate Douma commented on JS2-376:
-------------------------------
Thorsten,
I'd suggest you provide a patch for this first and attach it to this issue. \
Then it will be much easier and quicker for us to review and test the possible effect.
Especially Shinsuke should review and test this I think as he provided the above decoding solution.
So, maybe you should drop him an email as well if he might not have seen this yet.
> request parameter encoding problem
> ----------------------------------
>
> Key: JS2-376
> URL: http://issues.apache.org/jira/browse/JS2-376
> Project: Jetspeed 2
> Type: Bug
> Components: Components Core
> Versions: 2.0-M4
> Reporter: Thorsten Berger
>
> I logged an issue for the struts bridge, but found out that this problem is specific to jetspeed.
> Please see PB-14 (unable to post unicode characters in struts bridge) for an introduction.
> The problem is the character decoding done in in o.a.j.engine.servlet.ServletRequestImpl (line 157):
> try
> {
> paramValues[i] = new String(paramValues[i].getBytes("ISO-8859-1"), getCharacterEncoding());
> }
> catch (UnsupportedEncodingException e)
>
> The struts bridge now does some further wrapping of the ServletRequest resulting in calling the code above twice (and decoding decoded parameter strings again). It's clear that this results in garbage characters.
> The first call is done by jetspeed itself (providing parameters to the StrutsPortlet) and the second by the Struts RequestProcessor (to populate the form bean). However, I think this behaviour should be changed in Jetspeed.
> I'd like to suggest two solutions:
> 1: setting a request attribute indicating that request parameters have already been decoded, which prevents the second decoding
> 2: Delegating the decoding to the servlet api. (my preferred solution)
> I think hard-coding the encoding is unclean. The portal cannot count on "ISO-8859-1" parameter strings (which is especially true in the above case).
> The delegation could be achieved by:
> - removing the decoding from o.a.j.engine.servlet.ServletRequestImpl
> - changing JetspeedRequestContext.setCharacterEncoding() to set the encoding also to the wrapped HttpServletRequest
> - as you know this has to be done before the first getParameter() call is invoked, the following two calls must be removed to make this work:
> line 60 in CapabilityValveImpl (the variable "requestMediaType" is never used) and line 192 in JetspeedEngine (noticed that "targetPipeline" is never set as request parameter rather than as request attribute)
> -> results in the CapabilityValveImpl setting the characterEncoding before any getParameter() call
> As I urgently need this to work for my portal I applied solution 2. I would provide a patch for this solution if you're in agreement.
> Regards, Thorsten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Assigned: (JS2-376) request parameter encoding problem
Posted by "Shinsuke SUGAYA (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-376?page=all ]
Shinsuke SUGAYA reassigned JS2-376:
-----------------------------------
Assign To: Shinsuke SUGAYA
> request parameter encoding problem
> ----------------------------------
>
> Key: JS2-376
> URL: http://issues.apache.org/jira/browse/JS2-376
> Project: Jetspeed 2
> Type: Bug
> Components: Components Core
> Versions: 2.0-M4
> Reporter: Thorsten Berger
> Assignee: Shinsuke SUGAYA
> Attachments: j2_character_encoding_jira376.txt
>
> I logged an issue for the struts bridge, but found out that this problem is specific to jetspeed.
> Please see PB-14 (unable to post unicode characters in struts bridge) for an introduction.
> The problem is the character decoding done in in o.a.j.engine.servlet.ServletRequestImpl (line 157):
> try
> {
> paramValues[i] = new String(paramValues[i].getBytes("ISO-8859-1"), getCharacterEncoding());
> }
> catch (UnsupportedEncodingException e)
>
> The struts bridge now does some further wrapping of the ServletRequest resulting in calling the code above twice (and decoding decoded parameter strings again). It's clear that this results in garbage characters.
> The first call is done by jetspeed itself (providing parameters to the StrutsPortlet) and the second by the Struts RequestProcessor (to populate the form bean). However, I think this behaviour should be changed in Jetspeed.
> I'd like to suggest two solutions:
> 1: setting a request attribute indicating that request parameters have already been decoded, which prevents the second decoding
> 2: Delegating the decoding to the servlet api. (my preferred solution)
> I think hard-coding the encoding is unclean. The portal cannot count on "ISO-8859-1" parameter strings (which is especially true in the above case).
> The delegation could be achieved by:
> - removing the decoding from o.a.j.engine.servlet.ServletRequestImpl
> - changing JetspeedRequestContext.setCharacterEncoding() to set the encoding also to the wrapped HttpServletRequest
> - as you know this has to be done before the first getParameter() call is invoked, the following two calls must be removed to make this work:
> line 60 in CapabilityValveImpl (the variable "requestMediaType" is never used) and line 192 in JetspeedEngine (noticed that "targetPipeline" is never set as request parameter rather than as request attribute)
> -> results in the CapabilityValveImpl setting the characterEncoding before any getParameter() call
> As I urgently need this to work for my portal I applied solution 2. I would provide a patch for this solution if you're in agreement.
> Regards, Thorsten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org