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] >