You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Ajay Panagariya <ap...@gmail.com> on 2007/07/17 19:26:04 UTC

Problem passing URI as a parameter

Hi,

I've got a problem when I try to pass parameters that are formatted as
URI's.

Some URI's are of the form

(a)   http://www.example.com/test?item=pluto.apache.com

others are of the form

(b)   http://www.example.com/test?item=pluto.apache.com/wiki?id=1234

In (b), the special characters get encoded as %F3's, etc. When it gets to
processAction method in the portlet, the URI of concern (the 'item'
parameter in this case) looks fine. By this parameters gets to the doView,
I've lost everything after the '?'.

As it stands, I'm using URI.getPath() and URI.getQuery(), and passing each
half seperately, but this solution really doesn't lend itself to
flexibility. I can't figure out what the problem is or why the URI isn't
passed properly. This portlet code has worked in previous version of Pluto,
but in the current 1.2 it does not seem to work as expected. Can anyone shed
some light onto a possible solution, or maybe what I might be doing wrong?
Has anyone encountered this before?

I am trying to port some portlets (no pun intended) to Pluto 1.2, but my
solution of URI.getPath() and URI.getQuery() seems to look worse and worse
idea with each portlet I need to repair.

I know a lot happens between processAction and doView, and I've tried
stepping through it, but I can't seem to pinpoint where my URI is getting
chopped in half.

-Ajay Panagariya

Re: Problem passing URI as a parameter

Posted by Joe Bohn <jo...@earthlink.net>.
Yes, it looks like Ajay has sorted this out with pluto-396 ( 
https://issues.apache.org/jira/browse/PLUTO-396 ) .  Can somebody take a 
look at his patch and if it looks good integrate it?  We've been looking 
to move Geronimo to use Pluto 1.2 but this is one of the problems that 
we're having.

Thanks,
Joe


Marc Veary wrote:
> 361
> 
> However, I see you have sorted it :-)
> 
> On 7/18/07, *Ajay Panagariya* <apanagar@gmail.com 
> <ma...@gmail.com>> wrote:
> 
>     Thanks for that tip.I believe you're talking about Pluto-247?
> 
> 
>     On 7/18/07, *Marc Veary* <nwlcoc@googlemail.com
>     <ma...@googlemail.com>> wrote:
> 
>         There was a patch added to URL parser, I'm not sure if this has
>         had impact on this.  I'll have a look.
> 
>         Kind regards,
>         --
>         Marc
> 
> 
>         On 7/17/07, * Ajay Panagariya* <apanagar@gmail.com
>         <ma...@gmail.com>> wrote:
> 
>             Hi,
> 
>             I've got a problem when I try to pass parameters that are
>             formatted as URI's.
> 
>             Some URI's are of the form
> 
>             (a)   http://www.example.com/test?item=pluto.apache.com
>             <http://www.example.com/test?item=pluto.apache.com>
> 
>             others are of the form
> 
>             (b)  
>             http://www.example.com/test?item=pluto.apache.com/wiki?id=1234
>             <http://www.example.com/test?item=pluto.apache.com/wiki?id=1234>
> 
>             In (b), the special characters get encoded as %F3's, etc.
>             When it gets to processAction method in the portlet, the URI
>             of concern (the 'item' parameter in this case) looks fine.
>             By this parameters gets to the doView, I've lost everything
>             after the '?'.
> 
>             As it stands, I'm using URI.getPath() and URI.getQuery(),
>             and passing each half seperately, but this solution really
>             doesn't lend itself to flexibility. I can't figure out what
>             the problem is or why the URI isn't passed properly. This
>             portlet code has worked in previous version of Pluto, but in
>             the current 1.2 it does not seem to work as expected. Can
>             anyone shed some light onto a possible solution, or maybe
>             what I might be doing wrong? Has anyone encountered this before?
> 
>             I am trying to port some portlets (no pun intended) to Pluto
>             1.2, but my solution of URI.getPath() and URI.getQuery()
>             seems to look worse and worse idea with each portlet I need
>             to repair.
> 
>             I know a lot happens between processAction and doView, and
>             I've tried stepping through it, but I can't seem to pinpoint
>             where my URI is getting chopped in half.
> 
>             -Ajay Panagariya
> 
> 
> 
> 

Re: Problem passing URI as a parameter

Posted by Marc Veary <nw...@googlemail.com>.
361

However, I see you have sorted it :-)

