David H. DeWolf wrote:
Implementation:
------------------------
Pluto requires portlet applications to define a servlet that is mapped
to a special PlutoInvoker url in order to perform cross-context
dispatching. This servlet has been modified so that it automatically
registers itself with the container.
Unfortunately, it is not until servlet 2.5 (not widely deployed) that
the ServletContext is provided a contextPath property. Because of this,
and the fact that we need to register the portlet application based upon
a unique id, we attempt to derive an application id based off of the
following algorithm:
1) if a getContextPath() method exists on the ServletContext, invoke it
using reflection (so as to not fail in <= 2.4 environments) and use the
return value as the applicationId
2) if not, check to see if a init parameter or context attribute named
org.apache.pluto.CONTEXT_PATH has been set. If so, use it's value as
the applicationId
3) if not, check to see if the web app has been given a name
(ServletContext.getServletContextName()). If so, retrieve it's value
and use a hex string version of it for the applicationId.
4) if not, generate a random string and us it. This final fallback
allows the portlet to only be used temporarily. (If anyone has any
better ideas on what else we can use, please let me know - perhaps a
unique string derived off of the portlets available within the app).
The bottom line, is that after this work is complete (1 week?) there
will not longer be a need to "publish" portlets to the container.
Instead, once the portlet app war is deployed by the app server, it will
automatically take care of the rest.
I just modified this and now ONLY use the contextPath. I use the
following algorithm to resolve the path when it's not directly available
(e.g., it's inside an init instead of a request).
1) if a getContextPath() method exists on the ServletContext, invoke it
using reflection (so as to not fail in <= 2.4 environments) and use the
return value as the applicationId
2) if not, retreive the URL to web.xml from the ServletContext. Convert
this url to it's external form and extract out of it the "base"
directory or war name.
this allows us to keep invocation consistent and not have to support any
identifier expect for the contextPath for dispatching.
Yippeeee (and thanks to the sakai portal team for the idea!)
David
