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
