The CDI project is part ofJakarta and uses GitHub issues as it's issue tracking system.
Therefore, all issues in CDI JIRA project are being bulk-closed as described in this GitHub issue.

If you feel like this particular issue deserves ongoing discussion, investigation or fixes in CDI/CDI TCK, please create a new issue under GitHub repository and include a link to this JIRA.

For specification related question/issues, please use - https://github.com/eclipse-ee4j/cdi/issues
For CDI TCK related questions/issues, please use - https://github.com/eclipse-ee4j/cdi-tck/issues

Dupont Dupont has a very valid question in #4. This is currently completely blocking the usage of JSF utility library OmniFaces in multiple WARs in the same EAR which is deployed to a Java EE 6 compatible container. See also https://code.google.com/p/omnifaces/issues/detail?id=251.

I only wonder, isn't specifically this issue already fixed by https://issues.jboss.org/browse/WELD-1259? Haven't tried Weld 2 yet as JBoss AS 7 / EAP 6 can't be upgraded to use Weld 2.

I have quite a few questions / remarks about it (some of which are already mentioned in CDI-129, but don't have definite answers).

1. both @ApplicationScoped and @ModuleScoped visibility are needed (see DELTASPIKE-335)
   Unlike https://issues.jboss.org/browse/CDI-129?focusedCommentId=12602519&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12602519, I don't think we should automatically share @ApplicationScoped depending on whether the bean archive is packaged in EAR or in WAR (i.e. some cdi extension could use @ModuleScoped for JSF phase listeners and @ApplicationScoped for another purpose, so automatically sharing @ApplicationScoped would result in an artificial jar split for such extensions and packaging difficulties for the end-user).
2. What happens if a @ApplicationScoped bean is packaged in WEB-INF/lib for EAR applications ?
   IMO it should result in an exception, otherwise for EAR containing multiple WARs it will lead to inconsistencies.
3. What happens if a @ApplicationScoped bean is packaged in WEB-INF/lib for WAR application (no EAR) ?
   IMO it should be fine otherwise, we won't be able to use CDI in tomcat or with simple wars on JBoss otherwise.
4. What happens for EAR with multiple WARs if a CDI bean with same name is packaged in WEB-INF/lib of each wars ?
   With JBoss 7.1.x this leads to DeploymentException: WELD-001414 Bean name is ambiguous.
   This means that CDI bean archives must absolutely be packaged at the EAR level on JBoss 7.1.x (and for JSF webapp, JSF libs must be packaged in WEB-INF/lib in order for JSF to scan faces-config.xml - this leads to some difficulties if I package JSF artifacts and CDI beans in the same archive).
   This leads to the question : can CDI bean archives be packaged in WEB-INF/lib and still be portable (not in Java EE 6) ?
   IMO, it shouldn't result in an exception.
5. Same question if the a bean of the same class is packaged in WEB-INF/lib ?
   IMO, it shouldn't result in an exception.
6. What happens if a @ApplicationScoped bean of an EAR is Specialized or has an Alternative in a WEB-INF/lib ?
   Discussed previously : https://issues.jboss.org/browse/CDI-129?focusedCommentId=12602718&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12602718
   IMO, CDI impl should raise an exception (if we agree for 2. that @ApplicationScoped beans can only be defined at the EAR level for an EAR).

+1 for @ApplicationScoped == "@EARScoped"
Q: If no common agreement arises, could this be configured via a property?
By default @ApplicationScoped == @EARScoped but you can configure it to be @WARScoped via a property?

We discussed this, and we are strongly in favor of:

• @ApplicationScoped being shared across the EAR
• Visibility rules being applied as described in CDI 1.0

Other approaches are very interesting, and should be prototyped, but we don't believe that changing the way either of these concepts works from certain 1.0 CDI implementations is correct.

Note that we don't believe the concerns raised about specialization and alternatives to truly be an issue, as beans which have been specialized, and beans for which there is a selected alternative are not enabled in the application in the 1.0 specification.

Working on the assumption that the EG is not agreed on this position, I will start a vote on this topic next week.

Note to self, make sure we clarify what exactly what "application" means in Chapter 12 of the CDI spec, for the CDI spec, as it's too loose in the Java EE spec.

I am not aware of @Alternative being broken in Weld. If you think it is please file a Weld issue.

@Alternative is pretty much broken in Weld. I'd rather make the 'User' class in the shared lib an interface and test that. But pretty busy today. Feel free to fork and extend the tests. In any case that what this example shows gets pretty heavily used in the wild - most CDI based multi tenant apps work that way.

I would not say "vertical approach is implemented". It is probably a side effect of specialization never being properly implemented in Weld 1.x. This has other unexpected side effects. Can you try your test with alternatives?

Stu, it seems that large potions of the behaviour you described are already standard in all existing EE-6 container I tested with a small test app: https://github.com/struberg/cdi_eartest
It contains an @ApplicationScoped MailService which injects a @Specialized bean from a webapp. If you get "Yea, we are AdminUser!" on the landing page, then Jozefs 'horizontal' (EJB like) interpretation of the visibility rules is not implemented in a single certified EE container on the market but the rather 'vertical' approach is! Please review and test yourself.

Note that this approach actually solves some other problems as well, such as what happens when an extension in a war modifies a shared bean? At the moment this change will be visible everywhere, which violates the 'wars are isolated' principle. If you set the war to be an isolated deployment then this will not longer be an issue, as the war will only modify its own copy of the bean.

I think the real problem here is that there are two different use cases, in some cases the developer may view each war in an ear as a completely separate app, in other cases they are considered to be part of a single app.

A potentially simple way to resolve this would be to make this configurable. In beans.xml of a war you could do something like:

<beans>
<isolated-deployment>true</isolated-deployment>
</beans>

This would mean that the war would be treated as an separate CDI deployment, with its own scopes, extensions and beans. Bean discovery would still pick up shared beans and extensions from shared modules, however extensions will have a new instance created specifically for this deployment.

Conceptually this is the same as just bootstrapping CDI twice, once for the isolated sub deployment, and once for 'everything else'. In practice a CDI impl could probably share some of the state internally, to reduce the overhead of two different CDI startups.

As far as I can see this solves all the problems:

1) no dynamic wiring
2) User can choose if application scoped works the Weld way or the OWB way, depending on their use case
3) It is mostly backwards compatible, although OWB users would have to add a single line of xml to each war

Thoughts?

Mark, please don't rewrite history. The EG has NOT agreed that BDA and 5.1 are wrong. We simply discussed how to enable and disable alternatives, interceptors and decorators.

