portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elliot Metsger <emets...@jhu.edu>
Subject Re: hot deploy / auto assembly design
Date Sun, 08 Jul 2007 19:33:54 GMT

Eric Dalquist wrote:
> 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.

I've had some trouble delineating the responsibilities because you could
simply assemble the portlet to the servlet container's deployment
directory (e.g. /webapps for tomcat).  So the services could be merged I
think.  Whether or not that is a good idea...

Right now in my implementation the PortletDeploymentSerivce depends on
the PortletAssemblyService.  When the deployment service senses a war is
available for deployment, it calls the assembly service first, and then
it deploys the file.

Here's what I have right now:

      * Assembles the portlet war file.
      * <p/>
      * Implementations should be able to detect if the
      * provided file has already been assembled.
      * @param portletWar the portlet war file to assemble
      * @return the assembled war file
      * @throws AssemblyException if the war file cannot be assembled
      public File assemble( File portletWar ) throws AssemblyException;

       * Obtains the Assembler implementation.
       * @return the Assembler implementation
      public Assembler getAssembler();

The container is responsible for the assembly: it provides the Assembler
implementation and actually performs the assembly.  The goal is to have 
the container encapsulate the assembly logic.

     public AssemblerConfig getAssemblerConfig( final File portletWar );

The callback provides the Assembler config: Allowing the portal to set
the dispatch servlet class and the destination of the assembly. 
Probably the AssemblerConfig datastructure is overkill.  Perhaps 
looks like:
     public String getDispatchServletClass( final File portletWar );
and leave the AssemblerConfig and destination out of it (destination is 
part of deployment).  That seems much cleaner.

      * Deploys the portlet war file to the
      * container.
      * @param portletWar the war file to deploy.
     public void deploy( File portletWar, File destDir );

The container is responsible for the actual deployment of the war file, 
and monitoring the hot deploy directory (provided by the callback) for 
changes. Note there's no undeploy method.  Should there be?

      * Obtains the directory to be monitored by the
      * container for hot deployment.  Portlet war
      * files placed into this directory will be
      * assembled and deployed to the servlet container.
      * @return the hot deploy directory
     public File getHotDeployDirectory();

      * Obtains the directory that the portlet
      * war file will be deployed to.
      * @return the directory the war file will be deployed to
     public File getDestinationDirectory();

The callback is responsible for providing the directories to be 
monitored for hot-deployment and the directory that the assembled 
portlet should be deployed to.  The portal is probably in the best 
position to provide this information, depending on what container it is 
using (tomcat, jetty, etc).

Depending on how this goes perhaps a feature branch would be useful.
Before these features make it into a Pluto release, I'd like to
implement them in Sakai and uPortal (2 or 3 depending) and see how they
work out, shaking out any issues with implementation or the interfaces 

What do you think about the interfaces/responsibilities?


View raw message