Weld on Java SE does not use alternative

Question

I have projectA, projectB, and projectC Eclipse Maven projects.

ProjectA contains:
- IMyApi interface.
- "Empty" META-INF\beans.xml file.
ProjectB contains:
- IMyConfig interface.
- MyConfigJndi implementation of IMyConfig.
- MyApiImpl implementation of IMyApi, with a property @Inject private IMyConfig config;.
- "Empty" META-INF\beans.xml file.
ProjectC contains:
- a MyConfigAlter implementation of IMyConfig, marked as @Alternative.
- a Main class (and method) that initializes Weld SE and retrieves a IMyApi bean.
- a META-INF\beans.xml where MyConfigAlter is listed in the alternatives section.

Now, I run the Main class, and the IMyApi bean is successfully retrieved (as a MyApiImpl instance). But such an instance has been, in its config property, injected with a MyConfigJndi instance, instead of the alternative version (MyConfigAlter)

I am using Eclipse Luna + M2Eclipse.

What am I doing wrong?

UPDATE: I found out that using @Specializes instead of @Alternative solves the issue, but I still think it is not the proper solution (in some situation I may not have access to the "default" implementation).

UPDATE 2:

I am using Weld-se, 2.2.10.Final:

<dependency>
    <groupId>org.jboss.weld.se</groupId>
    <artifactId>weld-se</artifactId>
    <version>2.2.10.Final</version>
    <scope>runtime</scope>
</dependency>

And the initialization is simply

WeldContainer weld =
  new Weld().
    initialize();
IMyApi myApi =
  weld.
    instance().
    select(
      IMyApi.
        class).
    get();

Could you include some information, like what version of weld you're using, how you're bootstrapping? The fact that specializes sounds weird to me. — John Ament, Dec 02 '15 at 02:00
@JohnAment Thanks for your interest, I added the requested data. — SJuan76, Dec 02 '15 at 08:51
Of the three jar's you mentioned above, which one does the initialization code live in? — John Ament, Dec 02 '15 at 12:17
@JohnAment In `ProjectC`, in the `main` method of the `Main` class. — SJuan76, Dec 02 '15 at 12:18

score 4 · Accepted Answer · answered Dec 01 '15 at 17:42

Selecting an alternative using the alternatives element in the beans.xml descriptor only affects the corresponding bean archive, i.e. ProjectC in your case, as documented in Declaring selected alternatives for a bean archive. Based on that, this is logical that the ProjectB bean archive gets the MyConfigJndi implementation injected.

Since CDI 1.2, it is possible to select an alternative globally for the application using the @Priority annotation as documented in Declaring selected alternatives for an application.

So in your case, you could write:

@Priority(Interceptor.Priority.Application)
@Alternative
class MyConfigAlter {
}

score 0 · Answer 2 · answered Dec 02 '15 at 12:28

Another way to solve this is to use -Dorg.jboss.weld.se.archive.isolation=false - from http://docs.jboss.org/weld/reference/2.2.11.Final/en-US/html/environments.html#_bean_archive_isolation_2

The reason that this happens is that each JAR on the classpath becomes its own bean archive. Since the CDI spec as of 1.2 does not include an SE specification there is no definition of how the classpath operates in this mode. This isn't necessarily how an SE app would be designed since you don't have unique classloaders for each JAR.

Weld on Java SE does not use alternative

2 Answers2