Re: [RT] Dynamic portlet registry

[Ate Douma <at...@douma.nu>]

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

Re: [RT] Dynamic portlet registry

[Carsten Ziegeler <cz...@apache.org>]

Hi Ate,

Ate Douma wrote:
> 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.
Great :)

> 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.
Hmm, I'm not sure if it wouldn't work. This solution is the minimal
api/infrastructure required. Now, each web application has access to the
deployed web applications, so even another portlet web app is able to
use this.
The invoker service is still used on the portal side, so the invoker can
inject any services. The receiver (named Container in this API) is
usually code from the portal, but it runs in the context of the portlet
web application. The invoker could for example inject different
receivers (Containers).


Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org