On 7/18/07, Ajay Panagariya <ap...@gmail.com> wrote:
>
> Thanks for that tip.I believe you're talking about Pluto-247?
>
> On 7/18/07, Marc Veary <nwlcoc@googlemail.com > wrote:
> >
> > There was a patch added to URL parser, I'm not sure if this has had
> > impact on this.  I'll have a look.
> >
> > Kind regards,
> > --
> > Marc
> >
> > On 7/17/07, Ajay Panagariya <ap...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I've got a problem when I try to pass parameters that are formatted as
> > > URI's.
> > >
> > > Some URI's are of the form
> > >
> > > (a)   http://www.example.com/test?item=pluto.apache.com
> > >
> > > others are of the form
> > >
> > > (b)   http://www.example.com/test?item=pluto.apache.com/wiki?id=1234
> > >
> > > In (b), the special characters get encoded as %F3's, etc. When it gets
> > > to processAction method in the portlet, the URI of concern (the 'item'
> > > parameter in this case) looks fine. By this parameters gets to the doView,
> > > I've lost everything after the '?'.
> > >
> > > As it stands, I'm using URI.getPath() and URI.getQuery(), and passing
> > > each half seperately, but this solution really doesn't lend itself to
> > > flexibility. I can't figure out what the problem is or why the URI isn't
> > > passed properly. This portlet code has worked in previous version of Pluto,
> > > but in the current 1.2 it does not seem to work as expected. Can
> > > anyone shed some light onto a possible solution, or maybe what I might be
> > > doing wrong? Has anyone encountered this before?
> > >
> > > I am trying to port some portlets (no pun intended) to Pluto 1.2, but
> > > my solution of URI.getPath() and URI.getQuery() seems to look worse
> > > and worse idea with each portlet I need to repair.
> > >
> > > I know a lot happens between processAction and doView, and I've tried
> > > stepping through it, but I can't seem to pinpoint where my URI is getting
> > > chopped in half.
> > >
> > > -Ajay Panagariya
> > >
> >
> >
>

Re: Problem passing URI as a parameter

Posted by Ajay Panagariya <ap...@gmail.com>.
Thanks for that tip.I believe you're talking about Pluto-247?

On 7/18/07, Marc Veary <nw...@googlemail.com> wrote:
>
> There was a patch added to URL parser, I'm not sure if this has had impact
> on this.  I'll have a look.
>
> Kind regards,
> --
> Marc
>
> On 7/17/07, Ajay Panagariya <ap...@gmail.com> wrote:
> >
> > Hi,
> >
> > I've got a problem when I try to pass parameters that are formatted as
> > URI's.
> >
> > Some URI's are of the form
> >
> > (a)   http://www.example.com/test?item=pluto.apache.com
> >
> > others are of the form
> >
> > (b)   http://www.example.com/test?item=pluto.apache.com/wiki?id=1234
> >
> > In (b), the special characters get encoded as %F3's, etc. When it gets
> > to processAction method in the portlet, the URI of concern (the 'item'
> > parameter in this case) looks fine. By this parameters gets to the doView,
> > I've lost everything after the '?'.
> >
> > As it stands, I'm using URI.getPath() and URI.getQuery(), and passing
> > each half seperately, but this solution really doesn't lend itself to
> > flexibility. I can't figure out what the problem is or why the URI isn't
> > passed properly. This portlet code has worked in previous version of Pluto,
> > but in the current 1.2 it does not seem to work as expected. Can anyone
> > shed some light onto a possible solution, or maybe what I might be doing
> > wrong? Has anyone encountered this before?
> >
> > I am trying to port some portlets (no pun intended) to Pluto 1.2, but my
> > solution of URI.getPath() and URI.getQuery() seems to look worse and
> > worse idea with each portlet I need to repair.
> >
> > I know a lot happens between processAction and doView, and I've tried
> > stepping through it, but I can't seem to pinpoint where my URI is getting
> > chopped in half.
> >
> > -Ajay Panagariya
> >
>
>

Re: Problem passing URI as a parameter

Posted by Marc Veary <nw...@googlemail.com>.
There was a patch added to URL parser, I'm not sure if this has had impact
on this.  I'll have a look.

Kind regards,
--
Marc

On 7/17/07, Ajay Panagariya <ap...@gmail.com> wrote:
>
> Hi,
>
> I've got a problem when I try to pass parameters that are formatted as
> URI's.
>
> Some URI's are of the form
>
> (a)   http://www.example.com/test?item=pluto.apache.com
>
> others are of the form
>
> (b)   http://www.example.com/test?item=pluto.apache.com/wiki?id=1234
>
> In (b), the special characters get encoded as %F3's, etc. When it gets to
> processAction method in the portlet, the URI of concern (the 'item'
> parameter in this case) looks fine. By this parameters gets to the doView,
> I've lost everything after the '?'.
>
> As it stands, I'm using URI.getPath() and URI.getQuery(), and passing each
> half seperately, but this solution really doesn't lend itself to
> flexibility. I can't figure out what the problem is or why the URI isn't
> passed properly. This portlet code has worked in previous version of Pluto,
> but in the current 1.2 it does not seem to work as expected. Can anyone
> shed some light onto a possible solution, or maybe what I might be doing
> wrong? Has anyone encountered this before?
>
> I am trying to port some portlets (no pun intended) to Pluto 1.2, but my
> solution of URI.getPath() and URI.getQuery() seems to look worse and worse
> idea with each portlet I need to repair.
>
> I know a lot happens between processAction and doView, and I've tried
> stepping through it, but I can't seem to pinpoint where my URI is getting
> chopped in half.
>
> -Ajay Panagariya
>