In some situations, client proxies cache custom scoped bean instances

The problem can be reproduced with a small Arquillian test, that I added to the Weld-core sources (see pull request, based on Weld 3.0.0). The test class injects a request scoped instance and a custom scoped instance of the same type: @Inject @Qualifier1 private TestComponent requestScopedComponent; @Inject @Qualifier2 private TestComponent customScopedComponent; The instances are created by two producer methods: @Produces @Qualifier1 @RequestScoped public TestComponent produceRequestScopedComponent() { return new TestComponent(); } @Produces @Qualifier2 @CustomScoped public TestComponent produceCustomScopedComponent() { return new TestComponent(); } Injection of the request scoped instance triggers the creation of a proxy class that supports caching. The proxy class contains generated code which caches the bean instance in a ThreadLocal (RequestScopedBeanCache). As soon as the second injection is encountered, Weld observes that the client proxy class is already there, so it will just use the class that has been created for the request scoped bean. This leads to caching of the bean instance, while the scope does not support caching (if it supports caching, it needs to call beginRequest/endRequest on RequestScopedBeanCache when a scope is activated/deactivated).