Hi, > > 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? Ups, yepp, right.
> First of all, the current container implementation is (and we did our > utmost best to refactor it to reach this) completely stateless. Yes. > 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. And I like it :) > 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. Yes, that's what I thought while looking at the code. > 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. Ok, I totally agree - either we regard is as *the way* how to handle it (but I guess each portal using Pluto might want to do it differently) or we move this stuff out of the container(-api) I would prefer moving it to the driver. > 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. Yes, and that's fine - *if* the code is not in the container :) > 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. Agree. > 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. If the code is moved to the driver I would completly write my own implementation for this stuff; which I would prefer thinking about it. I think everything else works in an OSGi environment - it's only the registration process which is not optimal atm in the container. > 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). Ah ok, yes, the method name was just an example :) Thanks for all the information. As outlined above, I think we should just remove this stuff from container and therefore make it clear that this is not intended to be used by projects embedding Pluto. Regards Carsten -- Carsten Ziegeler [email protected]
