After poking around, I got some more information but I am not sure this can be addressed. The SO error is a "side-effect" of JSF wanting to use CDI to resolve EL expressions.

A little bit of summary - JSF 2.3 actually added this and it appears that soon as there is @FacesConfig, CDI resolution for EL kicks in (this is what I gathered from 2.3 spec, chapters 5.9.2 and 5.6.3). That means @Named CDI beans for each EL expression which in essence is correct approach.

Weld registers these new beans as any other beans. Since some are request/session scoped, it will use given request/session as a bean storage. This leads to the map storing a reference to itself (effectively it is a bean representing the storage itself) which, again, is correct. If it wouldn't be that way, Weld would never store that bean and resolution would not work. The bean will operate correctly, users can inject it and query the map, the only problem is toString() or any other deep inspection which leads to recursion.

Ruolin Li I do not think this can be anyhow remedied on Weld side as for us it is just another bean which we put into storage. The only way would be for JSF impl to change the bean producer to return altered map (a copy without the reference to itself?) or to override the toString() for that map if that's the pain point. It's just a hack though, not an actual solution. I am open to other ideas, it's just that I cannot think of how to address this properly...