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

Mark Struberg struberg at yahoo.de
Fri Dec 23 11:09:03 EST 2011



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
>> 
>> 



More information about the cdi-dev mailing list