that is exactly the problem: BOTH ways are not fully covered in CDI1.0! See CDI-18 where the EG already agreed that BDA and 5.1 is moot and needs to get redefined. Also
�

�
2.4 Scopes:
Java EE components such as servlets, EJBs and JavaBeans do not have a well-defined scope. ...
singletons, such as EJB singleton beans, whose state is shared between all clients,
...
Scoped objects, by contrast, exist in a well-defined lifecycle context:
their state is automatically shared by clients that execute in the same context.

Actually your interpretation of the spec would exactly fit the aforementioned EJB @Singleton. And in the same paragraph this is explicitly ruled out.

Also please note that your interpretation would have the result that firing a CDI event from an @ApplicationScoped bean in a shared lib would NOT reach any bean defined in any WAR file! There is no way to do that with your interpretation.

Again: all that ONLY happens if you need to deal with scopes > 1 per war.

In an attempt to summarise (which I'm sure will get me accused of bias, but I'm trying not to be!)

Viability of solution

(a) it is technically possible to consistently and sanely provide per-EAR, as this is what Weld does. TODO, add notes
(b) it is technically possible to consistently and sanely provide per-WAR, as this is what OWB does. TODO, add notes

Intent

The CDI 1.0 spec intended @ApplicationScoped to be per-EAR (as clarified by Gavin King, CDI 1.0 spec lead). Java EE describes an EAR as an "application" (as clarified by Bill Shannon, Java EE spec lead).

Backwards compatibility to Java EE app servers

All certified Java EE app servers provide @ApplicationScoped as per-EAR.

Note that this is only backwards compatibility the Java EE EG and JCP care about.

Backwards compatibility to non-Java EE certified environments

(a) Weld deploys to servlet containers, however this is not relevant to this discussion. We have never seriously investigated using Weld in a Java EE 5 app server.
(b) OWB deploys to Java EE 5 application servers, where it provides @ApplicationScoped per WAR.

Community

The community is fairly evenly split between per-EAR and per-WAR, with 53% choosing per-EAR and 47% choosing per-WAR in a poll.

Gavin has provided a very prompt response, and confirms that yes, the CDI 1.0 EG definitely intended @ApplicationScoped to be "per-EAR" and NOT "per-WAR", confirming my assumption that the note about "standard scopes defined by Servlet spec" was just an oversight.

b.) 5.1 is already obsolete. We already agreed in CDI-18 that all the modularity and BDA stuff must get reworked anyway as it is currently broken.

We have certainly not agreed on this.

Coming in on discussions from the weekend.

1) Initial intent. I'm 100% sure that Gavin intended @ApplicationScoped to be shared across the EAR originally, and that the comment about "standard scopes defined by Servlet spec" was the mistake. However, as I've been proved wrong here before, I've double checked it with him. Hopefully I can get an answer soon!

2) Whilst you may see most people using CDI standalone, what we are actually specifying here is how CDI works in Java EE 7 and above, and this what we must focus on. We must take account, of course, these other users, but they are lower than other considerations like how CDI works in Java EE 7 and above, backwards compatibility with Java EE 6 application servers.

I am not sure which part of my comment does your argumentation relates to.

I assume you accept that there are the two possible approaches. I assume you accept that the first approach does not conflict with CDI 1.0 (Talking about the wiring only. Nothing about the @ApplicationScoped yet). Can we both agree up to this point?

What I guess you are arguing about is whether the semi-static approach is valid or not.

oki, for the 1000th time:

a.) the term 'bean' in 5.1 might also be interpreted as 'Type at the injection point'

b.) 5.1 is already obsolete. We already agreed in CDI-18 that all the modularity and BDA stuff must get reworked anyway as it is currently broken.

@Jozef your argumentation with semi-static wiring is not quite right. This is perfectly allowed and even necessary in CDI 1.0. Please look at Bean<T> and InjectionPoint. Then look at Bean#getInjectionPoints(). This doesn't return a list of Bean<?> to be injected but only a list of InjectionPoints. And those just contain the Type and not the resolved Bean<?>. So upon creating the Contextual Instance via T Bean<T>#create(); a CDI container has to first do getInjectionPoints() and then for each InjectionPoint RESOLVE the correct Bean<?>. This is not defined in a static way in CDI 1.0 but fully dynamic!

No! The reason for that is because Beans are decoupled. Otherwise an extension would need to provide the entire Bean graph should it want to add a new Bean.

What the spec says is that for a given InjectionPoint declared on a Class that is packaged in a given module, there is always a single Bean<?> that this InjectionPoint resolves to. Otherwise, it is a deployment error. This is what I refer to as "static wiring" and this is what CDI specifies (sections 5.1 and 5.2).

If the same InjectionPoint can resolve to different beans depending on the current thread state, this is what I refer to as "semi-static approach" (you came up with the term)

EAR is only defined in EE. I see no way to deploy an EAR to a non-EE server

All the other mentioned stuff like MDB, @Timeout, etc are ALL EJB parts as well.
A legacy application could still use a simple static field if they like to share state. That was the way they did it with Spring and they will do it with CDI as well.

Btw, actually most CDI users I know do NOT use an EE6 server but still EE5 + either Weld or OWB in their webapps. Amongst them are huge banks, 2 of the 10 biggest stock exchanges worldwide, the biggest international military pact and, some universities, etc. They all run those 'big irons' and replaced Spring with Weld or OpenWebBeans. I actually know very few projects who already use a big EE6 server in production. To be honest: non of the big companies I know use it yet, they are still just testing.

And now please answer me what all those companies do get if they drop Weld or OpenWebBeans into their webapps and add the ServletListener to boot the CDI container? Exactly, they get 1-per-WAR behaviour.

"Now the question is: why the hack do we need that? Just use an @Singleton EJB if you like to share state between different WAR files, MDB and stuff!"

The problem with this is that this only works for EE applications. So if you want a singleton bean, you have to use @javax.ejb.Singleton for EE apps, and @ApplicationScoped for non EE apps, which I don't think is that great.

Yesterday Gerhard, David and I had a really good late night discussion. I think I now understand a bit better where you guys are coming from conceptually. The isolation rules Jozef proposed are the ones from EJB. But CDI beans are not EJBs! CDI introduced the notion of Contexts and proxying. With EJBs you don't have cross-scope injection abilities, etc. A lot concepts are fundamentally more open and different in CDI. Thus I fear we also cannot apply EJB rules 1:1 to CDI beans.

