> In Sakai's case the use case is that we need to put a few items
> (context) into thread local on every request so that the entire suite
> of Sakai APIs works in portlets.
When you say "entire suite of Sakai APIs work in portlets" do you mean
that the portlet will be able to invoke a Sakai API directly in the body
of a doView() or processAction()?
If that is the case then you have already lost compatibility right? In
that I can't take the same war file and deploy it in Jetspeed or uPortal.
Elliot
Charles Severance (JIRA) wrote:
Add support for a callback right before Render and Action in
PortletServlet
---------------------------------------------------------------------------
Key: PLUTO-328 URL: https://issues.apache.org/jira/browse/PLUTO-328
Project: Pluto Issue Type: New Feature Components: portlet container
Affects Versions: 1.1.0 Reporter: Charles Severance Priority: Minor
Fix For: 1.1.1
Basically we need another Optional service that provides a user of
Pluto's container (like Sakai) with the opportunity to adjust things
*right* before Action and Render is called.
In Sakai's case the use case is that we need to put a few items
(context) into thread local on every request so that the entire suite
of Sakai APIs works in portlets.
For Sakai tools, this is done with a Request Filter - but for Pluto I
do not want to add anything like a filter because I want to maintain
100% binary compatibility of war files between Sakai and all other
Pluto 1.1 based implementations - so for me an answer that says "just
hack the web.xml and add your filter" is not acceptible.
I am already working on this and have complete but untested code.
Once everything tests out, I will post a patch. Here is the basic
idea (imitating the ADMIN listener):
+public interface PortletPrepareListener { + + void
preRender(PortletRequest request, PortletResponse response); + +
void preAction(PortletRequest request, PortletResponse response); +
+}
I use Exactly the same pattern as the ADMIN listener. I decided one
listener with two methods was better than two listeners.
And frankly - people smarter than me migh actually decide to refactor
this and call our new friend the "PortletServletListener" and have
three mentods (admin, preRender, and preAction).
Once I hand in my patch - I am happt to see the refactor happen -
based on what folks think.
