We had this discussion in another issue where we discussed about @ApplicationScoped vs @EarScoped (which does not yet exist) in CDI-129. We could make our live easy if we say that @ApplicationScoped (which is the vast majority of beans) is per webapp (+ one for the 'shared' stuff like JMS), because every WebApp has it's own BeanManager anyway.
Then we can go on and say that 'an @EarScoped bean must only be specialized, alternated, etc in a library which is accessible to all @ApplicationScoped beans'. Which means a shared ejb-jar lib in a EAR.

For clarity, specialization should be seen across bean archives, this is a bug in Weld.

Mark, your comment is not really relevant to the spec discussion here, it depends on the implementation approach taken.

Not really. If you would define that @ApplicationScoped beans are 1 instance for all webapps, then of course no @Specializes sitting in a WAR WEB-INF/classes would be possible. Because this specialisation implementation (class visibility) is only available from that very webapp. I just have no idea how we could spec that in a way which would be implementable without breaking other specs (namely the EE spec).

Mark, that assumes that you have one BeanManager per web-app, this is not a requirement of the spec. Like you say, this is very hard to specify, and also hard to explain. It's simple enough to clarify that this must happen, in fact this is only an issue at all because there is a bug in Weld.

Even if you have 1 BeanManager for the whole EAR doesn't change anything that you cannot have both behaviours at a time! At least not with a proper classpath isolation which is recommended by the EE spec.
Either
a) make war local classes @Specializes @AppicationScoped beans from a shared ear-lib, or
b) have @ApplicationScoped being 1 per EAR.

both at the same time would require that no class isolation exists - and I hope we are d'accord that this is not anything we would suggest and even more - not make it a required behaviour

I was suggesting a situation when you have >1 BeanManager per webapp - the point is that this is not specified so we can't build on assumptions about how BMs are structured.

here is an example of such a problematic scenario

• EAR with webapp1 and webapp2
• EAR contains @ApplicationScoped MailService (in a shared ejb-jar)
• webapp2 contains @Specializes MyOtherMailService extends MailService
• we have proper ClassLoader isolation between webapp1 and webapp2

now we use @Inject MailService in webapp1 and webapp2,

• what do they get?
• what if we shutdown webapp2 programmatically?

No impl specifics around here, just pure specc issues imo...

2 side notes:

a.) Imo 'across bean archives boundaries' is not the real problem but 'across class visibility boundaries' is.
One can argue that this means the same, but 2 JAR files in the same WEB-INF/lib of webapp1 cause absolutely no problems. Those problems only arise if we hit class visibility boundaries imo.

b.) This not only hits @Specializes but also @Alternative, interceptors, decorators, etc

Defer visibility issues.