Downsides of turning of bean archive isolation?

Question

Suppose a component (i.e. jar file) FeedbackAPI with an interface

public interface Feedback {
    String giveFeedback();
}

and another component (i.e. jar file) FeedbackUser that uses that interface:

public class FeedbackCollector {
    @Inject Feedback feedback;
    ...
}

There are two implementations

@Alternative
public class GoodFeedback implements {
    String giveFeedback() { return "good"; } 
}

@Alternative
public class BadFeedback implements {
    String giveFeedback() { return "bad"; } 
}

To select which implementation to use, i want to select the alternative in the beans.xml of my webapp, without touching the beans.xml of FeedbackUser. But that is only possible if i turn of bean archive isolation.

Is there any downside of turning of bean archive isolation?

Answer 1

As we discussed in comments, the actual (and from CDI perspective correct) solution would be to add beans.xml into your FeedbackUser component and enable the alternative there.

To get back to your original question about flat deployment...

The downside is that you cannot fine-grain your deployment by limiting beans in a per-archive manner (for instance you cannot have interceptors/decorators/alternatives enabled in one archive while being disabled in another). You might also notice that your extensions will behave a bit differently as the observers might be notified of additional events (which would otherwise stay "invisible" to them). And there might be other differences, your mileage may vary based on your setup.

Think of it this way - it is as if you took all your architecture, your util libs, WAR deployment, backend-handling lib, and squashed it back into one (bean) archive. That's how CDI sees it if you use flat deployment.

Why was it introduced? For some cases, testing being one, this might be handy. Other use-case is something similar to what you have but without the ability to modify that beans.xml - in that case you have no way to enable it. You could the use flat deployment to handle enablement (amongst other things). It is not meant as a common use case, you should probably still stick to the original structured deployment if you can.