You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by "Carlin Rogers (JIRA)" <be...@incubator.apache.org> on 2005/06/01 22:54:55 UTC

[jira] Updated: (BEEHIVE-779) ScopedRequestImpl.restoreAttributes() should not point the ScopedAttributeContainer at the Session's stored attribute HashMap instance

     [ http://issues.apache.org/jira/browse/BEEHIVE-779?page=all ]

Carlin Rogers updated BEEHIVE-779:
----------------------------------

    Attachment: j779patch.txt

This patch modifies the ScopedRequestImpl.restoreAttributes() method
so that it no longer assigns the session stored attributes HashMap
to the request ScopedAttributeContainer.

The patch has a small format edit to a tiles sample file so that the
format is consistent with the other page flows in the tiles sample.

> ScopedRequestImpl.restoreAttributes() should not point the ScopedAttributeContainer at the Session's stored attribute HashMap instance
> --------------------------------------------------------------------------------------------------------------------------------------
>
>          Key: BEEHIVE-779
>          URL: http://issues.apache.org/jira/browse/BEEHIVE-779
>      Project: Beehive
>         Type: Bug
>     Versions: V1
>     Reporter: Carlin Rogers
>     Assignee: Carlin Rogers
>      Fix For: TBD
>  Attachments: j779patch.txt
>
> Currently the ScopedRequestImpl.restoreAttributes() assigns the 
> ScopedAttributeContainer with the Session's stored attribute HashMap instance.
> If there are multiple requests to the server in very fast succession, 
> this will cause the use of the HashMap iterator to throw a
> ConcurrentModificationException.
> The problem is that during both restoreAttributes() and persistAttributes()
> we are updating the session's instance of a HashMap. At the same time,
> in persisAttributes() the call to the ScopedAttributeContainer's
> getSerializableAttrs() uses the HashMap instance iterator 
> (HashMap.HashIterator). If between calls to next() for the next 
> MapEntry, and the number of elements in the Map gets altered,
> we get the ConcurrentModificationException...
> java.util.ConcurrentModificationException
>     at java.util.HashMap$HashIterator.nextEntry()Ljava.util.HashMap$Entry;(Unknown Source)
>     at java.util.HashMap$EntryIterator.next()Ljava.util.Map$Entry;(Unknown Source)
>     at java.util.HashMap$EntryIterator.next()Ljava.lang.Object;(Unknown Source)
>     at org.apache.beehive.netui.pageflow.scoping.internal.AttributeContainer.getSerializableAttrs(AttributeContainer.java:91)
>     at org.apache.beehive.netui.pageflow.scoping.internal.ScopedRequestImpl.persistAttributes(ScopedRequestImpl.java:444)
> I will take this one and submit a patch for the committers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira