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 zzkhan <zz...@gmail.com> on 2010/01/23 22:29:38 UTC
How to access HttpServletRequest data in portletRequest
Hi, I need to access query string parameters which are in the URL used to
access the portal page on which my portlet is rendered. Essentially, I am
after the Request Param Map object in the HttpServletRequest. Is there
anyway in pluto I can do this?
Thanks.
--
View this message in context: http://old.nabble.com/How-to-access-HttpServletRequest-data-in-portletRequest-tp27290070p27290070.html
Sent from the Pluto - Dev mailing list archive at Nabble.com.
Re: How to access HttpServletRequest data in portletRequest
Posted by Ate Douma <at...@douma.nu>.
Hi zzkhan,
Sorry for the delayed response but I was too occupied with other tasks that this one slipped by.
I have a few suggestions on your questions inline below.
HTH,
Ate
On 01/27/2010 08:54 PM, zzkhan wrote:
>
> Ate, Thanks for the reply, Ive tried to answer/comment on your response below
> and am eagerly waiting for some more feedback!
>
> However, if you're willing to leverage pluto specific (e.g. proprietary to
> the container/portal implementation) API, there are ways to access the full
> client *Servlet* request parameter map.
>
> Yes, at this stage I am williing to use pluto specific stuff if this gets me
> running faster as time is more of a priority for me as opposed to future
> portability of this app. Are you able to point me to the right direction in
> terms of documentation/examples?
>
>
> If you are developing standard portlets or targeting a solution which should
> also work on portlet containers however, you should stick to the Portlet API
> only and accept the above limitation (there are good reasons why you
> shouldn't want/need to access the underlying Servlet
> API directly).
>
> There might even be other ways to solve your functional needs which stick to
> the spec. but you'll have to explain them for us to be able to advise you in
> that.
>
>
> The overall context of the work I am doing is that we are trying to port an
> existing (JSR168) portlet application from vignette to pluto.
>
> One of the initial things we discovered was that the portlet uses some
> information which initially lies (or is populated by other components e.g.
> Filters) in the HttpServletRequest but is then made available in the
> PortletRequest by some 'glue code' which is actually a couple of
> customization classes (extending vignette base classes) that we developed
> and hooked into the vignette portal that hosts the portlet.
>
> What I am looking for is equivalent 'extension points' in Pluto which I can
> use to achieve the same as what has been done using vignette. Specifically
> this would be:
>
> 1) Making the ParameterMap from HttpServletRequest available in the
> PortletRequest.
> 2) Be able to take any RequestAttribute from HttpServletRequest and make it
> available in the PortletRequest.
>
> I would agree to the principle that the portlet should not need access to
> data in the underlying Servlet API but because in this instance I am
> migrating an existing application which has been coded such that it relies
> on ServletRequest data, I am trying not to change too much of the code and
> instead followingp the approach of 'provide it what ever it needs to work'
> if that makes any sense.
>
> If you really want to use the Pluto specific API it'll depends on which
> version of Pluto you're using (1.x and 2.x having a completely different
> container implementation).
>
> We are using Pluto 1.1.7
In Pluto 1.1.7, you should be able to retrieve the underlying servlet request using the following:
HttpServletRequest servletRequest = ((org.apache.pluto.internal.InternalPortletRequest)portletRequest).getHttpServletRequest();
>
> BTW, Jetspeed Portal (which uses the Pluto container) provides an
> additional/optional configuration which removes the above described
> restriction (per portlet if needed) thus providing all query string
> parameters on the URL on a PortletRequest parameter map, without need to use
> Jetspeed specific API. That still isn't portable to other portals but at
> least you don't need to use a proprietary API to leverage it.
>
> Have been playing around with jetspeed as well, can you point me to the
> specfic place with the jetspeed documentation for this?
This needs you to configure one (or two, read full details about in links below) configuration property,
"merge.portal.parameters.with.portlet.parameters" either globally in jetspeed.properties or for only a specific portlet in
jetspeed-portlet.xml.
See:
http://portals.apache.org/jetspeed-2/deployguide/jetspeed-properties.html
and
http://portals.apache.org/jetspeed-2/deployguide/guide-registry.html
(search for merge.portal.parameters.with.portlet.parameters within those pages).
>
>
> Ate Douma wrote:
>>
>> On 01/26/2010 06:15 PM, Scott O'Bryan wrote:
>>> Would this not be the same at the RequestParamMap in the Portlet
>>> Request? I mean, there is no gaurentee, by spec, that the query string
>>> is what you expect it to be.
>> >
>> > Scott
>>
>> IMO: No and yes to the above two statements.
>>
>> The PortletRequest parameter map will (by spec) only provide your with the
>> query string parameters as targeting the portlet itself.
>> No other parameters should and will be provided to the portlet.
>> Note: with Portlet 2.0, this might also included shared parameters, but
>> this still isn't the same as (all) the query string parameters in
>> the URL.
>>
>> However, if you're willing to leverage pluto specific (e.g. proprietary to
>> the container/portal implementation) API, there are ways to
>> access the full client *Servlet* request parameter map.
>> If you are developing standard portlets or targeting a solution which
>> should also work on portlet containers however, you should stick to
>> the Portlet API only and accept the above limitation (there are good
>> reasons why you shouldn't want/need to access the underlying Servlet
>> API directly). There might even be other ways to solve your functional
>> needs which stick to the spec. but you'll have to explain them for us
>> to be able to advise you in that.
>>
>> If you really want to use the Pluto specific API it'll depends on which
>> version of Pluto you're using (1.x and 2.x having a completely
>> different container implementation).
>>
>> BTW, Jetspeed Portal (which uses the Pluto container) provides an
>> additional/optional configuration which removes the above described
>> restriction (per portlet if needed) thus providing all query string
>> parameters on the URL on a PortletRequest parameter map, without need to
>> use Jetspeed specific API. That still isn't portable to other portals but
>> at least you don't need to use a proprietary API to leverage it.
>>
>> Regards,
>>
>> Ate
>>
>>>
>>> On 01/23/2010 02:29 PM, zzkhan wrote:
>>>> Hi, I need to access query string parameters which are in the URL used
>>>> to
>>>> access the portal page on which my portlet is rendered. Essentially, I
>>>> am
>>>> after the Request Param Map object in the HttpServletRequest. Is there
>>>> anyway in pluto I can do this?
>>>>
>>>> Thanks.
>>>
>>
>>
>>
>
Re: How to access HttpServletRequest data in portletRequest
Posted by zzkhan <zz...@gmail.com>.
Very dissappointed to see the response trend on this forum. There is already
a great deficiancy of pluto documentation/examples on the internet which led
me to this forum. It all seems to be going downhill for me unfortunately.
zzkhan wrote:
>
> Anyone willing to reply please?
>
>
> zzkhan wrote:
>>
>> Ate, Thanks for the reply, Ive tried to answer/comment on your response
>> below and am eagerly waiting for some more feedback!
>>
>> However, if you're willing to leverage pluto specific (e.g. proprietary
>> to the container/portal implementation) API, there are ways to access the
>> full client *Servlet* request parameter map.
>>
>> Yes, at this stage I am williing to use pluto specific stuff if this gets
>> me running faster as time is more of a priority for me as opposed to
>> future portability of this app. Are you able to point me to the right
>> direction in terms of documentation/examples?
>>
>>
>> If you are developing standard portlets or targeting a solution which
>> should also work on portlet containers however, you should stick to the
>> Portlet API only and accept the above limitation (there are good reasons
>> why you shouldn't want/need to access the underlying Servlet
>> API directly).
>>
>> There might even be other ways to solve your functional needs which stick
>> to the spec. but you'll have to explain them for us to be able to advise
>> you in that.
>>
>>
>> The overall context of the work I am doing is that we are trying to port
>> an existing (JSR168) portlet application from vignette to pluto.
>>
>> One of the initial things we discovered was that the portlet uses some
>> information which initially lies (or is populated by other components
>> e.g. Filters) in the HttpServletRequest but is then made available in the
>> PortletRequest by some 'glue code' which is actually a couple of
>> customization classes (extending vignette base classes) that we developed
>> and hooked into the vignette portal that hosts the portlet.
>>
>> What I am looking for is equivalent 'extension points' in Pluto which I
>> can use to achieve the same as what has been done using vignette.
>> Specifically this would be:
>>
>> 1) Making the ParameterMap from HttpServletRequest available in the
>> PortletRequest.
>> 2) Be able to take any RequestAttribute from HttpServletRequest and make
>> it available in the PortletRequest.
>>
>> I would agree to the principle that the portlet should not need access to
>> data in the underlying Servlet API but because in this instance I am
>> migrating an existing application which has been coded such that it
>> relies on ServletRequest data, I am trying not to change too much of the
>> code and instead followingp the approach of 'provide it what ever it
>> needs to work' if that makes any sense.
>>
>> If you really want to use the Pluto specific API it'll depends on which
>> version of Pluto you're using (1.x and 2.x having a completely different
>> container implementation).
>>
>> We are using Pluto 1.1.7
>>
>> BTW, Jetspeed Portal (which uses the Pluto container) provides an
>> additional/optional configuration which removes the above described
>> restriction (per portlet if needed) thus providing all query string
>> parameters on the URL on a PortletRequest parameter map, without need to
>> use Jetspeed specific API. That still isn't portable to other portals but
>> at least you don't need to use a proprietary API to leverage it.
>>
>> Have been playing around with jetspeed as well, can you point me to the
>> specfic place with the jetspeed documentation for this?
>>
>>
>> Ate Douma wrote:
>>>
>>> On 01/26/2010 06:15 PM, Scott O'Bryan wrote:
>>>> Would this not be the same at the RequestParamMap in the Portlet
>>>> Request? I mean, there is no gaurentee, by spec, that the query string
>>>> is what you expect it to be.
>>> >
>>> > Scott
>>>
>>> IMO: No and yes to the above two statements.
>>>
>>> The PortletRequest parameter map will (by spec) only provide your with
>>> the query string parameters as targeting the portlet itself.
>>> No other parameters should and will be provided to the portlet.
>>> Note: with Portlet 2.0, this might also included shared parameters, but
>>> this still isn't the same as (all) the query string parameters in
>>> the URL.
>>>
>>> However, if you're willing to leverage pluto specific (e.g. proprietary
>>> to the container/portal implementation) API, there are ways to
>>> access the full client *Servlet* request parameter map.
>>> If you are developing standard portlets or targeting a solution which
>>> should also work on portlet containers however, you should stick to
>>> the Portlet API only and accept the above limitation (there are good
>>> reasons why you shouldn't want/need to access the underlying Servlet
>>> API directly). There might even be other ways to solve your functional
>>> needs which stick to the spec. but you'll have to explain them for us
>>> to be able to advise you in that.
>>>
>>> If you really want to use the Pluto specific API it'll depends on which
>>> version of Pluto you're using (1.x and 2.x having a completely
>>> different container implementation).
>>>
>>> BTW, Jetspeed Portal (which uses the Pluto container) provides an
>>> additional/optional configuration which removes the above described
>>> restriction (per portlet if needed) thus providing all query string
>>> parameters on the URL on a PortletRequest parameter map, without need to
>>> use Jetspeed specific API. That still isn't portable to other portals
>>> but at least you don't need to use a proprietary API to leverage it.
>>>
>>> Regards,
>>>
>>> Ate
>>>
>>>>
>>>> On 01/23/2010 02:29 PM, zzkhan wrote:
>>>>> Hi, I need to access query string parameters which are in the URL used
>>>>> to
>>>>> access the portal page on which my portlet is rendered. Essentially, I
>>>>> am
>>>>> after the Request Param Map object in the HttpServletRequest. Is there
>>>>> anyway in pluto I can do this?
>>>>>
>>>>> Thanks.
>>>>
>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://old.nabble.com/How-to-access-HttpServletRequest-data-in-portletRequest-tp27290070p27695189.html
Sent from the Pluto - Dev mailing list archive at Nabble.com.
Re: How to access HttpServletRequest data in portletRequest
Posted by zzkhan <zz...@gmail.com>.
Anyone willing to reply please?
zzkhan wrote:
>
> Ate, Thanks for the reply, Ive tried to answer/comment on your response
> below and am eagerly waiting for some more feedback!
>
> However, if you're willing to leverage pluto specific (e.g. proprietary to
> the container/portal implementation) API, there are ways to access the
> full client *Servlet* request parameter map.
>
> Yes, at this stage I am williing to use pluto specific stuff if this gets
> me running faster as time is more of a priority for me as opposed to
> future portability of this app. Are you able to point me to the right
> direction in terms of documentation/examples?
>
>
> If you are developing standard portlets or targeting a solution which
> should also work on portlet containers however, you should stick to the
> Portlet API only and accept the above limitation (there are good reasons
> why you shouldn't want/need to access the underlying Servlet
> API directly).
>
> There might even be other ways to solve your functional needs which stick
> to the spec. but you'll have to explain them for us to be able to advise
> you in that.
>
>
> The overall context of the work I am doing is that we are trying to port
> an existing (JSR168) portlet application from vignette to pluto.
>
> One of the initial things we discovered was that the portlet uses some
> information which initially lies (or is populated by other components e.g.
> Filters) in the HttpServletRequest but is then made available in the
> PortletRequest by some 'glue code' which is actually a couple of
> customization classes (extending vignette base classes) that we developed
> and hooked into the vignette portal that hosts the portlet.
>
> What I am looking for is equivalent 'extension points' in Pluto which I
> can use to achieve the same as what has been done using vignette.
> Specifically this would be:
>
> 1) Making the ParameterMap from HttpServletRequest available in the
> PortletRequest.
> 2) Be able to take any RequestAttribute from HttpServletRequest and make
> it available in the PortletRequest.
>
> I would agree to the principle that the portlet should not need access to
> data in the underlying Servlet API but because in this instance I am
> migrating an existing application which has been coded such that it relies
> on ServletRequest data, I am trying not to change too much of the code and
> instead followingp the approach of 'provide it what ever it needs to work'
> if that makes any sense.
>
> If you really want to use the Pluto specific API it'll depends on which
> version of Pluto you're using (1.x and 2.x having a completely different
> container implementation).
>
> We are using Pluto 1.1.7
>
> BTW, Jetspeed Portal (which uses the Pluto container) provides an
> additional/optional configuration which removes the above described
> restriction (per portlet if needed) thus providing all query string
> parameters on the URL on a PortletRequest parameter map, without need to
> use Jetspeed specific API. That still isn't portable to other portals but
> at least you don't need to use a proprietary API to leverage it.
>
> Have been playing around with jetspeed as well, can you point me to the
> specfic place with the jetspeed documentation for this?
>
>
> Ate Douma wrote:
>>
>> On 01/26/2010 06:15 PM, Scott O'Bryan wrote:
>>> Would this not be the same at the RequestParamMap in the Portlet
>>> Request? I mean, there is no gaurentee, by spec, that the query string
>>> is what you expect it to be.
>> >
>> > Scott
>>
>> IMO: No and yes to the above two statements.
>>
>> The PortletRequest parameter map will (by spec) only provide your with
>> the query string parameters as targeting the portlet itself.
>> No other parameters should and will be provided to the portlet.
>> Note: with Portlet 2.0, this might also included shared parameters, but
>> this still isn't the same as (all) the query string parameters in
>> the URL.
>>
>> However, if you're willing to leverage pluto specific (e.g. proprietary
>> to the container/portal implementation) API, there are ways to
>> access the full client *Servlet* request parameter map.
>> If you are developing standard portlets or targeting a solution which
>> should also work on portlet containers however, you should stick to
>> the Portlet API only and accept the above limitation (there are good
>> reasons why you shouldn't want/need to access the underlying Servlet
>> API directly). There might even be other ways to solve your functional
>> needs which stick to the spec. but you'll have to explain them for us
>> to be able to advise you in that.
>>
>> If you really want to use the Pluto specific API it'll depends on which
>> version of Pluto you're using (1.x and 2.x having a completely
>> different container implementation).
>>
>> BTW, Jetspeed Portal (which uses the Pluto container) provides an
>> additional/optional configuration which removes the above described
>> restriction (per portlet if needed) thus providing all query string
>> parameters on the URL on a PortletRequest parameter map, without need to
>> use Jetspeed specific API. That still isn't portable to other portals but
>> at least you don't need to use a proprietary API to leverage it.
>>
>> Regards,
>>
>> Ate
>>
>>>
>>> On 01/23/2010 02:29 PM, zzkhan wrote:
>>>> Hi, I need to access query string parameters which are in the URL used
>>>> to
>>>> access the portal page on which my portlet is rendered. Essentially, I
>>>> am
>>>> after the Request Param Map object in the HttpServletRequest. Is there
>>>> anyway in pluto I can do this?
>>>>
>>>> Thanks.
>>>
>>
>>
>>
>
>
--
View this message in context: http://old.nabble.com/How-to-access-HttpServletRequest-data-in-portletRequest-tp27290070p27473016.html
Sent from the Pluto - Dev mailing list archive at Nabble.com.
Re: How to access HttpServletRequest data in portletRequest
Posted by zzkhan <zz...@gmail.com>.
Ate, Thanks for the reply, Ive tried to answer/comment on your response below
and am eagerly waiting for some more feedback!
However, if you're willing to leverage pluto specific (e.g. proprietary to
the container/portal implementation) API, there are ways to access the full
client *Servlet* request parameter map.
Yes, at this stage I am williing to use pluto specific stuff if this gets me
running faster as time is more of a priority for me as opposed to future
portability of this app. Are you able to point me to the right direction in
terms of documentation/examples?
If you are developing standard portlets or targeting a solution which should
also work on portlet containers however, you should stick to the Portlet API
only and accept the above limitation (there are good reasons why you
shouldn't want/need to access the underlying Servlet
API directly).
There might even be other ways to solve your functional needs which stick to
the spec. but you'll have to explain them for us to be able to advise you in
that.
The overall context of the work I am doing is that we are trying to port an
existing (JSR168) portlet application from vignette to pluto.
One of the initial things we discovered was that the portlet uses some
information which initially lies (or is populated by other components e.g.
Filters) in the HttpServletRequest but is then made available in the
PortletRequest by some 'glue code' which is actually a couple of
customization classes (extending vignette base classes) that we developed
and hooked into the vignette portal that hosts the portlet.
What I am looking for is equivalent 'extension points' in Pluto which I can
use to achieve the same as what has been done using vignette. Specifically
this would be:
1) Making the ParameterMap from HttpServletRequest available in the
PortletRequest.
2) Be able to take any RequestAttribute from HttpServletRequest and make it
available in the PortletRequest.
I would agree to the principle that the portlet should not need access to
data in the underlying Servlet API but because in this instance I am
migrating an existing application which has been coded such that it relies
on ServletRequest data, I am trying not to change too much of the code and
instead followingp the approach of 'provide it what ever it needs to work'
if that makes any sense.
If you really want to use the Pluto specific API it'll depends on which
version of Pluto you're using (1.x and 2.x having a completely different
container implementation).
We are using Pluto 1.1.7
BTW, Jetspeed Portal (which uses the Pluto container) provides an
additional/optional configuration which removes the above described
restriction (per portlet if needed) thus providing all query string
parameters on the URL on a PortletRequest parameter map, without need to use
Jetspeed specific API. That still isn't portable to other portals but at
least you don't need to use a proprietary API to leverage it.
Have been playing around with jetspeed as well, can you point me to the
specfic place with the jetspeed documentation for this?
Ate Douma wrote:
>
> On 01/26/2010 06:15 PM, Scott O'Bryan wrote:
>> Would this not be the same at the RequestParamMap in the Portlet
>> Request? I mean, there is no gaurentee, by spec, that the query string
>> is what you expect it to be.
> >
> > Scott
>
> IMO: No and yes to the above two statements.
>
> The PortletRequest parameter map will (by spec) only provide your with the
> query string parameters as targeting the portlet itself.
> No other parameters should and will be provided to the portlet.
> Note: with Portlet 2.0, this might also included shared parameters, but
> this still isn't the same as (all) the query string parameters in
> the URL.
>
> However, if you're willing to leverage pluto specific (e.g. proprietary to
> the container/portal implementation) API, there are ways to
> access the full client *Servlet* request parameter map.
> If you are developing standard portlets or targeting a solution which
> should also work on portlet containers however, you should stick to
> the Portlet API only and accept the above limitation (there are good
> reasons why you shouldn't want/need to access the underlying Servlet
> API directly). There might even be other ways to solve your functional
> needs which stick to the spec. but you'll have to explain them for us
> to be able to advise you in that.
>
> If you really want to use the Pluto specific API it'll depends on which
> version of Pluto you're using (1.x and 2.x having a completely
> different container implementation).
>
> BTW, Jetspeed Portal (which uses the Pluto container) provides an
> additional/optional configuration which removes the above described
> restriction (per portlet if needed) thus providing all query string
> parameters on the URL on a PortletRequest parameter map, without need to
> use Jetspeed specific API. That still isn't portable to other portals but
> at least you don't need to use a proprietary API to leverage it.
>
> Regards,
>
> Ate
>
>>
>> On 01/23/2010 02:29 PM, zzkhan wrote:
>>> Hi, I need to access query string parameters which are in the URL used
>>> to
>>> access the portal page on which my portlet is rendered. Essentially, I
>>> am
>>> after the Request Param Map object in the HttpServletRequest. Is there
>>> anyway in pluto I can do this?
>>>
>>> Thanks.
>>
>
>
>
--
View this message in context: http://old.nabble.com/How-to-access-HttpServletRequest-data-in-portletRequest-tp27290070p27345826.html
Sent from the Pluto - Dev mailing list archive at Nabble.com.
Re: How to access HttpServletRequest data in portletRequest
Posted by Ate Douma <at...@douma.nu>.
On 01/26/2010 06:15 PM, Scott O'Bryan wrote:
> Would this not be the same at the RequestParamMap in the Portlet
> Request? I mean, there is no gaurentee, by spec, that the query string
> is what you expect it to be.
>
> Scott
IMO: No and yes to the above two statements.
The PortletRequest parameter map will (by spec) only provide your with the query string parameters as targeting the portlet itself.
No other parameters should and will be provided to the portlet.
Note: with Portlet 2.0, this might also included shared parameters, but this still isn't the same as (all) the query string parameters in
the URL.
However, if you're willing to leverage pluto specific (e.g. proprietary to the container/portal implementation) API, there are ways to
access the full client *Servlet* request parameter map.
If you are developing standard portlets or targeting a solution which should also work on portlet containers however, you should stick to
the Portlet API only and accept the above limitation (there are good reasons why you shouldn't want/need to access the underlying Servlet
API directly). There might even be other ways to solve your functional needs which stick to the spec. but you'll have to explain them for us
to be able to advise you in that.
If you really want to use the Pluto specific API it'll depends on which version of Pluto you're using (1.x and 2.x having a completely
different container implementation).
BTW, Jetspeed Portal (which uses the Pluto container) provides an additional/optional configuration which removes the above described
restriction (per portlet if needed) thus providing all query string parameters on the URL on a PortletRequest parameter map, without need to
use Jetspeed specific API. That still isn't portable to other portals but at least you don't need to use a proprietary API to leverage it.
Regards,
Ate
>
> On 01/23/2010 02:29 PM, zzkhan wrote:
>> Hi, I need to access query string parameters which are in the URL used to
>> access the portal page on which my portlet is rendered. Essentially, I am
>> after the Request Param Map object in the HttpServletRequest. Is there
>> anyway in pluto I can do this?
>>
>> Thanks.
>
Re: How to access HttpServletRequest data in portletRequest
Posted by Scott O'Bryan <da...@gmail.com>.
Would this not be the same at the RequestParamMap in the Portlet
Request? I mean, there is no gaurentee, by spec, that the query string
is what you expect it to be.
Scott
On 01/23/2010 02:29 PM, zzkhan wrote:
> Hi, I need to access query string parameters which are in the URL used to
> access the portal page on which my portlet is rendered. Essentially, I am
> after the Request Param Map object in the HttpServletRequest. Is there
> anyway in pluto I can do this?
>
> Thanks.
>