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