Now think about it again: you basically like to define @ApplicationScoped as alias for (EJB) @Singleton, right?
That's what it boils down to if I read your proposal.

Now the question is: why the hack do we need that? Just use an @Singleton EJB if you like to share state between different WAR files, MDB and stuff!

So we do not even need to introduce any new scope because a thinkg like "@EnterpriseApplicationScoped" already exists: @Singleton. Maybe that was the reason why Gavin explicitly specified @ApplicationScoped web-app/servlet centric as 1-per-WAR by writing "The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in Section 6.7, “Context management for built-in scopes” represent the standard scopes defined by the Java Servlets specification."

The argument with the TCK is also not the strongest one. The JCP defines the following rule when resolving ambiguous definitions:
1.) JavaDoc
2.) Spec Wording
3.) TCK

We (OWB) already reported 30++ bugs in the TCK and I guess others did the same. If you consider how many tests there are then this is only a small part, but still.

Btw, it really rocks that the TCK is open sourced! This allows us to easily fix shortcomings, add more use cases and most importantly: talk about scenarios! With closed TCKs we would not even be allowed to talk about TCK use cases in a public bug tracker!

@Jozef your argumentation with semi-static wiring is not quite right. This is perfectly allowed and even necessary in CDI 1.0. Please look at Bean<T> and InjectionPoint. Then look at Bean#getInjectionPoints(). This doesn't return a list of Bean<?> to be injected but only a list of InjectionPoints. And those just contain the Type and not the resolved Bean<?>. So upon creating the Contextual Instance via T Bean<T>#create(); a CDI container has to first do getInjectionPoints() and then for each InjectionPoint RESOLVE the correct Bean<?>. This is not defined in a static way in CDI 1.0 but fully dynamic!

naturally (reading the spec the fisrt time) i thought about 2) but if Module == webapp for war (what about bda? if module is taken from JEE definition that sounds fine for me)

Right, somewhat confusingly (though understandable perhaps if you think of the age of the Java EE spec), Java EE names EJB JARs, WARS etc as "modules". Modules are not the same as a library (e.g. which goes in WEB-INF/lib or is installed in the app server).

However I'm not sure about @ModuleScoped, for the obvious reason that the word module has a wider meaning, especially if modularity makes it into the JDK. I suspect we need another term

@jozef:
ok - i'm happy that it just sounded differently and the context shouldn't imply that only mark has this opinion.

naturally (reading the spec the fisrt time) i thought about 2) but if Module == webapp for war (what about bda? if module is taken from JEE definition that sounds fine for me)

I still have not fully thought this through, but some more thoughts I have had on the subject:

When you say "one which makes users get different contextual instances depending on where the injection into gets made is an absolute no-go", I read your 3rd option as doing basically the same thing (the same injection point can resolve to different beans, but depending on the current thread state, which to my mind sounds even worse in a lot of ways).

Also your statement "this is NOT needed if we do not inject into a bean which is of a broader scope than 1 per webapp" is not correct. Say you have a request scoped bean (X) in the top level module that inject a User, and then you have a war that @Specialises the User bean. Depending on the web app that is active X.user will resolve differently. You wil not be affected by the proxy bug in the current implementation, however that is an implementation issue, and you still have to do semi-static wiring (although at injection time rather than invocation time). Also we still have to deal with custom scopes, which could cover the whole ear, so even then this does not help.

I also really dislike the way that wars are treated as 'special' in your proposal, not every EE app has a war.

Anyway, back to the actual scope issue and ignoring the specialisation issue for now, I think that we have two options:

1) Make ApplicationScoped per war/module, and add @EnterpriseApplicationScoped
2) Make ApplicationScoped per ear, and add @ModuleScoped

I prefer option 2:

• @EnterpriseApplicationScoped does not make much sense outside an ear. If you are writing portable code using @EnterpriseApplicationScoped for a '1 per app' scope seems a bit misleading when it may not even be an enterprise app.
• ModuleScoped also also more consistent with regard to things like EJB timers and invocations, I have never really heard an EJB jar referred to as an 'application', so IMHO ModuleScoped makes more sense here. I also really don't think we should be treating wars any different to other modules.

Now, on to the portable extension issue. Weld creates a single instance of a portable extension, I must admit I was quite surprised when I found out OWB does it differently. I know that a lot of portable extensions that I have written just assume that there is a single instance, and will basically do things like add the same bean twice when they are instantiated twice. I am not really sure how to resolve this, one option that comes to mind is allowing @ModuleScoped, @ApplicationScoped or @EnterpriseApplicationScoped on the PE class itself (depending on the annotation name we go with), although to be honest I don't know if I really like that idea that much.

This needs a lot more thought.

For my side I have a pretty clear opinion:
We have 3 options as listed above, and the one which makes users get different contextual instances depending on where the injection into gets made is an absolute no-go.

So 2 Options remain (and I will not argue about which one is in the spec, because BOTH are covered + contradicted in CDI 1.0)

either

• restrict @Specializes and @Alternative to all non Object.class CDI-Bean Types to the outermost module

• go with semi-static wiring IF needed. Again: this is NOT needed if we do not inject into a bean which is of a broader scope than 1 per webapp! By clarifying that @ApplicationScoped is 1 per WAR we could use fully static wiring for all CDI beans!

that's also not "more objective", because it isn't only mark who has this opinion.
since openwebbeans handles it that way, the owb team agreed on it as well.

In my summary I by no means intended to indicate that Mark is the only one in the world that likes that idea. (Just as if I write "Gerhard has a red t-shirt" I do not claim that there are no more people with red t-shirt ) Besides the OWB team, Stuart expressed an interest in latter approach as well. Furthermore, I also consider it to be an interesting alternative approach.

However, the fact still remains that out of the two approaches, the CDI 1.0 specification defines the former approach (static wiring). For the purpose of this issue we either have to accept what the spec currently defines - the former approach (static wiring) or we have to change the specification to use the latter approach (semi-static wiring).

This approach is btw also used in other CDI Extensions like Seam3. All of them would be broken.

Fact is that we need to define exactly how the BeanManager scenario and thus also the Extension scenario looks like.

@stuart:
it would be a huge issue for us, if we don't get one application scoped PE per web-app.
that's currently the approach used in deltaspike to collect artifacts which need to get processed later on.
we can't store them per classloader, because e.g. servers like wls12c use a different classloader during the bootstrapping process.

yes, that might have been the intended 'side effect' for the implementations. But from the definition pov it adds much more sugar: a well defined lifecycle. And this was for sure not intended.

