Subclassing Portal

I've been struggling with WebSphere Portal 5, needing to provide an authenticated file download in portlet capability. Because portlets, unlike servlets, are responsible for only a portion of each web page, the portlet is not permitted to hijack the outputstream and send out a file.

This issue has been addressed in jetspeed-2, using fileserver pipelines. It may be possible in servers that implement JSR 168, using the RenderResponse implementation, but I'm not using those capabilities at this point.

As I pondered this problem, I kept coming back to the fact that Portal itself is, essentially, a big servlet. Servlets are typically implemented in Java. When you have a Java class that isn't doing exactly what you want, you subclass it, override the offending method and implement the behavior you desire.

Can this be done with WebSphere Portal? Is it possible to subclass the Portal servlet itself?

[UPDATE]

I did some more digging and found that a likely candidate is com.ibm.wps.engine.Servlet. I attempted to subclass this, but quickly discovered that key methods, such as doGet and doPost, are marked as final. Clearly this servlet was not meant to be subclassed.

Suppose that one wanted to add the ability for a portlet to return a file, leaving the portal/portlets interface otherwise unupdated. Would it work to implement a proxy for com.ibm.wps.engine.Servlet, simply calling the portal servlet from every method (instead of super)?

If such an object could actually stand in for the portal servlet, one could add a hijackOutputStream() method to be called by portlets. This method would create and provide an alternate outputStream for use by the portlet. When the doGet or doPost of the portal servlet returned, the original outputStream would be discarded (or emptied) and replaced by the alternate outputStream. (This would be easier to visualize with a diagram.)

Knowing as little as I know, this seems like a reasonable approach. However, I don't seem to have time to try it just now.