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
