As for hot deploy I think Elliot is talking about dropping a POW (Plain Old WAR) in some directory the portal knows about and having Pluto/The Portal add the Pluto magic to the web.xml. This would help hide the non JSR-168 workings of portlets when working with Pluto more from the developer.
-Eric Charles Severance wrote:
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 <http://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
smime.p7s
Description: S/MIME Cryptographic Signature
