A ConcurrentModificationException is thrown if beans are created while the context is being destroyed.

Two beans are currently in the context while it is being destroyed:
MyRequestScopedBean
MyOtherRequestScopedBean

On @PreDestory of MyRequestScopedBean a third bean MyRequestScopedDataHolder is called. This bean is created because it was not used before.

When the destory logic in AbstractContext continues it failes with a ConcurrentModificationException because the underlying BeanStore (or more accuratly the backing HashMap) has been changed.

This bug is also depending on the version of the deployed app because it influences the key hash. This means there are situations where it works and situations where it won't work (depending of the "order" in the HashMap).

I created an example which uses JAX-RS but it is also reproduceable using MDBs.