[
https://issues.apache.org/jira/browse/PLUTO-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479926
]
Charles Severance commented on PLUTO-328:
-----------------------------------------
I took a quick look and your approach indeed does look far nicer and more
general than my approach. Once I get Sakai safely up to Pluto 1.1.1 and
checked in - I will jump to and refactor the Sakai code to use the new approach
for 1.1.2.
> 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.1
> Reporter: Charles Severance
> Assigned To: David DeWolf
> Priority: Minor
> Fix For: 1.1.2
>
> Attachments: pluto-csev-patch-PLUTO-328.txt
>
>
> 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.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
