incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <>
Subject Re: [PORTAL] Adamns inline questions
Date Thu, 28 Dec 2006 17:31:18 GMT

> 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. 

View raw message