Elliot Metsger wrote:
David H. DeWolf wrote:
Auto registration only requires the servlet config. the entire
portlet app is registered at the same (initial) time. Subsequent
initialization attempts due to other portlets are ignored. So --- i
don't think it needs it for auto-reg, perhaps only for obtaining it's
portletConfig.
Right, my bad - it isn't needed for auto-reg, it is for obtaining
portletConfig in the init() method. The portletConfig is later set as a
request attribute in the dispatch method.
I can't remember, what does the pluto 1.0.x configuration look like.
It's got to include the portletName somewhere, right?
It does, in the portlet-guid init parameter. But based on this thread I
thought that people don't want explicit support for older versions of
assembled portlets in the container.
No, actually, I LIKE the idea of supporting them in the portal driver,
and don't really have any opinion about whether or not this should be
baked into the container, but I can see Eric's point. My thought was
that since we already have a pluggable service (PortletInvokerService)
that supports this, why not just leverage it and keep the logic out of
the container for now.
So, in other words, I would create an optional portal driver service
which can be injected into the container to provide backwards compatible
support if wanted/desired. This service would probably extend our
existing DefaultPortletInvokerService and use the portlet-guid init
parameter for those requests that were identified as "legacy" requests.
David
David
Elliot Metsger wrote:
David H. DeWolf wrote:
I'm actually thinking that it's not a new service. . .it's just a
new implementation of the PortletInvokerService (which already exists).
Right, everything already exists :-)
Question: how will the PortletServlet get the portlet name to support
auto-registration? Do we add a getPortletName method to the
PortletInfoService?
What do you think?
Sounds good!
E
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
