Scoped Request Attributes (was: [Vote] POJOfied Environment)

[Daniel Fagerstrom <da...@nada.kth.se>]

Carsten Ziegeler wrote:

>Daniel Fagerstrom wrote:
>  
>
<snip/>

>>>How above Request interface additions will relate to methods already 
>>>added to 2.2 interface:
>>>
>>>   Object getAttribute(String name, int scope);
>>>   Object searchAttribute(String name);
>>>   Enumeration getAttributeNames(int scope);
>>>   void setAttribute(String name, Object o, int scope);
>>>   void removeAttribute(String name, int scope);
>>>
>>>Can any of those be renamed / reworked to be consistent with the 
>>>proposed additions? As we had no single 2.2 release yet, it's good time 
>>>to review those additions.
>>>      
>>>
>>I don't know why we need differnt scopes, maybe Carsten can comment.
>>    
>>
>The discussion about scoped attributes is here:
>http://marc.theaimsgroup.com/?t=108901128600001&r=1&w=2
>
>Basically, in 2.1.x the request attributes are shared between the global
>request and all its internal requests. So internal requests can
>overwrite attributes of the global request or of some parallel internal
>ones. And this can lead to very interesting results. So, scoped
>attributes are a way to solve this problewm.
>
>I recently added the searchAttribute() method that first looks in the
>local scope and then in the global scope for an attribute.
>
>I agree with Vadim, that we somehow should consider these things as well.
>  
>
I missed that discussion. Anyway, IMO global request scope is nearly 
never a good idea. As discussed in that thread, people are into an 
unplesant suprise if they use global request scope for e.g. aggregation. 
Furthermore one introduce quite strange dependencies in the code if 
internal requests affects global request attributes. IMO, one should in 
most cases avoid letting internal requests having global side effects.

In the thread you seemed to agree about that it was best, due to 
compability reasons, to keep the old global scope as default for request 
attributes, and make local request scope available through an extra 
parameter. IMO this is one of thoose cases where it is better to be 
brave and introduce back incompabilities than to keep an obscure 
behaviour. I think we should have request scope as default in 2.2, it 
will break some code, but there is a good workaround with the scoped 
attributes. And we will save most users from unpleasant suprises by 
having the more sensible behaviour as default.

If we go this way, the Map getRequestAttributes(), will have local 
request scope, and we could have a Map getGlobalRequestAtributes() for 
giving access to the global ones. But as using global request parameters 
is a rather uncommon use case, I don't think we need to have POJOfied 
support for it.

WDYT?

/Daniel

Re: Scoped Request Attributes

[Daniel Fagerstrom <da...@nada.kth.se>]

Carsten Ziegeler wrote:

>Daniel Fagerstrom wrote:
>  
>
>>I missed that discussion. Anyway, IMO global request scope is nearly 
>>never a good idea. As discussed in that thread, people are into an 
>>unplesant suprise if they use global request scope for e.g. aggregation. 
>>Furthermore one introduce quite strange dependencies in the code if 
>>internal requests affects global request attributes. IMO, one should in 
>>most cases avoid letting internal requests having global side effects.
>>
>>    
>>
>This is a difficult topic. You can use global attributes to pass
>information from the global request to the sub requests and vice versa.
>This can be very useful sometimes.
>  
>
It is indeed a difficult topic. Using global attributes does not scale 
well and make applications far to monolitic to be easy reusable. We of 
course have to support them despite that for back compability and 
because people might be used to them. But I think it would be much 
better if we saw an internal request like some kind of function call 
with in parameters and return values. Something like that is necessary 
to make e.g. blocks independent of their execution environment. One 
possiblity is to put a parameter map in the response object and make it 
local to the internal request.

