[cdi-dev] easy solution for class visibility checks?

[Pete Muir]

I think I read this as "a jar is a bean archive" NOT "a bean archive is a jar"… IOW it's requiring a jar to be a bean archive, but not vs versa, but I think that is just my interpretation. So I think we need to tidy this language up for sure, as I 100% agree this is too restrictive (and I always interpreted the spec to mean a bean archive is a "module"). Can you file a JIRA so we don't loose this?

On 23 Dec 2011, at 16:09, Mark Struberg wrote:

> 
> 
> Imo the spec is pretty clear about BDAs:
> 
> 12.1. Bean archives 
> Bean classes of enabled beans must be deployed in bean archives. 
> 
>     * A library jar, EJB jar, application client jar or rar archive is a bean archive if it has a file named beans.xml in the 
> META-INF directory. 
>     * The WEB-INF/classes directory of a war is a bean archive if there is a file named beans.xml in the WEB-INF directory 
> of the war. 
>     * A directory in the JVM classpath is a bean archive if it has a file named beans.xml in the META-INF directory. 
> 
> 
> 
> So this is pretty clear to me:"jar ... is a bean archive (BDA) if it has a file named beans.xml..."
> 
> 
> 
> LieGrue,
> strub
> 
> 
> ----- Original Message -----
>> From: Pete Muir <pmuir at redhat.com>
>> To: Mark Struberg <struberg at yahoo.de>
>> Cc: Ales Justin <ajustin at redhat.com>; cdi-dev <cdi-dev at lists.jboss.org>
>> Sent: Friday, December 23, 2011 1:54 PM
>> Subject: Re: [cdi-dev] easy solution for class visibility checks?
>> 
>> 
>> On 22 Dec 2011, at 23:08, Mark Struberg wrote:
>> 
>>>   Yes, it's hard to get right - but the BDA is broken as well. I'd 
>> say it's even more heavily broken than just letting it out.
>>> 
>>>   1.) The major reason is that 1 jar == 1 BDA as per the current spec. This 
>> is just way too restrictive and doesn't fit into any existing modularity 
>> system, because they either split inside the jars (OSGi exported vs not 
>> exported) or way outside the BDA (all jars in WEB-INF/lib of a webapp definitely 
>> belong to the same 'module'.
>> 
>> I don't interpret the spec like this, can you say why you come to this 
>> conclusion? (spec sections/quotes)
>> 
>>> 
>>>   2.) A few CDI tricks don't recognize the BDA (e.g. @Specializes) but 
>> still will be broken if they hit _real_ module boundaries. BDA is not a solution 
>> for those.
>> 
>> I don't think this is a problem with bean archives, but with @Specializes.
>> 
>>> 
>>> 
>>>   3.) 99% of all beans in Seam are annotated with @DefaultBean. Guess what 
>> this 'DefaultBean' does? It 'works around' the BDA restriction 
>> and thus breaks a lots of things. Why? Because you cannot work with this BDA 
>> stuff in place. So while you are telling me that BDA is the solution, your folks 
>> are blasting it away right now ;)
>> 
>> No, it doesn't work around bean archives, it works around alternatives, 
>> which we all know don't work too well from CDI 1.0.
>> 
>> So far you aren't convincing me that bean archives are broken, but that that 
>> 
>> 
>> 1) we have a problem with global enablement of alternatives (which we know)
>> 2) we have a problem with @Specializes and modularity (which we know)
>> 
>> :-)
>> 
>>> 
>>> 
>>> 
>>>   But I think we'll finally come up with a solution if we take the time.
>>> 
>>> 
>>>   LieGrue,
>>>   strub
>>> 
>>>