I was actually thinking about this same issue today. IMHO we need a special scope for Stateless and Singleton beans, as they are certainly not @Dependent scoped, and a lot of the rules and restrictions for @Dependent scoped beans simply don't make sense for them. I have created https://issues.jboss.org/browse/CDI-278 for this issue.

i understood it (and in implementation that's consistent) as "let the ejb container manage it" and don't add a proxy in front on another proxy. The best choice in CDI 1.0 IMO

Romain, usually @Dependent beans do NOT get a proxy. That's one of the other problems with this definition.

Indeed, in my opinion an @Stateless EJBs do not have any CDI scope at all. It follows it's own lifecycle. I can only think of this definition as Gavin wanted to use some side effect of it. I don't know which though. @Dependent beans are actually the exact opposite to 'stateless'. Every injection point gets it's own instance and can fully hold state therein.

Mark for EJB that's not so stupid because you get proxy not real instance so you really don't need to manage any scope for stateless or singelton (ejb one)

BTW i saw some extensions managing classloaders but was not as easy as it should be IMO

Actually all Extensions I know expect to not have to handle multiple classloaders but only are written for exactly one module.

regarding 3.2 In this paragraph are a few things wrong. e.g. just before the quoted sentence you'll find "A stateless session bean must belong to the @Dependent pseudo-scope." Just plain wrong imo. @Dependent means for every injection point you will get a new instance. Indeed that would be pretty disastrous for stateless EJBs

A few other lines from the spec that are relevant:

11.5 - "For each service provider, the container must provide a bean of scope @ApplicationScoped and qualifier @Default, sup- porting injection of a reference to the service provider instance. The bean types of this bean include the class of the service provider and all superclasses and interfaces."

If the application scope is scoped to the WAR then this means you need to create an instance of the PE per war.

3.2 - "A singleton bean must belong to either the @ApplicationScoped scope or to the @Dependent pseudo-scope"

Singleton beans are definitely one per EAR, so if application scope is per war then they should not be allowed to be application scoped.

Jozef, thanks for your input so far. There are some valid points in your argumentation and we need to clarify those. I guess we now have a pretty clear picture that EAR scenario is broken in CDI 1.0 if we use scopes broader than 1 contextual instance per war.

We also outlined 3 different approaches to treat such scopes. We will schedule an EG meeting to discuss this in the EG.

That is a pretty biased summary that ignores quite a few parts of the discussion above. I'll try to come up with a more objective one:

After discussion with Mark and Stuart we all can see that there are two orthogonal issues involved:

• wiring
  • CDI is based on static wiring where the Bean for an injection point is resolved based on the module the class that declares the injection point is packaged in. (as explained in Section 5.1 of the CDI 1.0 spec)
  • Mark thinks that a semi-static approach, where the Bean for an injection point is resolved based on the context of the thread in which the execution occurs is more appropriate. That means that if MailService is invoked from a web application that packages class B (which specializes A), MailService will also operate on the specialized version (B).
• the actual span of the @ApplicationScoped (either per-war or per entire ear)

Ok, the survey is created - http://www.surveymonkey.com/s/9VNXZDB

There is a lot of stuff here, but firstly:

a) Bean is quite well defined in CDI. If it gets a ProcessBean event thrown then it is a bean.
b) You are correct and TTCL is irrelevant here. Class loading is actually pretty irrelevant here, the EE platform spec defines class loading in terms of classes that must and must not be visible, and allows vendors to implement that with whatever class loading arrangement works

So from what I see the problem is that there is a conflict in the spec to do with how injection point resolution works with scoping. 5.2.1 makes it pretty clean that every injection point must resolve to one and only 1 bean. In Mark's example, it actually resolves to different beans, due to scoping issues, and this is a problem that we need to sort out in the spec. Making ApplicationScoped be a per web application thing however is not a solution to this problem. This would mean that different beans resolve to the same injection point depending on the current context, which completely destroys static wiring, and we get back to a Seam 2 style resolution at injection time.

It also makes the CDI deployment dependent on the current web app. What happens when there is no web app in an ear? What happens with a standalone jar? what happens with a SE app?

Mark, from what I am reading it sounds like you are trying to bring back the worst of Seam 2 (I know you probably did not use Seam 2, but the approach was pretty much exactly what you are describing, and it had a lot of problems).

IMHO we should just add @WebApplicationScoped and tighten up the spec to remove the scope problems, so if a bean ends up resolving injection points differently depending on the current archive it is a deployment error.

Gosh Jozef, please don't drive me nuts! just read the thread above to find it!

a.) It is not clear what the term 'Bean' used in 5.1 means
b.) Pete was not sure about the TCCL, go on read the TCCL paragraph again please. Imo it is relevant.
c.) your interpretation is contradicted by the example shown in "2.2. Bean types"
d.) the whole BeanManager API design contradicts your arguments

what else?

The spec is just not clear. I f***n don't care on which end. If A contradicts B then there are 3 ways to fix that: fix A, fix B or fix both.

To me the only sure thing is that we need to fix something as no possible interpretation closes all the gaps. Although the interpretation with the 1 per WAR would imo be the closest one and is also the only interpretation EXPLICITLY defined in the spec. All other interpretations are just indirect consequences of other definitions.

I already explained the argumentation chain which allows to interpret 5.1 to perfectly fit this picture in some posts above.

Yes. Afterwards, your TCCL interpretation of modularity was considered incorrect by Pete.

To interpret 5.1 in the way you propose would contradict the definitions of ...

Since you provided no evidence nor argumentation I assume your statement not to be true.

Jozef, thanks for your input so far. There are some valid points in your argumentation and we need to clarify those. I guess we now have a pretty clear picture that EAR scenario is broken in CDI 1.0 if we use scopes broader than 1 contextual instance per war.

We also outlined 3 different approaches to treat such scopes. We will schedule an EG meeting to discuss this in the EG.

Pete, do you have the example app somewhere so we can look at the sources?

I already explained the argumentation chain which allows to interpret 5.1 to perfectly fit this picture in some posts above.

BDA is btw is currently broken and the EG is working on a solution right now. See CDI-18.
To interpret 5.1 in the way you propose would contradict the definitions of

• BeanManager#getBeans(String)
• BeanManager#getBeans(Class)
• BeanManager#resolve()
• BeanManager#getReference(Bean<?>, Type, CreationalContext<?>)

In other words: that would be broken for EARs as well.

I cannot see any classloading issue!

