[PORTAL] Getting rid of filters

[Scott O'Bryan <da...@gmail.com>]

Hello everyone,

I'm almost done implementing a custom wrapper for the life cycle which 
should allow us to replace a large part of the functionality of our 
filter (the other part being handled by FacesContext wrappers).  I did 
have one question regarding "services" which are referred to in the 
TrinidadFilterImpl object.  It appears, basically, that the 
TrinidadFilterImpl is responsible for kicking off a number of services.  
These "services" use a FilterChains to execute and, as such, are not 
compatible with a portal environment.  Can anyone tell me what these 
"services" might be used for and what guarantees, if any, we make as to 
when they are executed? 

We have several options for handling them including running them only in 
a servlet environment using the filter, but they would not be available 
to portlets.  Also, since the initializations done in the filter would 
happen in the Lifecycle, things may be problematic if we guarantee that 
certain initializations have taken place since the lifecycle does not 
execute until after these services have been run.

Scott

[Question] Trinidad Filter Services [was: Re: [PORTAL] Getting rid of filters]

[Scott O'Bryan <da...@gmail.com>]

Fair enough.  I can certainly make it so that the filter is an 
"optional" component and we can keep the filter code in there.

That being said, are there some specific circumstances today where these 
filter services perform some logic that are needed in portal 
environments.  I do agree that right not the Portlet API does not yet 
allow us the flexibility of the Servlet container so simply eliminating 
the filter may be a bit premature.

For instance:

One of the requirements I heard from Adam was that of setting up skins 
in these filter services.  Perhaps it would be prudent to have a special 
skinning setup api that could reduce our reliance on the filter 
framework and allow for handing of this in a portal environment.

Does anyone else have requirements for these filters that they would 
want addressed in a more generic fashion?

Adam Winer wrote:
> On 11/3/06, Scott O'Bryan <da...@gmail.com> wrote:
>> Then I guess the final question is, is it important if these don't run
>> in the portal.
>>
>> I mean if we can't change the API to be container agnostic and ordering
>> is important, I'm forced to use the Lifecycle/ExternalContext approach
>> for Portlets and the filter approach for servlets.  Not only is this
>> painful and somewhat dirty, but a large chunk of functionality simply
>> won't be available on the portal that, quite possibly, needs to be.
>>
>> I mean I've managed to wrap Request and Response objects in the
>> FacesContext for both the portal and the servlet.  Anything that is
>> dependant on a ServletRequest will automatically not work in a portal.
>>
>> So help me out here.
>
> I'm happy with adding some servlet-agnostic APIs for some
> of the purposes served by the existing filter code.  I'm just saying
> that the goal of 100% no filters, 100% shared code is overly optimistic,
> and that we really, really, really shouldn't just nuke the existing 
> filter
> API.
>
> ExternalContext isn't 100% sufficient.  Ergo, perfect code sharing
> and being totally agnostic to the Servlet API isn't gonna happen.
> Forget about perfection - let's take steps towards making things better.
>
> -- Adam
>
>
>>
>> Scott
>>
>> Adam Winer wrote:
>> > On 11/3/06, Scott O'Bryan <da...@gmail.com> wrote:
>> >> Two questions then:
>> >>
>> >> 1) Being that these won't work in a portal environment, should we 
>> move
>> >> these to be executed elsewhere (like my custom lifecycle object) and
>> >> change the API to be more container agnostic (ie. using the
>> >> ExternalContext)?
>> >
>> > Changing the API is a painful way to go, and given that I've
>> > used it to wrap ServletResponse objects, a purely container agnostic
>> > approach isn't gonna cut it, I assume.
>> >
>> >> 2) If we do need to leave these in the filters, is it okay to move 
>> all
>> >> the other initialization logic (like setting up the skinning and
>> >> whatnot) to execute after these services or does it need to 
>> continue to
>> >> execute in the same order?
>> >
>> > Ordering is very important - one thing I've seen these filters
>> > used for is programatically registering additional skins.  And
>> > that had better happen after the original execution logic!
>> >
>> > -- Adam
>> >
>>
>>
>

Re: Re: [PORTAL] Getting rid of filters

[Adam Winer <aw...@gmail.com>]

On 11/3/06, Scott O'Bryan <da...@gmail.com> wrote:
> Then I guess the final question is, is it important if these don't run
> in the portal.
>
> I mean if we can't change the API to be container agnostic and ordering
> is important, I'm forced to use the Lifecycle/ExternalContext approach
> for Portlets and the filter approach for servlets.  Not only is this
> painful and somewhat dirty, but a large chunk of functionality simply
> won't be available on the portal that, quite possibly, needs to be.
>
> I mean I've managed to wrap Request and Response objects in the
> FacesContext for both the portal and the servlet.  Anything that is
> dependant on a ServletRequest will automatically not work in a portal.
>
> So help me out here.

