I think this is a great idea.This is one of those things that every portal that uses pluto will eventually like to do and having everyone write their own is just dumb.
The high level description sounds good, I'd like to hear more about your ideas for the responsibilities of the callback impls and the optional services.
-Eric Elliot Metsger wrote:
All,I'd like to add hot deploy and auto assembly to Pluto. Acknowledging that there may be a debate as to whether or not these are container versus portal services, the goal is to make assembly and hot deployment as easy as possible for portal implementors that use the Pluto container. Hot deploy and auto-assembly would work out of the box for users of Pluto portal.Here are my high-level thoughts without going into too much detail - please push back on them.Add two optional container services: PortletAssembly and PortletDeployment. Each service has a callback interface associated with it: PortletAssemblyCallback and PortletDeploymentCallback.The portal can provide full implementations PortletAssembly and PortletDeployment if it wishes. However, most portals will choose to provide implementations of the more simple callback interfaces.If the portal provides its own implementation of the interfaces, the container will use those. If the portal provides only the callbacks, the container will use its default implementation of the PortletAssembly and PortletDeployment interfaces, delegating to the callbacks where appropriate. If callbacks are not provided by the portal, then auto-assembly and hot-deploy will not be activated.From a high level, how does this sound?Implementation-wise I've been playing around. For the container to do auto-assembly, it needs to have access to the Pluto assembly code in a shared classloader.I've had to extract the assembly code from pluto-util into its own code module, and deploy the assembly code to shared. If you refactor the assembly code to not use UtilityException (AssemblyException was created and used instead), then the only dependencies added to shared are the pluto-assembler jar and commons-io (If commons-io isn't acceptable to load into shared, we can refactor it out). Since this approach modifies the exceptions on existing Assembly interfaces, this probably wouldn't make it into 1.1 for backwards compatibility reasons.Thoughts? Thanks, Elliot
smime.p7s
Description: S/MIME Cryptographic Signature
