You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "Charles Severance (JIRA)" <ji...@apache.org> on 2007/03/04 19:46:50 UTC
[jira] Created: (PLUTO-328) Add support for a callback right before
Render and Action in PortletServlet
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (PLUTO-328) Add support for a callback right before Render and Action in PortletServlet
Posted by Charles Severance <cs...@umich.edu>.
Good point - In Sakai we will have two kinds of portlets.
(a) Completely portable portlets that have no Sakai dependencies
(b) Portlets that only run in Sakai or when the Sakai APIs are present.
Even in case (a) I need access to the Sakai APIs when portlets are
running in Sakai because implementations of things like Preferences,
Userinfo (Portlet Run-time) which feed these interfaces accessing
Sakai APIs. While I could provision the thread in each of these
places, it would be much simpler and more reliable to simply
provision the thread once and then simply use the APIs - either in
the Portlet directly (non-portable) or in the Portlet-Run-Time
Environment.
So my use case about WAR portability was misguided - I still think
this is useful in general as it gives yet another access point
through optional services making the container more flexible.
/Chuck
On Mar 4, 2007, at 2:06 PM, Elliot Metsger wrote:
> > 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
Re: [jira] Created: (PLUTO-328) Add support for a callback right before Render and Action in PortletServlet
Posted by Charles Severance <cs...@umich.edu>.
I already am watching for method calls on the Render and Action
Request - but my problem is that what if they call a Sakai API
*before* they even touch the Request objects. I need to be assured
that the thread is properly provisioned *before* the first line of
the Render or Action executes.
/Chuck
On Mar 4, 2007, at 3:33 PM, Eric Dalquist wrote:
> Note what uP3 does. We have a custom impl for RenderRequest and
> ActionRequest that we provide to Pluto. The current use is this
> request watches for a portlet trying to access the USER_INFO Map
> and we actually do a DAO call in the *Request object. We also
> provide a custom PortletPreferences impl via these objects since we
> have a fairly complex prefs hierarchy that requires a custom
> implementation.
>
> Are there still things that you couldn't do with custom request
> objects that you need a listener for?
>
> Not saying it isn't a good idea, sounds like a neat hook, just not
> sure it actually needed or more useful than just having custom
> request objects.
>
> -Eric
Re: [jira] Created: (PLUTO-328) Add support for a callback right
before Render and Action in PortletServlet
Posted by Eric Dalquist <er...@doit.wisc.edu>.
Note what uP3 does. We have a custom impl for RenderRequest and
ActionRequest that we provide to Pluto. The current use is this request
watches for a portlet trying to access the USER_INFO Map and we actually
do a DAO call in the *Request object. We also provide a custom
PortletPreferences impl via these objects since we have a fairly complex
prefs hierarchy that requires a custom implementation.
Are there still things that you couldn't do with custom request objects
that you need a listener for?
Not saying it isn't a good idea, sounds like a neat hook, just not sure
it actually needed or more useful than just having custom request objects.
-Eric
Charles Severance wrote:
> I would also say one more thing about Sakai's implementation. Just
> using Sakai's request filter would not work in a portlet environment.
> Sakai's request filter is the complete equivalent of PortletServlet
> and handles the protocol between Sakai's portal re-dispatch and
> Sakai's tool run-time.
>
> It is completely parallel to the container doing the re-dispatch and
> sending stuff to PortletServlet.
>
> So I can't just add Sakai's request filter to the web.xml for a
> portlet - because Sakai is not doing the redispatch for portlets -
> only Sakai tools.
>
> /Chuck
>
> On Mar 4, 2007, at 2:06 PM, Elliot Metsger wrote:
>
>> > 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
Re: [jira] Created: (PLUTO-328) Add support for a callback right before Render and Action in PortletServlet
Posted by Charles Severance <cs...@umich.edu>.
I would also say one more thing about Sakai's implementation. Just
using Sakai's request filter would not work in a portlet
environment. Sakai's request filter is the complete equivalent of
PortletServlet and handles the protocol between Sakai's portal re-
dispatch and Sakai's tool run-time.
It is completely parallel to the container doing the re-dispatch and
sending stuff to PortletServlet.
So I can't just add Sakai's request filter to the web.xml for a
portlet - because Sakai is not doing the redispatch for portlets -
only Sakai tools.
/Chuck
On Mar 4, 2007, at 2:06 PM, Elliot Metsger wrote:
> > 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
Re: [jira] Created: (PLUTO-328) Add support for a callback right
before Render and Action in PortletServlet
Posted by Elliot Metsger <em...@jhu.edu>.
> 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.
>
>
>
[jira] Updated: (PLUTO-328) Add support for a callback right before
Render and Action in PortletServlet
Posted by "Charles Severance (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PLUTO-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charles Severance updated PLUTO-328:
------------------------------------
Attachment: pluto-csev-patch-PLUTO-328.txt
I refactored and called this "PortletServletService" because it really is a helper for the PortletServlet.
> 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
> Assigned To: David DeWolf
> Priority: Minor
> Fix For: 1.2.0
>
> 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.
[jira] Closed: (PLUTO-328) Add support for a callback right before
Render and Action in PortletServlet
Posted by "Elliot Metsger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PLUTO-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Elliot Metsger closed PLUTO-328.
--------------------------------
> 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.
[jira] Commented: (PLUTO-328) Add support for a callback right
before Render and Action in PortletServlet
Posted by "Charles Severance (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PLUTO-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477862 ]
Charles Severance commented on PLUTO-328:
-----------------------------------------
I have my patch attached as a file. it is to be applied to trunk.
> 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
> Assigned To: David DeWolf
> Priority: Minor
> Fix For: 1.2.0
>
>
> 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.
[jira] Commented: (PLUTO-328) Add support for a callback right
before Render and Action in PortletServlet
Posted by "David DeWolf (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PLUTO-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478239 ]
David DeWolf commented on PLUTO-328:
------------------------------------
I like this. Thanks for the patch. I'm going to make two changes:
1) Use an event object to encapsulate event info. This will allow us to more easily provide backwards compatibility as we add additional methods (for instance when we need to include eventing invocations in 286). It will also allow portals to use the same listener method for multiple types if they desire.
2) Revert back to PortalAdministrationService because this talks about WHAT it does rather than HOW it does it. At some point I wouldn't be shocked if we don't have a Servlet for invocation but have a Filter or perhaps even another method that doesn't use cross context dispatching (way in the future, don't get excited). This will prevent us from having to rename these in those situations.
> 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.
[jira] Resolved: (PLUTO-328) Add support for a callback right
before Render and Action in PortletServlet
Posted by "David DeWolf (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PLUTO-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David DeWolf resolved PLUTO-328.
--------------------------------
Resolution: Fixed
Added. Give it a try and let me know what you think.
> 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.
[jira] Updated: (PLUTO-328) Add support for a callback right before
Render and Action in PortletServlet
Posted by "David DeWolf (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PLUTO-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David DeWolf updated PLUTO-328:
-------------------------------
Fix Version/s: (was: 1.1.1)
1.2.0
Assignee: David DeWolf
> 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
> Assigned To: David DeWolf
> Priority: Minor
> Fix For: 1.2.0
>
>
> 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.
[jira] Updated: (PLUTO-328) Add support for a callback right before
Render and Action in PortletServlet
Posted by "David DeWolf (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PLUTO-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David DeWolf updated PLUTO-328:
-------------------------------
Fix Version/s: (was: 1.2.0)
1.1.2
Affects Version/s: (was: 1.1.0)
1.1.1
> 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.
[jira] Commented: (PLUTO-328) Add support for a callback right
before Render and Action in PortletServlet
Posted by "Charles Severance (JIRA)" <ji...@apache.org>.
[ 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.