Carsten Ziegeler wrote:
I'm currently trying to use Pluto for implementing a portal for
ApacheSling and I'm not stumbling across the PortalContextService which
is used by the PortletServlet to register/unregister services.
The current mechanism is fine if the portlet container is
started/stopped together with the servlet container. In Apache Sling we
use OSGi and the container itself is a bundle which can be started,
stopped, updated at any time. So currently whenever I restart the
container bundle, all registered servlets get lost as the PortletServlet
does not try to re-register.
I think we could easily handle this more dynamic case if we implement a
simple registry in the portlet api itself.
What do you mean by "in the portlet api"?
The portlet api is "given" and cannot be "extended" as such.
I assume you mean the container api, or more precisely, the container.driver.*
api, right?
So the portlet api provides a
ContextService (no good idea for the interface names yet, so I just
choose the shortest available for this mail):
- register(Callback)
- unregister(Callback)
- Iterator<Callback) getCallbacks()
These methods are invoked by the servlet on init/destroy. The servlet
itself implements the Callback interface:
- ServletContext getServletContext()
- String getPortletName()
- init(DriverPortletContext, DriverPortletConfig)
- destroy()
When the container starts it gets all callbacks from the ContextService,
and calls the init() method. When the container stops, it calls all
destroy methods.
If the servlet unregisters while the container is not up, nothing
happens; if it unregisters while the container is up, destroy() is called.
This is just a quick draft out of the top of my head.
WDYT?
Hi Carsten,
I've got several different comments on this.
First of all, the current container implementation is (and we did our utmost
best to refactor it to reach this) completely stateless.
The container no longer is tied to the "management" of the portlet applications and corresponding invoker servlet and the registry and
context services.
That separation was really needed to be able to reuse the container for different *portal* implementations and not enforce and/or imply any
kind of "state" management upon them.
The Pluto Portal Driver does provide an easy to use and convenient, but also simplistic, "management" environment which you can leverage (or
extend!) but IMO should not be regarded as an crucial or even important part of the Pluto container.
To be honest, I'm actually tempted to *separate* all the pluto.container.driver.* from both the container-api and the container
implementation itself because of that. For example, Jetspeed uses none of the .driver.* at all as we have far more reaching requirements.
Furthermore, the goal and charter of the Pluto Portal Driver is only to provide an easy testbed for the container itself, not targeted at
production usage. I seriously advise anyone using (or considering) Pluto Portal Driver as a real portal to reconsider or at least invest
plenty on extending and improving it. Doing that however within the Pluto project is beyond the scope of our charter.
Now, having said all that, this doesn't mean I'm all against slight enhancements on the .driver.* api, but as the Portal Driver clearly
isn't targeted and neither should need to become an OSGi manageable bundle, adding features specifically for OSGi management while within
the Pluto project itself there is no use-case (so will go untested) doesn't sound like a good idea to me.
If definitely have no problem in inproving/enhancing the *container* to make it (more) OSGi enabled, but AFAIK, it already is (or should) be
fully employable as an OSGi bundle right now.
If I'm missing the point and you are meaning container functionality here than
I fully support improvements in that area.
If I do understand your usage and requirements correctly however, what might help is the actual separation of the pluto context & registry
services (e.g. the .container.driver.*) from the container-api and container artifacts, like as I said already above.
Then it should be easy to extend the needed .driver.* classes (including the PortletServlet) and add the above Callback functionality in for
example Sling PortalDriver packages and maintain independent (OSGi) lifecycles for portal, container and portal apps bundles.
I also suggest adding a separate and different method from the current destroy() method in your PortletServlet extension, as it currently is
overlaying the Servlet.destroy() method. Calling that (Servlet)destroy() method when the portlet container goes away as you suggested would
effectively "interfere" with the servlet container lifecycle contract, unless you actually want to destroy the servlet, not just unregister
from the portlet container (but then, you probably should just stop the OSGi bundle (first) for that portlet app instead).
Regards,
Ate
Carsten
