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
