Re: Retrieving HTTP Servlet Info

Woonsan Ko <[email protected]> Fri, 11 May 2012 12:17:39 -0700 (PDT)
Newsgroups gmane.comp.jakarta.jetspeed.user
Message-ID <[email protected]>
Hi Ron,

Probably there must have been a confusion.
RequestContext (org.apache.jetspeed.request.RequestContext) has purely been in the shared jetspeed-api jar! [1]
Therefore, it wouldn't bring that kind of classloader problems at all.
Please don't be confused with the implementation class, JetspeedRequestContext, or something else (such as those from wicket or spring).

Regards,

Woonsan

[1] https://svn.apache.org/repos/asf/portals/jetspeed-2/portal/trunk/jetspeed-api/src/main/java/org/apache/jetspeed/request/RequestContext.java


----- Original Message -----
> From: Ron McNulty <[email protected]>
> To: Jetspeed Users List <[email protected]>; Woonsan Ko <[email protected]>
> Cc: 
> Sent: Friday, May 11, 2012 4:29 PM
> Subject: Re: Retrieving HTTP Servlet Info
> 
> Hi Woonsan
> 
> I have this working, so I thought I would report results.
> 
> Using your RequestContext idea turned out to be not too useful. The problem is 
> that RequestContext is an internal Jetspeed class, not one that is in 
> JetspeedApi.jar. That meant that I would need to package a lot of internal 
> Jetspeed jars into my application. A big red sign saying CLASSLOADER PROBLEMS 
> AHEAD was spotted, so I backed away from that approach.
> 
> So I turned to the hacker's friend - the Java reflection API. With a bit of 
> experimentation I managed to get the ServletContext, HttpServletRequest and 
> HttpServletResponse from their portlet counterparts. The new class is simply in 
> a jar that I put into the /lib directory, and it only imports the reflection, 
> servlet and portlet apis.
> 
> A welcome extra is that we can now easily read URL parameters from the 
> HttpServletRequest - something I think should have been included in JSR286. We 
> use full-page portlets extensively, and IPC does not allow passing parameters to 
> a portlet on a separate page.
> 
> Thanks for your feedback. I could create a Wiki page on this if you agree.
> 
> Regards
> 
> Ron
> 
> ----- Original Message ----- From: "Woonsan Ko" 
> <[email protected]>
> To: "Jetspeed Users List" <[email protected]>
> Sent: Friday, April 27, 2012 9:45 PM
> Subject: Re: Retrieving HTTP Servlet Info
> 
> 
> Hi Ron,
> 
> You can retrieve HTTP headers through PortletRequest#getProperties() and 
> #getProperty(name), but you cannot retrieve portal servlet request parameters 
> with those APIs.
> You may retrieve and carefully use portal servlet request, portal servlet 
> response and portal servlet config directly through 
> org.apache.jetspeed.request.RequestContext#getRequest(), #getResponse(), and 
> #getConfig().
> RequestContext object can be retrieved as follows:
> 
> RequestContext rc = (RequestContext) 
> portletRequest.getAttribute(RequestContext.REQUEST_PORTALENV);
> 
> Regards,
> 
> Woonsan
> 
> 
> 
>>  ________________________________
>>  From: Ron McNulty <[email protected]>
>>  To: Jetspeed Users List <[email protected]>
>>  Sent: Friday, April 27, 2012 3:42 PM
>>  Subject: Retrieving HTTP Servlet Info
>> 
>>  Hi All
>> 
>>  I have a legacy application that runs on IBM Websphere Portal that I need 
> to now run on Jetspeed. It uses the Apache Portlet Bridge, plus an IBM specific 
> class to get the ServletContext, HTTPRequest and HTTPResponse from the portlet 
> related structures. I need to replace this class with a Jetspeed version.
>> 
>>  Yes, I know JSR286 prohibits this, but I need to do the minimum work to get 
> this running (We develop on Jetspeed and deploy to IBM for production).
>> 
>>  I seem to remember that the HTTP parameters may be available from a 
> properties structure, but can't find the reference.
>> 
>>  Can anyone help me out?
>> 
>>  Regards
>> 
>>  Ron
>> 
>>  Wellington, NZ
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>