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 <[EMAIL PROTECTED]> 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