I'm happy with adding some servlet-agnostic APIs for some
of the purposes served by the existing filter code.  I'm just saying
that the goal of 100% no filters, 100% shared code is overly optimistic,
and that we really, really, really shouldn't just nuke the existing filter
API.

ExternalContext isn't 100% sufficient.  Ergo, perfect code sharing
and being totally agnostic to the Servlet API isn't gonna happen.
Forget about perfection - let's take steps towards making things better.

-- Adam


>
> Scott
>
> Adam Winer wrote:
> > On 11/3/06, Scott O'Bryan <da...@gmail.com> wrote:
> >> Two questions then:
> >>
> >> 1) Being that these won't work in a portal environment, should we move
> >> these to be executed elsewhere (like my custom lifecycle object) and
> >> change the API to be more container agnostic (ie. using the
> >> ExternalContext)?
> >
> > Changing the API is a painful way to go, and given that I've
> > used it to wrap ServletResponse objects, a purely container agnostic
> > approach isn't gonna cut it, I assume.
> >
> >> 2) If we do need to leave these in the filters, is it okay to move all
> >> the other initialization logic (like setting up the skinning and
> >> whatnot) to execute after these services or does it need to continue to
> >> execute in the same order?
> >
> > Ordering is very important - one thing I've seen these filters
> > used for is programatically registering additional skins.  And
> > that had better happen after the original execution logic!
> >
> > -- Adam
> >
>
>

Re: [PORTAL] Getting rid of filters

[Scott O'Bryan <da...@gmail.com>]

Then I guess the final question is, is it important if these don't run 
in the portal.

I mean if we can't change the API to be container agnostic and ordering 
is important, I'm forced to use the Lifecycle/ExternalContext approach 
for Portlets and the filter approach for servlets.  Not only is this 
painful and somewhat dirty, but a large chunk of functionality simply 
won't be available on the portal that, quite possibly, needs to be.

I mean I've managed to wrap Request and Response objects in the 
FacesContext for both the portal and the servlet.  Anything that is 
dependant on a ServletRequest will automatically not work in a portal.

So help me out here.

Scott

Adam Winer wrote:
> On 11/3/06, Scott O'Bryan <da...@gmail.com> wrote:
>> Two questions then:
>>
>> 1) Being that these won't work in a portal environment, should we move
>> these to be executed elsewhere (like my custom lifecycle object) and
>> change the API to be more container agnostic (ie. using the
>> ExternalContext)?
>
> Changing the API is a painful way to go, and given that I've
> used it to wrap ServletResponse objects, a purely container agnostic
> approach isn't gonna cut it, I assume.
>
>> 2) If we do need to leave these in the filters, is it okay to move all
>> the other initialization logic (like setting up the skinning and
>> whatnot) to execute after these services or does it need to continue to
>> execute in the same order?
>
> Ordering is very important - one thing I've seen these filters
> used for is programatically registering additional skins.  And
> that had better happen after the original execution logic!
>
> -- Adam
>

Re: Re: [PORTAL] Getting rid of filters

[Adam Winer <aw...@gmail.com>]

On 11/3/06, Scott O'Bryan <da...@gmail.com> wrote:
> Two questions then:
>
> 1) Being that these won't work in a portal environment, should we move
> these to be executed elsewhere (like my custom lifecycle object) and
> change the API to be more container agnostic (ie. using the
> ExternalContext)?

Changing the API is a painful way to go, and given that I've
used it to wrap ServletResponse objects, a purely container agnostic
approach isn't gonna cut it, I assume.

> 2) If we do need to leave these in the filters, is it okay to move all
> the other initialization logic (like setting up the skinning and
> whatnot) to execute after these services or does it need to continue to
> execute in the same order?

Ordering is very important - one thing I've seen these filters
used for is programatically registering additional skins.  And
that had better happen after the original execution logic!

-- Adam

>
> Scott
>
> Adam Winer wrote:
> > On 11/3/06, Scott O'Bryan <da...@gmail.com> wrote:
> >>
> >> Hello everyone,
> >>
> >> I'm almost done implementing a custom wrapper for the life cycle which
> >> should allow us to replace a large part of the functionality of our
> >> filter (the other part being handled by FacesContext wrappers).  I did
> >> have one question regarding "services" which are referred to in the
> >> TrinidadFilterImpl object.  It appears, basically, that the
> >> TrinidadFilterImpl is responsible for kicking off a number of services.
> >> These "services" use a FilterChains to execute and, as such, are not
> >> compatible with a portal environment.  Can anyone tell me what these
> >> "services" might be used for and what guarantees, if any, we make as to
> >> when they are executed?
> >
> >
> > They can be used for anything that a Filter can be used for.  I've used
> > them for initialization;  also, for wrapping of servlet objects.
> >
> > -- Adam
> >
>
>