The fact that you could possibly implement it that way does not mean that it is the right thing to do nor does it mean that it is the correct interpretation of the spec.

Btw: Weld 1.x and 2.x implement it EXACTLY THAT WAY ALREADY!

This is not true. Even if it was it would only mean that there are bugs in Weld. That happens.

Can you tell me which part of Section 5.1, which describes how modularity works in CDI, allows you to inject S into MailService?

here is the original quote from pete

I don't believe the TCCL is relevant here, it's only ever used explicitly to load classes, not implicitly if you instantiate via the new keyword, which is the model we are trying to follow.

That doesn't sound like 'it is definitely that way'. Indeed you almost NEVER do do 'new SomeClass()' in dependency injection frameworks at all! That's the whole idea of DI containers to always do this dynamically.

Imagine we do all this by hand:

step 1: create a MailService mailService = new MailService()
step 2: create a S s = new S; // S extends R
step 3: mailService.setR(s);

What is the problem with that?
I cannot see any classloading issue!

Btw: Weld 1.x and 2.x implement it EXACTLY THAT WAY ALREADY!

Of course, the MailService cannot have a @Inject S s; but only a @Inject R r;
But that doesn't restrict us to only inject instances of type R into it if we ONLY go on using those beans in our very own webapp!

Mark: Thus the MailService instance of your very webapp inoking r.someMethod() would work on an instance of S.

If we combine your statement with a quote from Section 5.1 of the CDI 1.0 spec:

A bean packaged in a certain module is available for injection, lookup and EL resolution to classes and JSP/JSF pages
packaged in some other module if and only if the bean class of the bean is required to be accessible to the other module by
the class accessibility requirements of the module architecture.

We can clearly see that you are wrong. The web app is not required to be accessible from the shared library. Therefore, S is not available for injection in the shared library and thus cannot be injected into MailService. What you are talking about is not CDI.

Mark: Dude, who is creating the instance of MailService? It is the BeanManager which uses the TCCL of your webapp

As Pete already explained, your TCCL argument is irrelevant to modularity in CDI.

Pete: I don't believe the TCCL is relevant here, it's only ever used explicitly to load classes, not implicitly if you instantiate via the new keyword, which is the model we are trying to follow.

what is 'shared mail service' ?

If we assume

@ApplicationScoped 
public class MailService {
  @Inject R r;
  ...
}

then each webapp would get it's own contextual instance. Thus the MailService instance of your very webapp inoking r.someMethod() would work on an instance of S.

For another webapp you might end up with an instance of R if this webapp doesn't specialize and not provide an alternative for S.

> S, however S is not accessible from the MailService so this is wrong

Dude, who is creating the instance of MailService? It is the BeanManager which uses the TCCL of your webapp. Also: this BeanManager of your webapp knows all enabled Bean<?> of your webapp, so it will perfectly be able to resolve Bean<S>.

No of course not! At least not in my model

OK, let's assume then that we took the approach 3) you proposed above (@ApplicationScoped per war) which claims to fix the issue. If the web app in my example above introduces a class

@RequestScoped
@Specializes
public class S extends R {
}

The Servlet would arguably operate on an instance of S. Assuming the servlet invokes the shared mail service, instance of which class would MailService operate on?

a) R, which means that the problem is not fixed and you are wrong (@ApplicationScoped per war does not change anything)
b) S, however S is not accessible from the MailService so this is wrong

From there we can see that @ApplicationScoped is per war has no impact on the "issue" that which you described as "user no-go".

> What you say is that the Servlet would operate on a
> different instance of the same R bean than the MailService?

No of course not! At least not in my model, but in your approach this exact problem would happen!

In my model a call stack would ALWAYS get the same contextual instance for the same injection points! Dude there are serious understanding problems we should clarify it seems. Go back a few meters and take a look at it again. We could also again do some tele conference together with pete to clarify the behaviour. You can also take a look at OWB where this perfectly works.

And PLEASE do avoid the term 'bean'. I like to NEVER read BEAN in this thread again, pretty please! It's sooooo ambiguous! Please erase it from your mind

What happens in my scenario is that the same shared class T could resolve to different Bean<T> depending on the webapp. But as each webapp has it's own contextual instances the same code @Inject T t; might end up as T1 in webapp1 and T2 in webapp2. This is not a problem - not even in CDI 1.0 - as the two webapps would get different contextual instances and always see the whole classes of all it's own webapp!.

By not providing a scope bigger than 1 per WAR, we DO NOT HAVE THOSE AFOREMENTIONED PROBLEMS IN CDI.

OK, assume there is a shared @RequestScoped bean R in the shared library injected both into a Servlet in your web app and into the MailService in the shared lib. No alternatives nor specialization this time. What you say is that assuming the Servlet invokes MailService, the Servlet would operate on a different instance of the same R Bean (Bean<R>) than the MailService? In the same call stack during processing of the single same request? How is that consistent? Maybe we could do a poll if this is what people want This is not CDI.

on which part? On the 'unusable' or the 'multiple contextual instances per Injection Point for the same call stack'?

I disagree that it is unusable.

> The same thing would happen for a @Dependent scoped bean
> or a @Request scoped bean. Although Mark thinks that restricting
> @ApplicationScoped per war fixes this it actually does not.

Again Jozef, this is JUST NOT TRUE for CDI!

The problem is not the scope of the bean which gets injected, but the scope of the bean you inject into. Are we d' accord on this part? It just doesn't friggin depend whether the injected bean is @Dependent, @SessionScoped or any other scope. So we are just talkin about the scope of the bean which helds the injection point. And here comes the clue:

By not providing a scope bigger than 1 per WAR, we DO NOT HAVE THOSE AFOREMENTIONED PROBLEMS IN CDI.

We could go on and define the behaviour for scopes larger than 1 per WAR in CDI 1.1.

The EJB EG would probably need to clarify the restrictions for injecting into shared stateful EJBs, but indeed that is not so much a problem of CDI.

> I disagree.
on which part? On the 'unusable' or the 'multiple contextual instances per Injection Point for the same call stack'?

The key point here is what get's injected into MailService, which is an EAR bean, is different depending on which WAR you are in, which is a little odd.

Unfortunatelly I cannot see the code anywhere so this might not be entirely accurate but I'd like to point out that this problem is orthogonal to scoping of the application scope. The same thing would happen for a @Dependent scoped bean or a @Request scoped bean. Although Mark thinks that restricting @ApplicationScoped per war fixes this it actually does not.

