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

Ales Justin ajustin at redhat.com
Fri Dec 23 06:02:08 EST 2011

> Yes, it's hard to get right - but the BDA is broken as well.

Agreed, but I think the concept itself is not broken.
Just needs more thought into it.

> I'd say it's even more heavily broken than just letting it out.

As you yourself suggested - via another mechanism - we do need a mechanism to provide proper visibility.
Flat out just won't work. It probably might for 95% cases, aka .war apps, but CDI is more than just that.

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

OSGi still falls into 1 jar / 1 BDA. I don't see why not.
It's just a matter of integration with the OSGi system, letting you scan only truly visible resources.
(or exposing the internals only through service pattern)

> or way outside the BDA (all jars in WEB-INF/lib of a webapp definitely belong to the same 'module'.

Each lib can be a CDI archive, hence its own BDA.

I do agree this falls out a bit of classic CL visibility/modularity.
But that's how the spec defines if, for a reason.
And it's not hard to follow, while inside a container -- CL defines the visibility rules, presence of beans.xml defines the fine grained archives.

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

Imo this is just a matter of better spec.
Putting natural rules into proper wording, which is what we're missing now - hence this CDI JIRA issue(s).

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

I would guess - since I never used it - this was introduced due to AS6' BDA handling, which was not the best.
But from what I worked with using CDI in "real" apps - and it's definitely not a lot, since I don't do that for a living - I never had any issues wrt BDA usage -- specially in AS7.
(ok, there was one, which I just recently fixed in 1.1.4.Final)
@DefaultBean is an exception not a rule, it proves nothing.

> But I think we'll finally come up with a solution if we take the time.



More information about the cdi-dev mailing list