I'm actually thinking that it's not a new service. . .it's just a new
implementation of the PortletInvokerService (which already exists).
What do you think?
Elliot Metsger wrote:
So the consensus is to provide an optional container service which
drivers can implement, supporting additional war file formats?
The default implementation of the optional service supports the current
version of the container, and drivers can extend the service to support
other formats?
Do I have it?
Thanks,
Elliot
Eric Dalquist wrote:
Yeah, thats what I'm thinking, the container just supports the invoker
for the current version. There is no reason the driver can't provide
an invoker that supports older Pluto assembled WARs or even WARs from
other containers.
-Eric
David H. DeWolf wrote:
Actually, that's a great point. . .couldn't this just be a different
implementation of the PortletInvokerService? One that belongs to the
portal driver. I like that idea.
Eric Dalquist wrote:
Elliot Metsger wrote:
Hi Eric,
Thanks for the feedback - let me just real quick respond here; more
fully formed thoughts to follow -
Eric Dalquist wrote:
I'd like to get my 2 cents in on this.
As much as part of me sees where supporting old pluto 1.0 WARs is
a plus or other random WARs as well.
A larger part of me says the spec says nothing about web.xml
magic, that is container specific and no one should be dealing
with a container specific WAR outside of the webapps (or
equivalent) directory of their container.
I don't think I'm suggesting that we expose any web.xml magic, in
fact I'm trying to encapsulate the 1.0 and 1.1+ magic.
I feel fairly strongly that the deployment process of a portlet
WAR is a portal specific action and something that the Pluto
container should not be concerned with.
So right now the format of a Pluto 1.0 assembled web.xml is tied to
a Pluto 1.0.x container implementation, and similarly Pluto 1.1.0+
assembled wars are tied to the Pluto 1.1.0+ container
implementation. Specifically in 1.1.0+ the PortletEntityImpl and
the PortletServlet have ties in one way or the other to the format
of the assembled web.xml.
I'm suggesting that Pluto 1.1.0+ containers grok Pluto 1.0.x
assembled portlets.
I guess I feel like this isn't very good behavior to encourage. I'm
not sure why people are copying already deployed (assembled)
portlets from one container/portal to another. I really feel like we
should be making people work with Plain Old War Files (POWFs?) as
much as possible and assembled WARs should only exist in the servlet
container.
Now this is much more my view towards the Pluto container, the
driver can do as it pleases. So if supporting the web.xml magic from
other versions of Pluto or other containers is very compelling I
guess I'm wondering if that support is an optional part of the
container. From my uPortal 3 side of things I'd rather tell people
to take their POWFs and run the uPortal deployer task on them to set
them up correctly and copy them to the correct deployed location.
That way I don't have to worry about supporting changes in some
other containers web.xml magic and we encourage people to write
portlets that follow the spec and aren't tied to a specific container.
So, my earlier suggestion about 1.0 invoker support in the driver
could probably be re-written as, please make support for web.xml
magic for anything other than the current version of Pluto optional.
-Eric
What I hear Chuck saying is make the "grokking" extensible/pluggable.
I see making a more pluggable strategy for the invoker but I would
vote for putting the pluto 1.0 invoker support classes in the
pluto driver and not the container.
Since portlet registration and invocation is a container-specific
process, I'm not sure how that would work. I mean, the classes
could go into the driver, but then the container would depend on
the driver which I think would be not good.
Does that help alleviate your concern, or am I just
mis-understanding - which is _entirely_ possible :-)
-Eric
Charles Severance wrote:
Elliott,
I have a similarly non-direct answer :). As a fan of war file
binary compatibility - even if de-facto, I am interested in
having Pluto 1.1 capable of supporting as many binary war formats
as possible - not *in* the Pluto code - but with extension
capabilities in PortletServlet.
Here is my use case... I lets say that a long time ago, I wrote a
JSR-168 container called XYZPortal perhaps from scratch, and made
my own convention for web.xml hacking. So I have my
XYZPortletServlet and some stuff in my web.xml about portlet
classes and servlet URLs.
But I want to drop these wars into a Pluto 1.1.x container with
no modifications to the war. This is what I want to do.
Write a *different* implementation of XYZPortletServlet (perhaps
even one that extends Pluto's Portlet Servlet) - put this
implementaiton up in shared - In this servlet - I look at all my
init parms, paths, etc and *call* stuff in Pluto's PortletServlet
so that these portlets are properly registered with Pluto's
portlet servlet.
My guess is that to write such a "XYXPortletServlet extends
PlutoPortletServlet" would really be quite simple - things like
the paths to servlets might even not matter at all - because the
goal is to register the portlets *into* Pluto 1.1.x - not into
XYZContainer.
So while I have no answer for your basic question - as you cruise
through the code - think about the notion of extending
PortletServlet :)
/Chuck
On Mar 11, 2007, at 11:19 AM, David H. DeWolf wrote:
Elliot,
I have a couple of thoughts, but perhaps not a direct answer:
1) Binding the creation of this to the invoker service makes
absolute sense. In fact, since each invoker implementation will
probably utilizes it's own mechanism and may not requires it, I
don't even think it needs to be exposed within it's interface -
just bound to the impl.
2) While you're at it, you may want to consider the effects of
eventually only requiring ONE servlet to be mapped per PORTLET
APP instead of per PORTLET. This is the reason I changed the
approach in the first place. Having everything map to
/PortletInvoker/PortletName allows us to use a wildcard servlet
mapping of /PortletInvoker/* eventually (or a filter for that
matter, which I think we may need anyways eventually to support
portlet filters.
3) Having a service encapsulate this logic is fine.
PortletInvokerUriResolver seems like a good idea to me.
4) In terms of backwards compatibility, in 1.1.x we should be
binarily compatible for sure. The one areas where I think we
can get away with not being compatible is if we want to extend
the OptionalContainerServices interface. We specifically put a
note in the javadocs that impls should be prepared to support
additional optional services and instead of implementing the
interface directly, they should consider extending the default
impl to ensure future versions do not break binary compatibility.
For 1.2.x I think we may deprecate several things and we have
the option of breaking binary compatibility to some extent.
Whatever we do, we need a very clear and straight forward
migration plan.
Does that help and answer your questions, at least somewhat?
David
Elliot Metsger wrote:
I'm working on support for Pluto 1.0.x portlets in Pluto 1.1.x
and 1.2.x (https://issues.apache.org/jira/browse/PLUTO-325).
Basically, I want a 1.0.x assembled war file to "just work"
with Pluto 1.1.x and above. I don't want people to have to
recompile or munge their 1.0.x web.xml or war files.
As I see it, this involves:
1) mapping the portlet-guid from Pluto 1.0.x web.xml to the
portlet name 2) supporting the Pluto 1.0.x invoker URI.
I have code to commit for this right now (and it works!!!
bonus, right?) but I'm questioning the design for item 2.
Currently the URL used by the DefaultPortletInvokerService is
obtained from the PortletEntity. The PE has the invoker URI
hard-coded. Since I need to support both the 1.0.x and 1.1.0+
invoker URI formats, we need a more pluggable solution. My
thinking is to look up the servlet mapping for the portlet from
the WebAppDD, and get the invoker uri from the servlet mapping.
My question is, where do we plug the functionality in - before
I go committing like a crazy man :)
What I did was have the PortletEntity use a new package-private
PortletInvokerUriResolver class. The advantage of this is that
the PortletEntity interface doesn't change, which is important
for maintaining binary compatibility on the 1.1.x branch.
But I'm wondering if a better, or ultimate, solution is to make
invoker uri resolution the responsibility of the
PortletInvokerService. Makes sense right? If that is the case
then do people agree that one solution is appropriate for 1.1.x
and a second solution is more appropriate for 1.2.x?
Could we - for the 1.2.x solution - remove the
getControllerUri() method from the PortletEntity interface
(what is the policy on binary compat between 1.1.x and 1.2.x,
considering our Java 5 requirement for 1.2.x), and move portlet
invoker uri resolution into the PortletInvokerService?
Thanks for your thoughts,
Elliot