Jozefs way is technically valid, but a no-go from a user perspective imo as it would lead to having different contextual instances for the same injection points across your application.

I disagree. If you want to override a certain bean globally, put the alternative into a shared jar or into another jar that is visible to all the web applications. If you only want to change the behavior in one of the web applications, put the alternative bean into the web application. I find this way consistent (because it does not create exceptions to rules), straightforward and powerful (because you can choose out of multiple options without introducing new scopes).

Should @ApplicationScoped bean instances be shared between all modules (web apps, ejb modules etc), or be per web application?

again the term 'bean' which is so highly ambiguous I guess you fear that the public audience is not yet fully aware of 'Contextual Instance'?

I'd rather try it a bit more sluggish:

What would you expect to get from an @ApplicationScoped CDI bean in an EAR? 1 instance per each Web-Application or 1 instance for the full EAR?

Regarding the Bill quote: I've now read through the EE6 spec and it appears to me that they mostly refer to EARs as "Java EE Application" (in older spec versions it was "J2EE Application"), see e.g. EE.2.11.3, EE.2.4, EE.2.12.2, EE.5.5.2 and 185 more references. There is other prominent mentioning of "JSF Application", "Web Application", even "Desktop Application" and "Java Application" amongst a dozen others.

Do you have the code somewhere? What I observed in JBossAS and Glassfish is that the WebApp which touches the shared MailService the first time will do all the injection based on the active beans in this very webapp. Regardless if the resolved Bean<X> is visible in the other webapps or not. This is not only wrong but might in some cases even create the obvious NoClassDefFound and similar (great candidate: serialisation time).

Of course one could argue this is an impl bug, but otoh how to implement that correctly?
And now we are back to the 3 listed ways to do it:
1.) injecting only other beans of the shaed-lib and completely ignore anything defined in the webapps. Jozefs way is technically valid, but a no-go from a user perspective imo as it would lead to having different contextual instances for the same injection points across your application.

2.) restricting @Specializes and @Alternatives to only shared libs. This is technically valid as well but this restriction is certainly not covered by the spec.

3.) make @ApplicationScoped 1 per WAR and thus remove the problem with scopes over multiple isolation levels. All our classloader slices would always see exactly 1 well defined scenario. We should nonetheless think about any scope broader than 1 per war in CDI-1.1, but for CDI-1.0 it would perfectly work (And to repeat again: this is also what is explicitly stated in the spec 2.4.1).

Proposed question for the poll is

Should @ApplicationScoped bean instances be shared between all modules (web apps, ejb modules etc), or be per web application?

Mark, wdyt?

I think we need to resolve how BeanManager works exactly before we can address exactly how getBeans() works. But I agree, it's very unclear how this should work if you try to use BeanManager from outside a Bean.

Here is the gisted version of Mark's example.

The key point here is what get's injected into MailService, which is an EAR bean, is different depending on which WAR you are in, which is a little odd.

Ok, I'll start the poll. Still getting to the BeanManager bits!

Mark's "MailService" example is very helpful, but I'm struggling to fully comprehend it because of the formatting. I'm going to try to create a gist, which will give us compiling code. This should make it easier to understand I think! Mark, I'm going to need you to double check that I've accurately reproduced your example!

we could start a public poll. I did let raise hands on a few conference talks and it was about 95:5 for 1 per webapp.

What about my BeanManager#getBeans() question?

a.) I've now talked with lots of different folks, including JSR spec leads, and NO ONE did expect that behaviour.

Mark, it would be very helpful if you could have these people engage in this discussion directly with the CDI EG, as I do not see a similar pattern.

EAR -> EE application ok, but is the other direction true as well?
application -> EAR?
Imo not, because the term application is also clearly used for webapps too in the EE umbrella spec.

This was in answer to the question "What is the definition of "application" in Java EE?" so I would think that this was just the way Bill expressed himself, rather than carrying your inference. However I'm happy to double check if you want?

Mark says:

Due to the well defined TCCL behaviour in the EE umbrella spec it is perfectly viable that A might see B IF it is invoked in a request of the webapp containing A. So technically from the EE spec there is NO such restriction you mentioned. It's just easier for a container vendor to implement.

I don't believe the TCCL is relevant here, it's only ever used explicitly to load classes, not implicitly if you instantiate via the new keyword, which is the model we are trying to follow.

Another point: who likes to go to all the other spec leads like JPA and most important JSF and confess that we messed up? Especially who gonna tell Ed that he cannot drop JSF ManageBeans because we have no replacement for his ����JSF @ApplicationScoped which exists since 10 years and he finally agreed to get rid of?

I'm quite happy to take on any tasks that involve discussions with other spec leads.

As JSF is prepared to deprecate scopes, and move people over to standard CDI scopes, there is a code change required anyway. Therefore, if we were to introduce a @ModuleScoped or similar, I think JSF apps could move from JSF application scope to this.

There may be places where we don't use the terminology as precisely as we should, but I think Chapter EE.8 of the platform spec makes it clear that an ear file is a single Java EE application.

EAR -> EE application ok, but is the other direction true as well?
application -> EAR?

Imo not, because the term application is also clearly used for webapps too in the EE umbrella spec.

Pete, afair we just agreed that most containers implement it that way currently and that this is basically broken. Please think about the consequences! That would render CDI almost useless! Also please comment on my BeanManager clarification questions.

What will a BeanManager#getBeans() return you?

On that very meeting I told you that I will write up concrete examples and here we go.

In this comment I'll try to go through the points from Mark and Jozef, and add some more facts that I have. I'll then do a separate comment with my opinion

> ... beans that execute within the same application.
Too bad it's neither in the CDI nor the EE spec defined what they mean with application. Both sometimes refer to web-applications and sometimes to enterprise-applications. It's just not clear.

I previously asked Bill Shannon and Linda DeMichiel for a clarification on this. Bill said:

There may be places where we don't use the terminology as precisely as we should, but I think Chapter EE.8 of the platform spec makes it clear that an ear file is a single Java EE application.

So, whilst it may not be clear, the official line is that an "application" is an ear, if ear is used.

Afair it was 2 options:
Option a.) just disallow @Specializes and @Alternatives for all beans defined in a shared jar. Regardless of it's scope.
Option b.) inject only beans defined in the shared jar into another bean of a shared jar. E.g. MailService would always get an instance of A injected. Imo this is pretty crucial as @Inject X x; in a JSF backing bean would give you a different contextual instance (even of a totally different type) than the same code @Inject X x; in the MailService.

