Design question regarding invoker

[Elliot Metsger <em...@jhu.edu>]

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

Re: Design question regarding invoker

[Eric Dalquist <er...@doit.wisc.edu>]

We just delegate to Pluto but I'd rather people not be concerned with 
what portlet container uPortal is using and just know that they need to 
give uPortal a POWF and the rest is up to uPortal.

-Eric

Elliot Metsger wrote:
>
> hey eric,
>
> questions/comments inline -
>
> Eric Dalquist wrote:
>
>>> 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.
>
> I agree.  But sometimes it is easier to drop the assembled portlet 
> into tomcat.  If, for example, I have already published the channel 
> publishing document to uPortal, it is much easier to just drop the 
> assembled portlet into the webapps directory, without using the uP 
> deployer.  This may not be the recommended way of doing things I'll 
> certainly grant you that...
>
>> 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.
>
> Ok so I'm not saying that uP has to support any web.xml magic.  In the 
> case of a pre-assembled war I wouldn't use the uP deployer at all.
>
>> 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
>
>> 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.
>
> So how involved is uPortal in the assembly of web.xml files?  Does it 
> not just delegate that to Pluto?  Or do you assemble the portlets on 
> your own?
>
> Elliot
>
>
>>
>> -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
>>>>>>
>>>>>>
>>>>>

Re: Design question regarding invoker

[Elliot Metsger <em...@jhu.edu>]

hey eric,

questions/comments inline -

Eric Dalquist wrote:

>> 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.

I agree.  But sometimes it is easier to drop the assembled portlet into 
tomcat.  If, for example, I have already published the channel 
publishing document to uPortal, it is much easier to just drop the 
assembled portlet into the webapps directory, without using the uP 
deployer.  This may not be the recommended way of doing things I'll 
certainly grant you that...

> 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.

Ok so I'm not saying that uP has to support any web.xml magic.  In the 
case of a pre-assembled war I wouldn't use the uP deployer at all.

> 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

> 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.

So how involved is uPortal in the assembly of web.xml files?  Does it 
not just delegate that to Pluto?  Or do you assemble the portlets on 
your own?

Elliot


> 
> -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
>>>>>
>>>>>
>>>>

Re: Design question regarding invoker

[Elliot Metsger <em...@jhu.edu>]

David H. DeWolf wrote:
> 
> Elliot Metsger wrote:
>>> 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.  

Ok.

> 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.

Yes I agree, this makes the most sense, and seems to be one of the 
things the invoker service was designed for anyway.

> 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.

My question is specific to how the PortletServlet gets the portlet name? 
  Maybe I'm missing something.  Will it get it from a service or just 
parse the init-param?  If from a service, I need some help understanding 
which service.  If parsing the init-param, no problem (that's how I have 
  it coded now).

Not trying to be difficult, just trying to understand -

Thanks,

Elliot

> 
> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>
>>

Re: Design question regarding invoker

["David H. DeWolf" <dd...@apache.org>]

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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>
>>>
> 

Re: Design question regarding invoker

[Elliot Metsger <em...@jhu.edu>]

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.

> 
> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>
>>

Re: Design question regarding invoker

["David H. DeWolf" <dd...@apache.org>]

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.

I can't remember, what does the pluto 1.0.x configuration look like. 
It's got to include the portletName somewhere, right?

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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>
> 

Re: Design question regarding invoker

[Elliot Metsger <em...@jhu.edu>]

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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>

Re: Design question regarding invoker

["David H. DeWolf" <dd...@apache.org>]

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
>>>>>>>>
>>>>>>>>
>>>>>>>
> 

Re: Design question regarding invoker

[Elliot Metsger <em...@jhu.edu>]

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
>>>>>>>
>>>>>>>
>>>>>>

Re: Design question regarding invoker

[Eric Dalquist <er...@doit.wisc.edu>]

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
>>>>>>
>>>>>>
>>>>>

Re: Design question regarding invoker

["David H. DeWolf" <dd...@apache.org>]

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
>>>>>
>>>>>
>>>>

Re: Design question regarding invoker

[Eric Dalquist <er...@doit.wisc.edu>]

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
>>>>
>>>>
>>>

Re: Design question regarding invoker

[Elliot Metsger <em...@jhu.edu>]

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.

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
>>>
>>>
>>

Re: Design question regarding invoker

[Eric Dalquist <er...@doit.wisc.edu>]

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 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. 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.

-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
>>
>>
>

Re: Design question regarding invoker

[Charles Severance <cs...@umich.edu>]

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
>
>

Re: Design question regarding invoker

["David H. DeWolf" <dd...@apache.org>]

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
>