You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Elliot Metsger <em...@jhu.edu> on 2007/07/07 19:27:53 UTC
hot deploy / auto assembly design
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
Re: hot deploy / auto assembly design
Posted by Elliot Metsger <em...@jhu.edu>.
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:
PortletAssemblyService:
/**
* 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.
PortletAssemblyCallback:
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
PortletAssemblyCallback
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.
PortletDeploymentService
/**
* 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?
PortletDeploymentCallback
/**
* 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
themselves.
What do you think about the interfaces/responsibilities?
Elliot
Re: hot deploy / auto assembly design
Posted by Eric Dalquist <er...@doit.wisc.edu>.
I think this is a great idea.
This is one of those things that every portal that uses pluto will
eventually like to do and having everyone write their own is just dumb.
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.
-Eric
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
Re: hot deploy / auto assembly design
Posted by Christian Raschka <ch...@informatik.uni-jena.de>.
This sounds really good to me. That's it, what i was looking for, as i
was starting with pluto. It'll be a big help for all the people working
with pluto and developing portlets.
Another big point is, as elliot already said, that portlet wars
shouldn't be pluto specific. That's IMHO against the idea of
standardisation of JSR 168 compatible portlets. - Develope a portlet,
package it as a war, test it with pluto, and take it to the portal of
your choice without changing anything.
Christian
Elliot Metsger wrote:
>
>
> 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
Re: hot deploy / auto assembly design
Posted by Elliot Metsger <em...@jhu.edu>.
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
Re: hot deploy / auto assembly design
Posted by Eric Dalquist <er...@doit.wisc.edu>.
The PermGen issue is due to how classloaders work in Java and that each
webapp gets its own classloader in Tomcat. I can't find the specific
issue right now but I believe it is an issue with there not being a way
to unload all loaded classes when shutting down the old webapp instance.
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
> csev@umich.edu 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
>>
>>
>
Re: hot deploy / auto assembly design
Posted by Charles Severance <cs...@umich.edu>.
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
csev@umich.edu 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
>
>
Re: hot deploy / auto assembly design
Posted by Elliot Metsger <em...@jhu.edu>.
David H. DeWolf wrote:
> Cool. . .one more thing I'm against:
>
> - Any tomcat/app server specific logic. I think there's been some
> creeping again lately, it was too much of a pain to weed it out the
> first time. We really need to be on guard with this type of thing.
I agree. That is the purpose of the callbacks, in part. To do any
application server specific logic (I should have put that in my response
to Eric's post).
Look, one result of this is that we do a feature branch (or wherever
general@ wants the code to go) and it doesn't meet these requirements.
So some cycles got spent (my cycles so far) and didn't result in the
feature being implemented. Wouldn't be the first time :-)
Elliot
>
> David
>
> Elliot Metsger wrote:
>> I hear your concerns David, so I'll start a thread on general?
>>
>> My overall concern and itch I'm scratching is:
>>
>>> 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.
>>
>> If Pluto isn't the place do to this that's cool with me, I believe
>> however that these are real issues to be addressed. So we can flesh
>> this out on general?
>>
>> Elliot
>>
>> David H. DeWolf wrote:
>>> The last thing in the world I want to do is poo-poo the great
>>> progress that has been made in our community lately. That said,
>>> while I think these additions sounds great, the pmc (at least in the
>>> past) has been fundamentally against the idea of expanding pluto
>>> beyond the container scope. Between this addition, functionality
>>> recently added to the administration portlets, etc. . ., I think
>>> pluto is becoming more and more portal like. We need to remember our
>>> mission (http://portals.apache.org/pluto/mission.html) is to first
>>> and foremost to be a container.
>>>
>>> Before we proceed, I'd like to make sure that we give the portals
>>> folks that don't consistently monitor this list a chance to chime in
>>> to this discussion. The PMC has recently been working very hard to
>>> bring our communities together as the single project we are supposed
>>> to be. We need to make sure that our efforts align with that of the
>>> pmc, jetspeed ,bridges, and wsrp4j communities.
>>>
>>> If the decision is made to add this functionality, we need to make
>>> sure it is factored in a way in which it does not confuse the portlet
>>> spec RI. In other words, it should be in the portal (not container),
>>> and clearly marked as optional. Given those conditions, I'm behind
>>> the efforts and would like to help out.
>>>
>>> David
>>>
>>> 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
>>>>
>>
Re: hot deploy / auto assembly design
Posted by "David H. DeWolf" <dd...@apache.org>.
Cool. . .one more thing I'm against:
- Any tomcat/app server specific logic. I think there's been some
creeping again lately, it was too much of a pain to weed it out the
first time. We really need to be on guard with this type of thing.
David
Elliot Metsger wrote:
> I hear your concerns David, so I'll start a thread on general?
>
> My overall concern and itch I'm scratching is:
>
>> 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.
>
> If Pluto isn't the place do to this that's cool with me, I believe
> however that these are real issues to be addressed. So we can flesh
> this out on general?
>
> Elliot
>
> David H. DeWolf wrote:
>> The last thing in the world I want to do is poo-poo the great progress
>> that has been made in our community lately. That said, while I think
>> these additions sounds great, the pmc (at least in the past) has been
>> fundamentally against the idea of expanding pluto beyond the container
>> scope. Between this addition, functionality recently added to the
>> administration portlets, etc. . ., I think pluto is becoming more and
>> more portal like. We need to remember our mission
>> (http://portals.apache.org/pluto/mission.html) is to first and
>> foremost to be a container.
>>
>> Before we proceed, I'd like to make sure that we give the portals
>> folks that don't consistently monitor this list a chance to chime in
>> to this discussion. The PMC has recently been working very hard to
>> bring our communities together as the single project we are supposed
>> to be. We need to make sure that our efforts align with that of the
>> pmc, jetspeed ,bridges, and wsrp4j communities.
>>
>> If the decision is made to add this functionality, we need to make
>> sure it is factored in a way in which it does not confuse the portlet
>> spec RI. In other words, it should be in the portal (not container),
>> and clearly marked as optional. Given those conditions, I'm behind
>> the efforts and would like to help out.
>>
>> David
>>
>> 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
>>>
>
Re: hot deploy / auto assembly design
Posted by "David H. DeWolf" <dd...@apache.org>.
Cool. . .one more thing I'm against:
- Any tomcat/app server specific logic. I think there's been some
creeping again lately, it was too much of a pain to weed it out the
first time. We really need to be on guard with this type of thing.
David
Elliot Metsger wrote:
> I hear your concerns David, so I'll start a thread on general?
>
> My overall concern and itch I'm scratching is:
>
>> 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.
>
> If Pluto isn't the place do to this that's cool with me, I believe
> however that these are real issues to be addressed. So we can flesh
> this out on general?
>
> Elliot
>
> David H. DeWolf wrote:
>> The last thing in the world I want to do is poo-poo the great progress
>> that has been made in our community lately. That said, while I think
>> these additions sounds great, the pmc (at least in the past) has been
>> fundamentally against the idea of expanding pluto beyond the container
>> scope. Between this addition, functionality recently added to the
>> administration portlets, etc. . ., I think pluto is becoming more and
>> more portal like. We need to remember our mission
>> (http://portals.apache.org/pluto/mission.html) is to first and
>> foremost to be a container.
>>
>> Before we proceed, I'd like to make sure that we give the portals
>> folks that don't consistently monitor this list a chance to chime in
>> to this discussion. The PMC has recently been working very hard to
>> bring our communities together as the single project we are supposed
>> to be. We need to make sure that our efforts align with that of the
>> pmc, jetspeed ,bridges, and wsrp4j communities.
>>
>> If the decision is made to add this functionality, we need to make
>> sure it is factored in a way in which it does not confuse the portlet
>> spec RI. In other words, it should be in the portal (not container),
>> and clearly marked as optional. Given those conditions, I'm behind
>> the efforts and would like to help out.
>>
>> David
>>
>> 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
>>>
>
Re: hot deploy / auto assembly design
Posted by Elliot Metsger <em...@jhu.edu>.
I hear your concerns David, so I'll start a thread on general?
My overall concern and itch I'm scratching is:
> 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.
If Pluto isn't the place do to this that's cool with me, I believe
however that these are real issues to be addressed. So we can flesh
this out on general?
Elliot
David H. DeWolf wrote:
> The last thing in the world I want to do is poo-poo the great progress
> that has been made in our community lately. That said, while I think
> these additions sounds great, the pmc (at least in the past) has been
> fundamentally against the idea of expanding pluto beyond the container
> scope. Between this addition, functionality recently added to the
> administration portlets, etc. . ., I think pluto is becoming more and
> more portal like. We need to remember our mission
> (http://portals.apache.org/pluto/mission.html) is to first and foremost
> to be a container.
>
> Before we proceed, I'd like to make sure that we give the portals folks
> that don't consistently monitor this list a chance to chime in to this
> discussion. The PMC has recently been working very hard to bring our
> communities together as the single project we are supposed to be. We
> need to make sure that our efforts align with that of the pmc, jetspeed
> ,bridges, and wsrp4j communities.
>
> If the decision is made to add this functionality, we need to make sure
> it is factored in a way in which it does not confuse the portlet spec
> RI. In other words, it should be in the portal (not container), and
> clearly marked as optional. Given those conditions, I'm behind the
> efforts and would like to help out.
>
> David
>
> 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
>>
Re: hot deploy / auto assembly design
Posted by "David H. DeWolf" <dd...@apache.org>.
The last thing in the world I want to do is poo-poo the great progress
that has been made in our community lately. That said, while I think
these additions sounds great, the pmc (at least in the past) has been
fundamentally against the idea of expanding pluto beyond the container
scope. Between this addition, functionality recently added to the
administration portlets, etc. . ., I think pluto is becoming more and
more portal like. We need to remember our mission
(http://portals.apache.org/pluto/mission.html) is to first and foremost
to be a container.
Before we proceed, I'd like to make sure that we give the portals folks
that don't consistently monitor this list a chance to chime in to this
discussion. The PMC has recently been working very hard to bring our
communities together as the single project we are supposed to be. We
need to make sure that our efforts align with that of the pmc, jetspeed
,bridges, and wsrp4j communities.
If the decision is made to add this functionality, we need to make sure
it is factored in a way in which it does not confuse the portlet spec
RI. In other words, it should be in the portal (not container), and
clearly marked as optional. Given those conditions, I'm behind the
efforts and would like to help out.
David
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
>