Re: [cdi-dev] easy solution for class visibility checks?
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(a)redhat.com>
To: Mark Struberg <struberg(a)yahoo.de>
Cc: Ales Justin <ajustin(a)redhat.com>; cdi-dev <cdi-dev(a)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
>
>