You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Mark Struberg (JIRA)" <de...@myfaces.apache.org> on 2012/11/19 15:21:01 UTC

[jira] [Commented] (MYFACES-3652) Define default view key algorithm

    [ https://issues.apache.org/jira/browse/MYFACES-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500255#comment-13500255 ] 

Mark Struberg commented on MYFACES-3652:
----------------------------------------

Also please note that the XorShift random long generator would also easily fulfil our security requirements and allows us to get rid of the pretty expensive SecureRandom SessionIdGenerator as well.

Btw no need for a pluggable ViewKey. All the abstraction is done in SessionViewStorageFactory anyway. And even this currently is not fully pluggable. We have 4 different abstractions for this area and none of them is clean atm. I prefer having slightly less but more general SPI interfaces. And fully pluggable of course!

I'm not sure about StateCache. There is currently no documentation what the generic types K and V represent. But that might be a good point of abstraction granularity.

                
> Define default view key algorithm
> ---------------------------------
>
>                 Key: MYFACES-3652
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3652
>             Project: MyFaces Core
>          Issue Type: Sub-task
>          Components: JSR-344
>    Affects Versions: 2.2.0, 2.1.9
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>
> Currently we have a few different viewkey generator implementations. Those got added only in 2.1.9. Before that the only had a TicketCounter in each Session. 
> The original implementation also had no viewId in the key.
> If you think about it, then it makes no sense at all to add the viewId. Despite it's an int hashCode we have 2 problems which completely trashes the purpose: 
> a.) hashCode is not guaranteed to be unique
> b.) the hashCode is always the same for the same view.
> Think about an application with only one xhtml page. In that case the viewId would add no additional info.
> With 4 pages you would only reduce the collision rate to over 25%. Since the application will most times mainly hit by a few entry points like index.html you gain barely anything from adding this information.
> IF we have had problems with any collisions, then we shall add an XorShift random generator instead of the viewId. Leo, I didn't an issue report for such a problem. Do you have any tip for me where I can find that?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira