I've committed the code to Apache Sling for now, so everyone interested can have a look here:
https://svn.apache.org/repos/asf/incubator/sling/whiteboard/portal/container-api Carsten Carsten Ziegeler wrote: > 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]
