Hi,
I already mentioned this topic some time ago. I've no a solution which I
think is nicer than the current solution for Pluto and I also think that
this one is generic to be used by all portals based on Pluto (it's not
even tied to Pluto).
(The class names etc. might not be optimal, but more important is the
concept itself). The following api has to be in a shared location of the
classpath, so all web applications and the portlet container share the
same classes - no other pluto classes are required in this shared
location anymore.
Each portlet application registers itself as a PortletApplication:
public interface PortletApplication {
ServletContext getServletContext();
ClassLoader getClassLoader();
}
So this interface delivers the servlet context of the portlet
application and it's class loader to the portlet container.
Then we have the PortletApplicationRegistry which is a singleton. The
singleton has a register(PortletApplication) and
unregister(PortletApplication) method.
There is a single ContainerServlet implementing the PortletApplication
interface and registering itself on startup and deregistering itself
from the PortletApplicationRegistry.
As this registry is in the shared class loader location and is a
singleton it keeps track of all portlet applications coming and going
over time. It's always available.
This is the "client" part (or the portlet web app part), now let's look
at the server part. The PortletApplicationRegistry also allows to
register a listener which is notified whenever a portlet app is
registered or unregistered. The listener gets the PortletApplication.
When a new listener is registered all currently registered apps are
notified as new, when the listener unregisters all apps are notified as
removed. This ensures that the listener always is up to date.
This is the registration process, no for the invocation of portlets.
I've another interface I called container (in lack of a better name)
which has just a service(req, res) method and it defines a request
attribute containing this object.
The invoker service puts an implementation of this interface into the
request attribute, calls the dispatcher which calls the above
ContainerServlet. The servlet picks up the Container object and calls
the service method. That's it; everything else is happening in the
portlet container.
Only one single servlet per portlet application is required; there is no
real logic in the servlet. It's just 5 classes which need to be in the
shared class loader space and all the work can be done in the portlet
container. In addition it supports more static scenarios and dynamic
scenarios.
WDYT?
Regards
Carsten
--
Carsten Ziegeler
[email protected]
