Hi Carsten,
Sorry for the late response but I finally had some time to read and review your
proposal.
I also looked at your example implementation for Sling.
I agree its a very generic api and in theory could reduce the shared container api to this minimum, but I don't think that's going to usable
for all purposes.
This minimum shared container api will only make sense if you only need to manage and coordinate the portlet application lifecycle across
portlet applications and handle everything else within the actual portal/container webapp.
However, if you want to delegate and manage part of the container OM and services through other (portlet) web applications this solution
will not work out.
In Jetspeed for instance we provide a separate j2-admin portlet application for management of the Jetspeed portal, including the registry
(container OM), services, etc. and it uses both the *full* container-api as well as jetspeed-api extended upon the container-api for this.
This allows us (and third party users/integrators) to extend and plugin their own custom or enhanced management functionality (even through
yet another portlet application) without having to "touch" the core portal engine and application.
So, "hiding" everything from the container-api except the application lifecycle registration doesn't make sense in our case, and I'd expect
the same holds for many/most other (pluto) container usages.
Regards,
Ate
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