We discussed this at the CDI EG meeting and the consensus was that option B is correct, as the injected instance depends on how the beans resolve, and thus getting a different contextual when a different bean resolves is expected.

Sorry Jozef, you are a pretty clever dude in general and you did hit quite some nails. But in this case you started to drop "it is that way" sentences but missed the most important part of it: the actual argument! I had expected something like "I think it is that way BECAUSE ${argument}, ${quote}, etc"

And no, it is not unrelated to cdi-1.0.

Another argument why we need further clarification. If you get the BeanManager from JNDI then according to your interpretation you would like to get different results for getBeans() depending on what? How would that ever work? Please shed some light, I don't get it.

I think we would need to add some BeanManager#getBeans(injectionclass, type, qualifiers) + resolve with the same + getReference ...
We do not have all that currently.

> From the EE-6 umbrella spec referenced in CDI:

What you quoted is completely unrelated to modularity in CDI 1.0

Btw, I do agree with you that we need to get a common understanding about how Modularity should work. The BDA approach was way too restrictive but a flat structure doesn't work neither.

Also the CDI spec prominently uses the terminus tecnicus 'bean' for 5 different things:

• Bean<T>
• the class which gets scanned and might lead to 0..n Bean<T>
• the Contextual Reference
• the Contextual Instance
• the Type on the Injection Point

Even in the aforementioned paragraph 5.1 many those 5 meanings are perfectly mixed up.

Come on Jozef, do your homework

From the EE-6 umbrella spec referenced in CDI:

"EE.6.2.4.7 Context Class Loader
This specification requires that Java EE containers provide a per thread context class loader for the use of system or library classes in dynamically loading classes provided by the application. The EJB specification requires that all EJB client containers provide a per thread context class loader for dynamically loading system value classes. The per thread context class loader is accessed using the Thread method getContextClassLoader.
The classes used by an application will typically be loaded by a hierarchy of class loaders. There may be a top level application class loader, an extension class loader, and so on, down to a system class loader. The top level application class loader delegates to the lower class loaders as needed. Classes loaded by lower class loaders, such as portable EJB system value classes, need to be able to discover the top level application class loader used to dynamically load application classes."

This will work perfectly fine without breaking any specs.

> Let's say this is your view and is one of n possible interpretations of the spec wording.

Then it's the only correct interpretation. Read section 5.1. It specifies what I described above. At the same time it does not say anything about TCCL and classloaders in general which you are referring to. I don't think we can proceed further with this issue without clear understanding of how modularity is supposed to work in 1.0

> In other words, CDI contexts are never isolated between bean archives.
I don't get that. Where do you read that I like to do that?

What I was talking about was that you always see only exactly 1 'slice' of a context for each Thread. All users share the same SessionContext, but still each request can only see the contextual instances of the single currently active session of each request.

The same would happen for webapplications. Each request knows to which webapp it belongs. And a single request can only belong to exactly one single webapp! So he will only see the @ApplicationScoped contextual instances of this very webapp the request is for.

> Firstly, here is how the modularity work in CDI:
Let's say this is your view and is one of n possible interpretations of the spec wording.

Due to the well defined TCCL behaviour in the EE umbrella spec it is perfectly viable that A might see B IF it is invoked in a request of the webapp containing A. So technically from the EE spec there is NO such restriction you mentioned. It's just easier for a container vendor to implement.

And your example is also perfectly broken from a user experience pov!
If you inject X in a shared jar you would get another contextual instance than injecting X in a JSF backing bean that way! Hell, this is SICK SICK SICK! No user would be able to use that stuff!

I have a �@Inject User usr; in my MailFormular backing bean and the same code in my MailService and would get 2 DIFFERENT users? You're kidding me, right?

The are only 2 practical ways to do this properly for users:
1.) restrict any @Specializes or @Alternative of an interface to the visibility area it got defined in. In other words if you have a User interface in a shared jar in your EAR we disallow @Specializes or @Alterative in any WAR. But again, this is NOT defined in CDI-1.0 yet!

2.) use a proper proxy which only proxies the injection point type (in our case X) and not only resolve the contextual instance but also the proper Bean<X> dynamically on each invocation IF it got injected into a 'broader scoped bean'. And here we come back to my first argument: by keeping the specified behaviour of CDI-1.0 as 1 per webapp we would not have any 'broader' scope in CDI and thus we dont need to deal! We could introduce all the necessary handling in CDI-1.1 together with the broader @EnterpriseApplicationScoped.

Another point: who likes to go to all the other spec leads like JPA and most important JSF and confess that we messed up? Especially who gonna tell Ed that he cannot drop JSF ManageBeans because we have no replacement for his ����JSF @ApplicationScoped which exists since 10 years and he finally agreed to get rid of?

What you propose is inconsistent with the way CDI contexts work. Currently, there are never two or more contextual instances of the same normal scoped bean injectable at the same time. In other words, CDI contexts are never isolated between bean archives.

You are mixing way too many things here. Firstly, here is how the modularity work in CDI:

Let's have two bean archives: A and B. Module A is accessible from B (A it might represent a shared library in an ear). Module B is not accessible from A (B it might represent a web app).

Let A define the following classes:

public interface X {}

public class A implements X {}

Let B define the following class:

@Alternative
public class B extends A {}

Class B is an enabled alternative in module B. Alternatively, B may be a specializing class (not alternative at all).

Now suppose there are classes Foo and Bar, each of them injecting X, Foo is located in module A and Bar is located in module B.

If Foo invokes a method on the injected instance, it will always be invoked on an instance of A (and not instance of B). if Bar invokes a method on the injected instance, it will always be invoked on an instance of B. This is regardless of scope of bean A and B (no matter whether client proxies are used or not).

There is no randomness and there is not ClassNotFoundException.

Oki to pick up that stuff again

@StuartDouglas:
> ... beans that execute within the same application.
Too bad it's neither in the CDI nor the EE spec defined what they mean with application. Both sometimes refer to web-applications and sometimes to enterprise-applications. It's just not clear.

@PMuir From the historical perspective. I read through the very early mails in the webbeans dev mailing list and the original intention seems to have been to glue together JSF and EJB. And as such the CDI scopes were meant as replacement for JSF scopes. All the EAR stuff finds a first mentioning in spec drafts in middle 2008. Now guess how JSF ApplicationScoped behaves? Exactly, 1 per JSF Application == 1 per webapp. With other words. There exists a defined behaviour for ApplicationScoped beans in Java EE since 10 years, and it is 1 per webapp!

