Resolving ambiguous dependencies with CDI extension
<p>I am trying to modify our existing CDI extension which creates its own proxy beans. Now there is only a single proxy created for each service. Services have something like application scope so there is always only a single instance of a service.</p>

<p>What I want to accomplish is to create a single proxy bean for every injection point. I need them in order to store some information specific for the given injection point. If there are more injection points for the same service, there will be more proxy beans but still a single instance of a service behind them. However, when I change the behavior this way, Weld complains about ambiguous dependencies since it cannot choose between two exactly same proxies.</p>

<p>How can I fix this? Basically, what I do is observing <code>ProcessBean</code> event and creating a new proxy for each injection point of every single discovered bean. Then I am adding all those proxy beans to container using <code>AfterBeanDiscovery#addBean</code> method. I would somehow need to skip this last step and inject them manually to their injection points or be able to influence the decision of choosing the right bean to be injected. If I am given an injection point and a list of ambiguous dependencies which can be injected into it, I will be able to choose the right one based on its attribute. But I do not really know if it is possible to make this decision for Weld and how I can do it.</p>

<p><strong>EDIT</strong>: Simply what I want to do is to implement my own scope similar to <code>@Dependent</code> but with proxies in which I can store some additional information related to given injection point.</p>

<p><strong>EDIT2</strong>: I have finally fixed it by creating a new qualifier carrying information about specific injection point. This qualifier is added to both injection point and its proxy. But it is not very nice solution since I have to replace injection points with my own implementation which allows modification of qualifiers collection. I sense there must be a more elegant solution. Please, let me know if you can think of any.</p>