incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <>
Subject Re: [Jira] Portlet Issue
Date Tue, 10 Oct 2006 20:13:24 GMT
To answer Mitthias, I'm going to be testing against Pluto and Oracle's 
WSRP.  I *MAY* add Gridsphere to the test since it's Websphere like.

Now, Arash, you are replying to a different issue.  I noticed that 
Tomahawk has added support for PortletFilters and I guess I jumped the 
gun on wanting to use it.  By removing dependencies on the "wapper" 
objects in the filters, we can remove any dependency we have on the 
implementation of the particular portal for now.  Perhaps we may even 
have to depend on our own bridge portlet which (like tomahawk) is 
derived off of the MyFaces Bridge.  The things that concerns me is that 
never will the two run together in a portal environment if we do this.

I have a requirement to allow this stuff to run in a WSRP container 
which is more like type 2 of your scenario.  Therefore, I am flat 
against using an implied implementation (like taking advantage of the 
fact that WebSphere wraps httpServletRequest/Response objects.  I 
*don't* mind providing an interface with various adapters (for each 
portal maybe) that could implement these wrapper objects as hopefully 
well have something similar in the spec in a year or so.

That being said, while LifeRay is not of the first type you recomended, 
someone familiar with the system should be able to provide a wrapper 
object for LifeRay's PortletRequest implementation object.


Arash Rajaeeyan wrote:
> there two kind of portals
> some use Servlet classes as a base for Portlet and other Portlet Classes,
> and subclasses classes like PortletRequest from HttpServletRequest.
> some develop Portlet classes from scratch.
> lots of problems arise in second type of portlet API implementation which
> the Portlet classes can not be casted to Servlet classes.
> IBM websphere is from first kind.
> Liferay is second type.
> pluto is some thing between:
>  package org.apache.pluto.internal.impl;
>  ....
>  public abstract class PortletRequestImpl extends 
> HttpServletRequestWrapper
>  implements PortletRequest, InternalPortletRequest {
>  ....
> as you see they have subclasses HttpServletRequestWrapper
> so they have all methods of HttpServlet
> so I think its better that we don't test portlet patch implementation on
> pluto.
> On 10/10/06, Matthias Wessendorf <> wrote:
>> Scott,
>> testing against Pluto (Portlet RI)?
>> -M
>> On 10/10/06, Scott O'Bryan <> wrote:
>> > I added seven issues to the Trinidad Portlet component in Jira and one
>> > to the MyFaces Portlet_Support component.  That should get us started.
>> > We'll have to have MYFACES-1448, MYFACES-1383, and ADFFACES-234 done
>> > before we can start, however.
>> >
>> > I do have a fix for MYFACES-1383, but it needs some testing.  
>> Hopefully
>> > I'll be able to check it in soon.
>> >
>> > Scott
>> >
>> -- 
>> Matthias Wessendorf
>> further stuff:
>> blog:
>> mail: mwessendorf-at-gmail-dot-com

View raw message