Oki, lets take aside how we name that baby. The real problem is not how to cope with @ApplicationScoped, but how injecting into anything which has a scope bigger than some class visibility would work. The biggest unique visibility area is a single web-application. Thus we are talking about any scope 'bigger' than 1 per webapp.

It doesn't matter if this is @EnterpriseApplicationScoped or a @Statefuf EJB which is shared across the whole EAR - the underlying problem is the same!
And just to be clear: the containers I tested so far just blow up with the above mentioned scenario.

Oki here it goes.

The scenario is as following

• A shared jar with interface X and @EnterpriseApplicationScoped public class A implements X and an @EnterpriseApplicationScoped public class MailService { @Inject X;.
• webapp1 with @SessionScoped public class BackingBean1 { @Inject X x;
• webapp2 with @Specializes public class B extends A and @SessionScoped public class BackingBean2 { @Inject X x;

a.) I've now talked with lots of different folks, including JSR spec leads, and NO ONE did expect that behaviour.

b.) what proxy will be used for the injection point in MailService#x ? Most containers atm just inject a proxy with the Bean of the first request. If webapp2 gets accessed first, then it will create a contextual instance of MailService and the injection point will be filled with the proxy for B. If now a request from webapp1 arrives then the proxy will return an instance of B which will cause a ClassNotFound exception or similar. Because webapp1 cannot see class B. In the best case you will 'only' randomly end up with the wrong class...
This is btw the same if you inject a @SessionScoped or @RequestScoped bean into a bean with a larger scope than 1 per webapp. @Specializes and @Alternative beans will be randomly broken for any injection point of a bean with a broader scope than 1 per webapp.

So there are 2 broken situations with most implemented proxies atm
1. some webapps might get classes/impls which dont belong to them
2. some webapps might get NO @Alternative or @Specializes despite being configured

This could perfectly get fixed by such proxies by just implementing the injection point type and do getBeans(injectionPointType) + resolve the instance. But this is not defined that way in CDI as Jozef pointed out. Currently the proxies contain the Beans, so we have no chance to do this properly in a spec conform way for CDI beans. The easiest solution would be to just interpret @ApplicationScoped as 1 per webapp and we are done.

Jozef, could you please also describe your preferred way?

Afair it was 2 options:
Option a.) just disallow @Specializes and @Alternatives for all beans defined in a shared jar. Regardless of it's scope.
Option b.) inject only beans defined in the shared jar into another bean of a shared jar. E.g. MailService would always get an instance of A injected. Imo this is pretty crucial as @Inject X x; in a JSF backing bean would give you a different contextual instance (even of a totally different type) than the same code @Inject X x; in the MailService.

coming back to Stuarts comment:
> "The application context is shared between all servlet requests"
Ok, if you take it so word for word: in this case, since it doesn't say 'per EAR', we obviously must share the ApplicationContext even across different EARs on the same Server? See, it doesn't specify the EAR in this paragraph, so the only specific definition is in 2.4.1.

@Jozef: I think we already clarified somewhere that events must only be sent to active Contexts. This e.g. happens if you try to send an event in a ServletFilter to a JSF related Context.

There is a similar issue related to events. I am not sure if the proposed solution for the @ApplicationScoped issues fixes the events issue implicitly or a clarification of the Events chapter is needed. The issue follows:

Should a web application bundled within an ear should be notified of an event fired by another web application bundled within the same ear? The observer resolution algorithm should take bean visibility into account and notify only those observer methods from whom the event firer is visible.

Yes stu, I confused the paragraphs. What I meant was

> 2.4.1. Built-in scope types
> The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in Section 6.7,
> “Context management for built-in scopes” represent the standard scopes defined by
> the Java Servlets specification.

which clearly says 1 contextual instance for each webapp.

(Opps, when I opened this the history tab was open rather than comments, and I did not realise that this had already been said)

The Final Release of JSR-299 does not define anything to do with @ApplicationScoped in 6.5.2.

@ApplicationScoped is defined in 6.7.3 and states: "The application context is shared between all servlet requests, web service invocations, EJB remote method invocations,
EJB asynchronous method invocations, EJB timeouts and message deliveries to message-driven beans that execute within
the same application. The application context is destroyed when the application is shut down."

This means that @ApplicationScoped is shared over a whole ear, and is not per war (there may not even be a war in the ear).

Gerhard, please can you clarify how we can change the current proposal in order to remove the non-portability clause. We can't make changes to the EE spec here.

pete - no there was a different statement:

> "Therefore I would follow Marius suggestion and [...] add a clause indicating that non-portability is an issue here ..."

just specifying a recommendation (as suggested afterwards) isn't enough (imo)

... that was the reason for my answer.

Altering issue title and changing to clarification to reflect outcome of design discussion.

As we are all now in consensus, I will draft a proposed change to the CDI spec which clarifies the behaviour of @ApplicationScoped in ears.

But most old EE servers (JBoss4 and 5 are perfect examples for this, as are the old WebLogics) ship with almost no isolation at all it seems! I actually never understood why they behave this way as default!

Believe it or not, older versions of JBoss AS (than 4) did provide more isolation by default, but by user request the isolation was downgraded. Also worth pointing out that JBoss AS 4 and 5 did support much stronger isolation if you enabled it (we always recommended you did with Seam, and enabled it automatically with Weld so I always forget this was the default!).

@Marius: A Bean can only be used in a shared library if it's type is available on the shared classpath too. E.g. in a ejb-jars lib. And even if one webapp uses an @Alternative which is only available in this very one webapp, then there is no problem. Because injecting an @ApplicationScoped bean will still give you the contextual reference (the proxy). They simply refer to different contextual instances. There is really not much difference to a @SessionScoped bean of which it's class is in a shared ejb-jars lib.

I'm a little lost in this sentence... What are you trying to say?

Jens/Marius, I think your point is a very reasonable one for the spec. Of course, we would need an FAQ explaining the details of this

Mark, please take this comment to the EE expert group, as you know we can only decide on CDI here This proposal is certainly implementable, no concerns there.

Gerhard, we all agree with this rhetoric here (no real need to repeat it), we just need to find a solution that (a) makes sense technically and (b) works in the environment we are in. What is proposed does make sense (to me) and does work technically except in the case that people use non-isolated classloading, which EE keeps as an option for backwards compatibility.

IOW what we have is a solution that makes sense with the recommended deployment model (isolated classloading), but we need to include, in the spec, a note about non-portability for the backwards compatible non-isolated classloading case.