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.
Sure, let me back up and expound on Eric's reply.
To deploy a portlet in a Pluto 1.1 based portal, there are three steps:
1) Assembly of the portlet war file - the container-specific munging of
web.xml and subsequent packaging into a war.
2) Deployment of the portlet war file to the portal - currently done by
plopping the assembled war into /webapps.
3) Registration of the portlet war with the container - currently
automated by PortletServlet's init() - this is what you're referring to
above.
So in short I'm proposing to put code into the Pluto container to
automate items 1) and 2). The idea is that the developer packages up
the portlet into a war, with _no Pluto information in web.xml_. Places
this war into a specific directory on the filesystem (either by copying
it or uploading it via an admin tool). Pluto monitors the directory,
and when it senses a war has been added, it will perform steps 1) and 2)
programatically: the war is assembled and then deployed to the servlet
container with no intervention by the developer/administrator.
None of this would prevent the current way of doing things: placing a
manually assembled war file into /webapps. My position is that there is
a better way to do assembly and deployment: better for the portlet
developer, and better for the portlet container, and better for the
portlet community at large.
Right now assembly is performed manually by the developer (either by vi
or by Maven or Ant mechanisms), and this has a couple consequences:
1) Pluto-specific internals are exposed, and so Pluto container must
(should?) support older web.xml formats as the container evolves. The
reality is that right now this burden is being borne by the portlet
developer when it should be borne by the container (IMO).
2) Portlet wars are being packaged and distributed with pluto-specific
elements, reducing portability.
3) And then there is the headache that new portlet developers encounter:
the idea of assembly - some manual steps taken during packaging - is
foreign.
Does this explanation help? Are these features worth cycles? Etc etc.
Elliot
