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
