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 "Shinsuke SUGAYA (JIRA)" <je...@portals.apache.org> on 2005/10/17 02:11:48 UTC
[jira] Resolved: (JS2-376) request parameter encoding problem
[ 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
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
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
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