Eliott - I don't get it.
Sakai already does hot deploy with Pluto 1.1 - all of the code Sakai
has added that runs at the moment of the init of the PortletServlet -
runs on a re-deploy of the webapp and re-registers the portlet with
Sakai - viola - it is there. So hot-deploy is possible.
Now one thing I have noticed is that after a while, this type of hot-
deploy runs out of perm space :( I don't exactly know whose fault it
is - but in general I just restart Tomcat after a while.
Is your proposal to make hot deploy more deterministic and make it so
we clean up after things better?
I am not opposed - hot-deploy is a very cool thing - I am just trying
to understand a bit.
Charles Severance
[EMAIL PROTECTED] www.dr-chuck.com
On Jul 7, 2007, at 1:27 PM, 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
