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
