Portlets and servlets use similar, but different classes for representing HTTP Servlet requests, responses, and sessions. This makes sharing control code between servlets and portlets difficult: for example, a utility function which would get or set a session variable would not be usable in both portlets and servlets, despite the function calls being very similar in appearance (e.g. HttpSession.getAttribute(name) v.s. PortletSession.getAttribute(name)).

One option - if you don't need to do this sort of thing often - would be just to have a few duplicate functions that take different parameter types - but this is of course bad coding practice.

There are some Portal-specific ways of obtaining an object of the required class, using special knowledge of how to retrieve a particular object from a request, or by knowing which objects are safe to cast (e.g. Apache Pluto's portlet RenderRequest can be safely cast to a HttpServletRequest).

This generic, JSR168-compliant solution is to use simple wrappers or adapters, so that a Portlet object can masquerade as an HTTP Servlet object (or vice versa). For basic requirements, like session access, this approach should be ok, but it will fail if an attempt is made to call a function which is not available on the underlying object.

The only complexity is due to the way a Portlet effectively sees 2 sessions: PORTLET_SCOPE (local to that portlet) and APPLICATION_SCOPE. When wrapping objects, you will have to know whether HttpSession attributes should be treated as PORTLET_SCOPE or APPLICATION_SCOPE PortletSession attributes, or (in reverse) you want to expose the PORTLET_SCOPE or the APPLICATION_SCOPE PortletSession attributes as simple HttpSession attributes.