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 <cs...@umich.edu> on 2007/03/04 06:41:00 UTC
A feature Idea - Portlet Servlet
David,
I really think that the code adding Listeners to the ADMIN requests
is sweet - and no good deed goes unpunished. I really would like
similar code added both to the Render and Action code (i.e. check to
see if there is a listener registered with the container and hand the
request/response off to the listener *right before* the render and
action calls.
I need this to get some code to run inside the servlet to set a few
things in thread local so Sakai APIs work once portlets start. I am
guessing that many containers will want this same opportunity. It is
like a "light" Portlet filter. I am not suggesting a filter pattern
or a wrapping pattern - just give me a moment *right before* render
is called.
/Chuck
// The requested method is RENDER: call Portlet.render(..)
if (methodId == Constants.METHOD_RENDER) {
RenderRequestImpl renderRequest =
(RenderRequestImpl) portletRequest;
RenderResponseImpl renderResponse =
(RenderResponseImpl) portletResponse;
// check to see if there is a registered listener for
renders and call
portlet.render(renderRequest, renderResponse);
}
// The requested method is ACTION: call
Portlet.processAction(..)
else if (methodId == Constants.METHOD_ACTION) {
ActionRequestImpl actionRequest =
(ActionRequestImpl) portletRequest;
ActionResponseImpl actionResponse =
(ActionResponseImpl) portletResponse;
// check to see if there is a registered listener for
action and call
portlet.processAction(actionRequest, actionResponse);
}
// The requested method is ADMIN: call handlers.
else if (methodId == Constants.METHOD_ADMIN) {
ContainerInvocation inv =
ContainerInvocation.getInvocation();
PortalAdministrationService pas =
inv.getPortletContainer()
.getOptionalContainerServices()
.getPortalAdministrationService();
Iterator it = pas.getAdministrativeRequestListeners
().iterator();
while(it.hasNext()) {
AdministrativeRequestListener l =
(AdministrativeRequestListener)it.next();
l.administer(portletRequest, portletResponse);
}
}
Re: A feature Idea - Portlet Servlet
Posted by Charles Severance <cs...@umich.edu>.
David,
I re-factored it a it and called it PortletServletService instead of
PortletPrepareService because really it is a helper to the
PortletServlet.
I have a patch attached to http://issues.apache.org/jira/browse/
PLUTO-328 and attached below.
I would propose that the way to add "events" is to simply add methods
to this Service and scatter them throughout PortletServlet as we need
to.
I would also suggest (not strongly) that we simply fold the adminster
() method into to this new service - after coordinating with Eric
(perhaps another release).
Now off to debugging the Sakai Implementation of this new service...
Almost working :)
And once again - no need to hold up 1.1.1 for this.
/Chuck
On Mar 4, 2007, at 2:22 PM, David H. DeWolf wrote:
> I like this . . .and I think we could support additional events as
> well. I'd like to come up with an eventing model that's flexible
> and easily scales. Do you mind if this waits until 1.1.2 so it
> doesn't hold up 1.1.1?
Re: A feature Idea - Portlet Servlet
Posted by Charles Severance <cs...@umich.edu>.
Verified as fixed in trunk - Sakai is once again a happy camper.
Thanks.
/Chuck
On Mar 4, 2007, at 2:53 PM, Elliot Metsger wrote:
> Done r514462.
>
> Elliot Metsger wrote:
>> being fixed now...
>> Charles Severance wrote:
>>> But there *is* a problem with 1.1.1 (castor.properties) that
>>> might be worthfixing before 1.1.1. Broke Sakai solidly.
>>>
>>> http://issues.apache.org/jira/browse/PLUTO-329
>>>
>>> /Chuck
Re: A feature Idea - Portlet Servlet
Posted by Elliot Metsger <em...@jhu.edu>.
Done r514462.
Elliot Metsger wrote:
> being fixed now...
>
> Charles Severance wrote:
>
>> But there *is* a problem with 1.1.1 (castor.properties) that might be
>> worthfixing before 1.1.1. Broke Sakai solidly.
>>
>> http://issues.apache.org/jira/browse/PLUTO-329
>>
>> /Chuck
>>
>> On Mar 4, 2007, at 2:22 PM, David H. DeWolf wrote:
>>
>>> I like this . . .and I think we could support additional events as
>>> well. I'd like to come up with an eventing model that's flexible and
>>> easily scales. Do you mind if this waits until 1.1.2 so it doesn't
>>> hold up 1.1.1?
>>>
>>> Charles Severance wrote:
>>>> David,
>>>> I really think that the code adding Listeners to the ADMIN requests
>>>> is sweet - and no good deed goes unpunished. I really would like
>>>> similar code added both to the Render and Action code (i.e. check to
>>>> see if there is a listener registered with the container and hand
>>>> the request/response off to the listener *right before* the render
>>>> and action calls.
>>>> I need this to get some code to run inside the servlet to set a few
>>>> things in thread local so Sakai APIs work once portlets start. I am
>>>> guessing that many containers will want this same opportunity. It
>>>> is like a "light" Portlet filter. I am not suggesting a filter
>>>> pattern or a wrapping pattern - just give me a moment *right before*
>>>> render is called.
>>>> /Chuck
>>>> // The requested method is RENDER: call Portlet.render(..)
>>>> if (methodId == Constants.METHOD_RENDER) {
>>>> RenderRequestImpl renderRequest =
>>>> (RenderRequestImpl) portletRequest;
>>>> RenderResponseImpl renderResponse =
>>>> (RenderResponseImpl) portletResponse;
>>>> // check to see if there is a registered listener for
>>>> renders and call
>>>> portlet.render(renderRequest, renderResponse);
>>>> }
>>>> // The requested method is ACTION: call
>>>> Portlet.processAction(..)
>>>> else if (methodId == Constants.METHOD_ACTION) {
>>>> ActionRequestImpl actionRequest =
>>>> (ActionRequestImpl) portletRequest;
>>>> ActionResponseImpl actionResponse =
>>>> (ActionResponseImpl) portletResponse;
>>>> // check to see if there is a registered listener for
>>>> action and call
>>>> portlet.processAction(actionRequest, actionResponse);
>>>> }
>>>> // The requested method is ADMIN: call handlers.
>>>> else if (methodId == Constants.METHOD_ADMIN) {
>>>> ContainerInvocation inv =
>>>> ContainerInvocation.getInvocation();
>>>> PortalAdministrationService pas =
>>>> inv.getPortletContainer()
>>>> .getOptionalContainerServices()
>>>> .getPortalAdministrationService();
>>>> Iterator it =
>>>> pas.getAdministrativeRequestListeners().iterator();
>>>> while(it.hasNext()) {
>>>> AdministrativeRequestListener l
>>>> =(AdministrativeRequestListener)it.next();
>>>> l.administer(portletRequest, portletResponse);
>>>> }
>>>> }
>>>
>>>
Re: A feature Idea - Portlet Servlet
Posted by Elliot Metsger <em...@jhu.edu>.
being fixed now...
Charles Severance wrote:
> But there *is* a problem with 1.1.1 (castor.properties) that might be
> worthfixing before 1.1.1. Broke Sakai solidly.
>
> http://issues.apache.org/jira/browse/PLUTO-329
>
> /Chuck
>
> On Mar 4, 2007, at 2:22 PM, David H. DeWolf wrote:
>
>> I like this . . .and I think we could support additional events as
>> well. I'd like to come up with an eventing model that's flexible and
>> easily scales. Do you mind if this waits until 1.1.2 so it doesn't
>> hold up 1.1.1?
>>
>> Charles Severance wrote:
>>> David,
>>> I really think that the code adding Listeners to the ADMIN requests
>>> is sweet - and no good deed goes unpunished. I really would like
>>> similar code added both to the Render and Action code (i.e. check to
>>> see if there is a listener registered with the container and hand the
>>> request/response off to the listener *right before* the render and
>>> action calls.
>>> I need this to get some code to run inside the servlet to set a few
>>> things in thread local so Sakai APIs work once portlets start. I am
>>> guessing that many containers will want this same opportunity. It is
>>> like a "light" Portlet filter. I am not suggesting a filter pattern
>>> or a wrapping pattern - just give me a moment *right before* render
>>> is called.
>>> /Chuck
>>> // The requested method is RENDER: call Portlet.render(..)
>>> if (methodId == Constants.METHOD_RENDER) {
>>> RenderRequestImpl renderRequest =
>>> (RenderRequestImpl) portletRequest;
>>> RenderResponseImpl renderResponse =
>>> (RenderResponseImpl) portletResponse;
>>> // check to see if there is a registered listener for
>>> renders and call
>>> portlet.render(renderRequest, renderResponse);
>>> }
>>> // The requested method is ACTION: call
>>> Portlet.processAction(..)
>>> else if (methodId == Constants.METHOD_ACTION) {
>>> ActionRequestImpl actionRequest =
>>> (ActionRequestImpl) portletRequest;
>>> ActionResponseImpl actionResponse =
>>> (ActionResponseImpl) portletResponse;
>>> // check to see if there is a registered listener for
>>> action and call
>>> portlet.processAction(actionRequest, actionResponse);
>>> }
>>> // The requested method is ADMIN: call handlers.
>>> else if (methodId == Constants.METHOD_ADMIN) {
>>> ContainerInvocation inv =
>>> ContainerInvocation.getInvocation();
>>> PortalAdministrationService pas =
>>> inv.getPortletContainer()
>>> .getOptionalContainerServices()
>>> .getPortalAdministrationService();
>>> Iterator it =
>>> pas.getAdministrativeRequestListeners().iterator();
>>> while(it.hasNext()) {
>>> AdministrativeRequestListener l
>>> =(AdministrativeRequestListener)it.next();
>>> l.administer(portletRequest, portletResponse);
>>> }
>>> }
>>
>>
Re: A feature Idea - Portlet Servlet
Posted by Charles Severance <cs...@umich.edu>.
I already have all the Pluto bits working completely - I am testing
it all and building Sakai's implementation to make sure I got it
right :)
I am happy to wait for 1.1.2 (early and often).
In terms of the eventing model, my instinct is to actually collapse
all of these capabilities (sorry Eric) into a single listener
interface and call it:
PortletServletService
which has admin, preRender, and preAction methods.
I would be happy for someone else to design this if they do not like
this approach. The problem is that it is hard to do refactors as
patches - particularly when you are a VI guy. :)
But there *is* a problem with 1.1.1 (castor.properties) that might be
worthfixing before 1.1.1. Broke Sakai solidly.
http://issues.apache.org/jira/browse/PLUTO-329
/Chuck
On Mar 4, 2007, at 2:22 PM, David H. DeWolf wrote:
> I like this . . .and I think we could support additional events as
> well. I'd like to come up with an eventing model that's flexible
> and easily scales. Do you mind if this waits until 1.1.2 so it
> doesn't hold up 1.1.1?
>
> Charles Severance wrote:
>> David,
>> I really think that the code adding Listeners to the ADMIN
>> requests is sweet - and no good deed goes unpunished. I really
>> would like similar code added both to the Render and Action code
>> (i.e. check to see if there is a listener registered with the
>> container and hand the request/response off to the listener *right
>> before* the render and action calls.
>> I need this to get some code to run inside the servlet to set a
>> few things in thread local so Sakai APIs work once portlets
>> start. I am guessing that many containers will want this same
>> opportunity. It is like a "light" Portlet filter. I am not
>> suggesting a filter pattern or a wrapping pattern - just give me a
>> moment *right before* render is called.
>> /Chuck
>> // The requested method is RENDER: call Portlet.render
>> (..)
>> if (methodId == Constants.METHOD_RENDER) {
>> RenderRequestImpl renderRequest =
>> (RenderRequestImpl) portletRequest;
>> RenderResponseImpl renderResponse =
>> (RenderResponseImpl) portletResponse;
>> // check to see if there is a registered listener
>> for renders and call
>> portlet.render(renderRequest, renderResponse);
>> }
>> // The requested method is ACTION: call
>> Portlet.processAction(..)
>> else if (methodId == Constants.METHOD_ACTION) {
>> ActionRequestImpl actionRequest =
>> (ActionRequestImpl) portletRequest;
>> ActionResponseImpl actionResponse =
>> (ActionResponseImpl) portletResponse;
>> // check to see if there is a registered listener
>> for action and call
>> portlet.processAction(actionRequest, actionResponse);
>> }
>> // The requested method is ADMIN: call handlers.
>> else if (methodId == Constants.METHOD_ADMIN) {
>> ContainerInvocation inv =
>> ContainerInvocation.getInvocation();
>> PortalAdministrationService pas =
>> inv.getPortletContainer()
>> .getOptionalContainerServices()
>> .getPortalAdministrationService();
>> Iterator it = pas.getAdministrativeRequestListeners
>> ().iterator();
>> while(it.hasNext()) {
>> AdministrativeRequestListener l =
>> (AdministrativeRequestListener)it.next();
>> l.administer(portletRequest, portletResponse);
>> }
>> }
>
>
Re: A feature Idea - Portlet Servlet
Posted by "David H. DeWolf" <dd...@apache.org>.
I like this . . .and I think we could support additional events as well.
I'd like to come up with an eventing model that's flexible and easily
scales. Do you mind if this waits until 1.1.2 so it doesn't hold up 1.1.1?
Charles Severance wrote:
> David,
>
> I really think that the code adding Listeners to the ADMIN requests is
> sweet - and no good deed goes unpunished. I really would like similar
> code added both to the Render and Action code (i.e. check to see if
> there is a listener registered with the container and hand the
> request/response off to the listener *right before* the render and
> action calls.
>
> I need this to get some code to run inside the servlet to set a few
> things in thread local so Sakai APIs work once portlets start. I am
> guessing that many containers will want this same opportunity. It is
> like a "light" Portlet filter. I am not suggesting a filter pattern or
> a wrapping pattern - just give me a moment *right before* render is called.
>
> /Chuck
>
> // The requested method is RENDER: call Portlet.render(..)
> if (methodId == Constants.METHOD_RENDER) {
> RenderRequestImpl renderRequest =
> (RenderRequestImpl) portletRequest;
> RenderResponseImpl renderResponse =
> (RenderResponseImpl) portletResponse;
>
> // check to see if there is a registered listener for
> renders and call
>
> portlet.render(renderRequest, renderResponse);
>
> }
>
> // The requested method is ACTION: call
> Portlet.processAction(..)
> else if (methodId == Constants.METHOD_ACTION) {
> ActionRequestImpl actionRequest =
> (ActionRequestImpl) portletRequest;
> ActionResponseImpl actionResponse =
> (ActionResponseImpl) portletResponse;
>
> // check to see if there is a registered listener for
> action and call
>
> portlet.processAction(actionRequest, actionResponse);
> }
>
> // The requested method is ADMIN: call handlers.
> else if (methodId == Constants.METHOD_ADMIN) {
> ContainerInvocation inv =
> ContainerInvocation.getInvocation();
> PortalAdministrationService pas =
> inv.getPortletContainer()
> .getOptionalContainerServices()
> .getPortalAdministrationService();
>
> Iterator it =
> pas.getAdministrativeRequestListeners().iterator();
> while(it.hasNext()) {
> AdministrativeRequestListener l
> =(AdministrativeRequestListener)it.next();
> l.administer(portletRequest, portletResponse);
> }
> }
>