Re: [PORTAL] Getting rid of filters

[Scott O'Bryan <da...@gmail.com>]

Oh yeah, and I'm moving wrapping of servlet objects out of the filters 
and into the ExternalContext.  That does not mean we can't wrap them in 
filters as well, but everytime we do, those filters will not run in a 
portal.

Scott

Scott O'Bryan wrote:
> Two questions then:
>
> 1) Being that these won't work in a portal environment, should we move 
> these to be executed elsewhere (like my custom lifecycle object) and 
> change the API to be more container agnostic (ie. using the 
> ExternalContext)?
>
> 2) If we do need to leave these in the filters, is it okay to move all 
> the other initialization logic (like setting up the skinning and 
> whatnot) to execute after these services or does it need to continue 
> to execute in the same order?
>
> Scott
>
> Adam Winer wrote:
>> On 11/3/06, Scott O'Bryan <da...@gmail.com> wrote:
>>>
>>> Hello everyone,
>>>
>>> I'm almost done implementing a custom wrapper for the life cycle which
>>> should allow us to replace a large part of the functionality of our
>>> filter (the other part being handled by FacesContext wrappers).  I did
>>> have one question regarding "services" which are referred to in the
>>> TrinidadFilterImpl object.  It appears, basically, that the
>>> TrinidadFilterImpl is responsible for kicking off a number of services.
>>> These "services" use a FilterChains to execute and, as such, are not
>>> compatible with a portal environment.  Can anyone tell me what these
>>> "services" might be used for and what guarantees, if any, we make as to
>>> when they are executed?
>>
>>
>> They can be used for anything that a Filter can be used for.  I've used
>> them for initialization;  also, for wrapping of servlet objects.
>>
>> -- Adam
>>
>
>

Re: [PORTAL] Getting rid of filters

[Scott O'Bryan <da...@gmail.com>]

Two questions then:

1) Being that these won't work in a portal environment, should we move 
these to be executed elsewhere (like my custom lifecycle object) and 
change the API to be more container agnostic (ie. using the 
ExternalContext)?

2) If we do need to leave these in the filters, is it okay to move all 
the other initialization logic (like setting up the skinning and 
whatnot) to execute after these services or does it need to continue to 
execute in the same order?

Scott

Adam Winer wrote:
> On 11/3/06, Scott O'Bryan <da...@gmail.com> wrote:
>>
>> Hello everyone,
>>
>> I'm almost done implementing a custom wrapper for the life cycle which
>> should allow us to replace a large part of the functionality of our
>> filter (the other part being handled by FacesContext wrappers).  I did
>> have one question regarding "services" which are referred to in the
>> TrinidadFilterImpl object.  It appears, basically, that the
>> TrinidadFilterImpl is responsible for kicking off a number of services.
>> These "services" use a FilterChains to execute and, as such, are not
>> compatible with a portal environment.  Can anyone tell me what these
>> "services" might be used for and what guarantees, if any, we make as to
>> when they are executed?
>
>
> They can be used for anything that a Filter can be used for.  I've used
> them for initialization;  also, for wrapping of servlet objects.
>
> -- Adam
>

Re: [PORTAL] Getting rid of filters

[Adam Winer <aw...@gmail.com>]

On 11/3/06, Scott O'Bryan <da...@gmail.com> wrote:
>
> Hello everyone,
>
> I'm almost done implementing a custom wrapper for the life cycle which
> should allow us to replace a large part of the functionality of our
> filter (the other part being handled by FacesContext wrappers).  I did
> have one question regarding "services" which are referred to in the
> TrinidadFilterImpl object.  It appears, basically, that the
> TrinidadFilterImpl is responsible for kicking off a number of services.
> These "services" use a FilterChains to execute and, as such, are not
> compatible with a portal environment.  Can anyone tell me what these
> "services" might be used for and what guarantees, if any, we make as to
> when they are executed?


They can be used for anything that a Filter can be used for.  I've used
them for initialization;  also, for wrapping of servlet objects.

-- Adam



We have several options for handling them including running them only in
> a servlet environment using the filter, but they would not be available
> to portlets.  Also, since the initializations done in the filter would
> happen in the Lifecycle, things may be problematic if we guarantee that
> certain initializations have taken place since the lifecycle does not
> execute until after these services have been run.
>
> Scott
>