[cdi-dev] easy solution for class visibility checks?
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
* 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..."
----- 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.
More information about the cdi-dev