No, it's not just "backwards compatibility"; the point
is that it is perfectly acceptable for a developer to write
a servlet filter. Just because you or I may want to
require portlet support doesn't mean everyone does,
or that everyone on the planet should stop using servlet
filters. So, we should support those that want to write
servlet filters to the extent that it's feasible, or those
that want to integrate pre-existing filters to the extent
that it's feasible. Which it is, as best I can see.
True, and it does. Doesn't change the fact that this needs to be
supported but inside and outside of the filters. My point about
backward compatibility was simple, we could allow execution of filter
services without needing to do things like handle the multi-part form
request. The reason the filter needs to do it is because it was done
before. Going forward, things that are put into services within the
Trinidad main line "can and should" be done with the configurator. This
means that going forward the "filter" developer is not guarenteed to
have any of these additional wrappers run by the time the filter is run.
I was NOT referring to the fact that filter services themselves were
there to maintain backward compatibility. Going forward we're going to
continue to need this functionality certainly. I'm just saying that
applying the wrappers within trinidad are specifically for this purpose
and going forward we won't need to apply them in both places.
In FileUploadConfiguratorImpl you added a fixme that we should clean up
the handles to the files as soon as possible. I agree with this. The
current implementation (ie. before configurators were added) applied
these before execution of the filterchain and then was allowed to get
GC'd after. I believe that doing the same logic inside of the
beginRequest and endRequest has about the same lifespan. So my question
is, how does this differ from what was provided by Trinidad before these
enhancements? If it isn't any different, then maybe we can file a Jira
ticket and handle this as part of another patch.
Yep, if it's endRequest(), that's good enough (as long as our
configurator
code has absolute guarantees that endRequest() will be called, which
it does, I think?)
The contract guarantees it yes. Some enhancements will need to be made
to the bridge in order to enforce this without Faces 2.0. Either way,
if it's not executed, it's a bug.