>>In the thread you seemed to agree about that it was best, due to 
>>compability reasons, to keep the old global scope as default for request 
>>attributes, and make local request scope available through an extra 
>>parameter. IMO this is one of thoose cases where it is better to be 
>>brave and introduce back incompabilities than to keep an obscure 
>>behaviour. I think we should have request scope as default in 2.2, it 
>>will break some code, but there is a good workaround with the scoped 
>>attributes. And we will save most users from unpleasant suprises by 
>>having the more sensible behaviour as default.
>>
>>If we go this way, the Map getRequestAttributes(), will have local 
>>request scope, and we could have a Map getGlobalRequestAtributes() for 
>>giving access to the global ones. But as using global request parameters 
>>is a rather uncommon use case, I don't think we need to have POJOfied 
>>support for it.
>>
>>    
>>
>I don't agree here. My number one concern is compatibility. Users might
>not notice that we changed this behaviour and will spend days in finding
>these problems.
>
I would rather consider the current behaviour as a bug and am more 
concerned about the days new user might spend on understanding why the 
default behaviour makes there applications stop working when they 
introduce aggregation. But I have no idea about how people write their 
applications, so it is maybe common to use global request attributes.

> So, either we leave it compatible or we provide an
>update tool, that rewrites every old use "getAttribute(name)" to
>getAttribute(name, global scope)" etc. But without such a tool, I'm -1
>on changing the behaviour.
>  
>
Any suggestions about how to write such an update tool?

>In addition, I think it's not that uncommon to pass information between
>the main and the sub requests using global attributes.
>  
>
Might be, but as described above I think we should provide better 
mechanisms if it is considered an important use case. Using global 
variables for communication between parts has rightfully been recognized 
as an anti pattern for decades. It just doesn't scale as all part must 
know and cooperate about some global resources.

>I think we should leave it the way it is and provide three maps:
>- getLocalRequestAttributes()
>- getGlobalRequestAttributes()
>- getAllRequestAttributes() - combines the two
>
>(We can use different names, but I think we should have this functionality).
>  
>
We could do that, but it seem like a quite heavy burden for keeping 
compability with something we should have taken care of as soon as we 
introduced internal requests (although I understand that it wasn't easy 
to predict the consequences back then). The getAllRequestAttributes() 
seem like FS to me, why do you need it?

/Daniel

Re: Scoped Request Attributes

[Carsten Ziegeler <cz...@apache.org>]

Daniel Fagerstrom wrote:
> 
> I missed that discussion. Anyway, IMO global request scope is nearly 
> never a good idea. As discussed in that thread, people are into an 
> unplesant suprise if they use global request scope for e.g. aggregation. 
> Furthermore one introduce quite strange dependencies in the code if 
> internal requests affects global request attributes. IMO, one should in 
> most cases avoid letting internal requests having global side effects.
> 
This is a difficult topic. You can use global attributes to pass
information from the global request to the sub requests and vice versa.
This can be very useful sometimes.

> In the thread you seemed to agree about that it was best, due to 
> compability reasons, to keep the old global scope as default for request 
> attributes, and make local request scope available through an extra 
> parameter. IMO this is one of thoose cases where it is better to be 
> brave and introduce back incompabilities than to keep an obscure 
> behaviour. I think we should have request scope as default in 2.2, it 
> will break some code, but there is a good workaround with the scoped 
> attributes. And we will save most users from unpleasant suprises by 
> having the more sensible behaviour as default.
> 
> If we go this way, the Map getRequestAttributes(), will have local 
> request scope, and we could have a Map getGlobalRequestAtributes() for 
> giving access to the global ones. But as using global request parameters 
> is a rather uncommon use case, I don't think we need to have POJOfied 
> support for it.
> 
I don't agree here. My number one concern is compatibility. Users might
not notice that we changed this behaviour and will spend days in finding
these problems. So, either we leave it compatible or we provide an
update tool, that rewrites every old use "getAttribute(name)" to
getAttribute(name, global scope)" etc. But without such a tool, I'm -1
on changing the behaviour.

In addition, I think it's not that uncommon to pass information between
the main and the sub requests using global attributes.

I think we should leave it the way it is and provide three maps:
- getLocalRequestAttributes()
- getGlobalRequestAttributes()
- getAllRequestAttributes() - combines the two

(We can use different names, but I think we should have this functionality).

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/