You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Scott O'Bryan <da...@gmail.com> on 2006/10/10 18:43:19 UTC
[Jira] Portlet Issue
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
Re: [Jira] Portlet Issue
Posted by Scott O'Bryan <da...@gmail.com>.
Correct. I mean it's crappy that we have to go through like 20 layers
of wrappers to make this thing work right. I imagine, though, that it's
going to be that way until the next Portlet Spec. Same way with Ajax.
The new Portlet spec is going to have a request type specifically for Ajax.
Arash Rajaeeyan wrote:
> Hi
>
> yes it makes sense.
>
> you know the problem is Protlet is more limited than servlet
> so some Portlet Classes (say PortletRequest) have less methods and
> properties than their counter part (say HttpServlet)
> so the wrapper which implements Servlet class and has wrapped a portlet
> related class inside should return null or throw exception in some
> special
> cases.
>
> so these wrappers behaviour is not completely same as their http servlet
> counter parts.
>
> I don't know if this functionality are used any where in trinidad or not.
> as long as I find out in the codes there is no dependency on HttpServlet
> classes
> and in most places the JSF classes are used in trinidad.
> for example in most places FacesContext is used and not ServletContext so
> there is no problem in returning PortletContext in getFacesContext
>
Re: [Jira] Portlet Issue
Posted by Arash Rajaeeyan <ar...@gmail.com>.
Hi
yes it makes sense.
you know the problem is Protlet is more limited than servlet
so some Portlet Classes (say PortletRequest) have less methods and
properties than their counter part (say HttpServlet)
so the wrapper which implements Servlet class and has wrapped a portlet
related class inside should return null or throw exception in some special
cases.
so these wrappers behaviour is not completely same as their http servlet
counter parts.
I don't know if this functionality are used any where in trinidad or not.
as long as I find out in the codes there is no dependency on HttpServlet
classes
and in most places the JSF classes are used in trinidad.
for example in most places FacesContext is used and not ServletContext so
there is no problem in returning PortletContext in getFacesContext
On 10/11/06, Scott O'Bryan <da...@gmail.com> wrote:
>
> Yeah, that was my origonal thought. I'll reopen MYFACES-1448 which is a
> task to do just that. All we need is something simple to do the
> "Non-Wrapper" initialization code. It would need an "init" and a
> "destroy" as well as a pre-lifecycle and post-lifecycle call, but these
> could be done with the PortletContext, PortletRequest/Response classes.
>
> As for the wrappers, you get me wrong. I'm not wanting to tie myself to
> HttpServlet stuff at all. Here is my theory about moving the
> "functionality" of the wrapper objects to our existing ExternalContext
> wrapper.
>
> If we have an HttpServletRequest/Response then we can simply use the
> provided wrapper objects. If we don't then we would need to get the
> original request object and ExternalContext and wrap them overriding
> only the functionality we need to. The wrapped external context would
> return a wrapped PortletRequest/PortletResponse/PortletContext object of
> the appropriate (Action or Render) type. For dispatching your wrapper
> simply need to take the provided object's "wrapped" object and pass it
> into the superclass. Therefore, the external context references a
> wrapped PortletRequest and Response as well as it's underlying
> implementation. We'd have to be a bit careful when the objects switch
> from ActionRequests to RenderRequests, but this should be pretty easy to
> do. This would allow us to create wrapper objects without actually
> having them supported by JSR-168 or the need to cast to HttpServlet stuff.
>
> Does this make sense?
>
>
>
>
> Arash Rajaeeyan wrote:
> > Hi scott,
> >
> > my post was generally about portlet support.
> >
> > you are right the second type method can be fixed by a wrapper which
> > implements HttpServlet and wraps Portlet.
> >
> > I prefer to use a method which works in all portals JSR168, or WSRP
> > and even
> > in future JSR 286, if some solution works for second type (Not Drived
> > Classes from HttpServlet) of portals it will work for first type (Drived
> > Portlet classes from HttpServlet)
> >
> > I will test every thing with both kind of portals to make sure they both
> > work fine.
> >
> > may be we can modify that "MyFaces Bridge" and add what ever we need to
> > support trinidad.
> > trindidad and tomahawk are both under myfaces, and many people including
> > myself are using both set of components.
> >
> >
> > On 10/10/06, Scott O'Bryan <da...@gmail.com> wrote:
> >>
> >> 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.
> >>
> >> Scott
> >>
> >> 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 <ma...@apache.org> wrote:
> >> >>
> >> >> Scott,
> >> >>
> >> >> testing against Pluto (Portlet RI)?
> >> >>
> >> >> -M
> >> >>
> >> >> On 10/10/06, Scott O'Bryan <da...@gmail.com> 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
> >> >> http://tinyurl.com/fmywh
> >> >>
> >> >> further stuff:
> >> >> blog: http://jroller.com/page/mwessendorf
> >> >> mail: mwessendorf-at-gmail-dot-com
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>
>
--
Arash Rajaeeyan
Re: [Jira] Portlet Issue
Posted by Scott O'Bryan <da...@gmail.com>.
Yeah, that was my origonal thought. I'll reopen MYFACES-1448 which is a
task to do just that. All we need is something simple to do the
"Non-Wrapper" initialization code. It would need an "init" and a
"destroy" as well as a pre-lifecycle and post-lifecycle call, but these
could be done with the PortletContext, PortletRequest/Response classes.
As for the wrappers, you get me wrong. I'm not wanting to tie myself to
HttpServlet stuff at all. Here is my theory about moving the
"functionality" of the wrapper objects to our existing ExternalContext
wrapper.
If we have an HttpServletRequest/Response then we can simply use the
provided wrapper objects. If we don't then we would need to get the
original request object and ExternalContext and wrap them overriding
only the functionality we need to. The wrapped external context would
return a wrapped PortletRequest/PortletResponse/PortletContext object of
the appropriate (Action or Render) type. For dispatching your wrapper
simply need to take the provided object's "wrapped" object and pass it
into the superclass. Therefore, the external context references a
wrapped PortletRequest and Response as well as it's underlying
implementation. We'd have to be a bit careful when the objects switch
from ActionRequests to RenderRequests, but this should be pretty easy to
do. This would allow us to create wrapper objects without actually
having them supported by JSR-168 or the need to cast to HttpServlet stuff.
Does this make sense?
Arash Rajaeeyan wrote:
> Hi scott,
>
> my post was generally about portlet support.
>
> you are right the second type method can be fixed by a wrapper which
> implements HttpServlet and wraps Portlet.
>
> I prefer to use a method which works in all portals JSR168, or WSRP
> and even
> in future JSR 286, if some solution works for second type (Not Drived
> Classes from HttpServlet) of portals it will work for first type (Drived
> Portlet classes from HttpServlet)
>
> I will test every thing with both kind of portals to make sure they both
> work fine.
>
> may be we can modify that "MyFaces Bridge" and add what ever we need to
> support trinidad.
> trindidad and tomahawk are both under myfaces, and many people including
> myself are using both set of components.
>
>
> On 10/10/06, Scott O'Bryan <da...@gmail.com> wrote:
>>
>> 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.
>>
>> Scott
>>
>> 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 <ma...@apache.org> wrote:
>> >>
>> >> Scott,
>> >>
>> >> testing against Pluto (Portlet RI)?
>> >>
>> >> -M
>> >>
>> >> On 10/10/06, Scott O'Bryan <da...@gmail.com> 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
>> >> http://tinyurl.com/fmywh
>> >>
>> >> further stuff:
>> >> blog: http://jroller.com/page/mwessendorf
>> >> mail: mwessendorf-at-gmail-dot-com
>> >>
>> >
>> >
>> >
>>
>>
>
>
Re: [Jira] Portlet Issue
Posted by Arash Rajaeeyan <ar...@gmail.com>.
Hi scott,
my post was generally about portlet support.
you are right the second type method can be fixed by a wrapper which
implements HttpServlet and wraps Portlet.
I prefer to use a method which works in all portals JSR168, or WSRP and even
in future JSR 286, if some solution works for second type (Not Drived
Classes from HttpServlet) of portals it will work for first type (Drived
Portlet classes from HttpServlet)
I will test every thing with both kind of portals to make sure they both
work fine.
may be we can modify that "MyFaces Bridge" and add what ever we need to
support trinidad.
trindidad and tomahawk are both under myfaces, and many people including
myself are using both set of components.
On 10/10/06, Scott O'Bryan <da...@gmail.com> wrote:
>
> 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.
>
> Scott
>
> 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 <ma...@apache.org> wrote:
> >>
> >> Scott,
> >>
> >> testing against Pluto (Portlet RI)?
> >>
> >> -M
> >>
> >> On 10/10/06, Scott O'Bryan <da...@gmail.com> 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
> >> http://tinyurl.com/fmywh
> >>
> >> further stuff:
> >> blog: http://jroller.com/page/mwessendorf
> >> mail: mwessendorf-at-gmail-dot-com
> >>
> >
> >
> >
>
>
--
Arash Rajaeeyan
Re: [Jira] Portlet Issue
Posted by Scott O'Bryan <da...@gmail.com>.
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.
Scott
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 <ma...@apache.org> wrote:
>>
>> Scott,
>>
>> testing against Pluto (Portlet RI)?
>>
>> -M
>>
>> On 10/10/06, Scott O'Bryan <da...@gmail.com> 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
>> http://tinyurl.com/fmywh
>>
>> further stuff:
>> blog: http://jroller.com/page/mwessendorf
>> mail: mwessendorf-at-gmail-dot-com
>>
>
>
>
Re: [Jira] Portlet Issue
Posted by Arash Rajaeeyan <ar...@gmail.com>.
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 <ma...@apache.org> wrote:
>
> Scott,
>
> testing against Pluto (Portlet RI)?
>
> -M
>
> On 10/10/06, Scott O'Bryan <da...@gmail.com> 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
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
--
Arash Rajaeeyan
Re: [Jira] Portlet Issue
Posted by Matthias Wessendorf <ma...@apache.org>.
Scott,
testing against Pluto (Portlet RI)?
-M
On 10/10/06, Scott O'Bryan <da...@gmail.com> 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
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [Jira] Portlet Issue
Posted by Scott O'Bryan <da...@gmail.com>.
Or submit it soon rather.
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
>