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
