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 [email protected]
