[jsr-314-open] [C036-ElInResources] ACTION: Vote: Resource.getInputStream() underspecified

[Alexander Smirnov]

Comments inline.

On 09/28/2009 12:49 PM, Andy Schwartz wrote:
> Ed Burns wrote:
>>>>>>> On Fri, 25 Sep 2009 08:55:11 +0200, Werner Punz
>>>>>>> <werner.punz at gmail.com> said:
>>
>> WP> Anyway I think this discussion gets a little bit off topic ;-),
>> wasnt it
>> WP> about how to apply the el to javascripts originally?
>>
>> Thank you. Please take the valuable discussion of caching and resources
>> to a separate thread.
>>
>
> As Jim's email described, the caching behavior is intimately related to
> the question of how to handle EL evaluation in resources. I don't think
> that these two discussions really are separate matters.
>
> I agree with the concerns that Jim raised. If we allow arbitrary EL
> expressions in resources, then we cannot safely set cache headers. I
> think it is very important that JSF provides the ability to
> automatically set cache headers - I do not think we should require users
> to set up a separate filter for this purpose. (Though if like Lincoln
> users prefer to own this responsibility, I am fine with providing some
> way to disable this.)
>
> So, I suppose I prefer RestrictAllowableExpressions, since I feel that
> allowing arbitrary expressions (DefaultToOptOut) means that we either
> need to:
>
> 1. Stop setting cache headers. Or...
The proper solution seems to mark resource that contains el-expressions 
non-cacheable and sent cache-control headers otherwise. It's easy to 
detect such calls from renderer.
> 2. Accept the likelihood that users are going to hose themselves in
> non-obvious ways. Or...
> 3. Design a solution that allows a unique URL to be produced for each
> unique EL context.
Such solution requires some resource metadata that defines parameter[s] 
to unique identify resource. It can't be done automatically because even 
complex file that contains a lot of el references can depend from 
something simple like database primary key value, data hashcode or some 
UUID, but framework has no clue to guess such key. The same metadata 
can be used to solve versioning problem ( go back to xml configuration 
file ? ).
>
> I am not happy with either #1 or #2. #3 might be interesting, but seems
> like a 2.1 project.
>
> If we do go with DefaultToOptOut then in addition to the above concerns,
> I share concerns that others have raised about controlling the opt-in
> behavior globally.
>
> BTW, quick question regarding:
>
>> all EL Expressions in all resources are evaluated every time the
>> resource is served
>
> Do we check for EL expressions in *all* resources? I assume that we
> aren't scanning binary resources (images), right?
>
> Andy
>
>