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
