jsr342-experts@javaee-spec.java.net

[jsr342-experts] Re: Proposal for global CDI enablement

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Thu, 13 Dec 2012 15:02:01 -0800

Thanks for putting this together, Pete! I think this is a good compromise
that will help the community. I have some questions and some comments...

> Only classes with a bean defining annotation, or with an annotation,
> or meta-annotation, present specified by @WithAnnotations are passed to
> ProcessAnnotatedType observers (the exact semantics are defined by CDI 1.1
> PRD for @WithAnnotations). As mentioned above, if a ProcessAnnotatedType
> is observed for a type without a bean defining annotation, as a result
> of having an annotation present that is specified by @WithAnnotations,
> it may instruct the container to add discover the class as a bean.

I'm trying to understand the impact of this on the implementation.

If I remember correctly, portable extensions are discovered using
java.util.ServiceLoader, is that correct? After discovering
the services during CDI initialization, CDI looks for the
@WithAnnotations annotation and notifies the extension of the
classes it's interested in. That means that CDI must have at
its disposal a list of *all* classes with any annotation the
could ever possibly be specified with @WithAnnotations, is that
right? And even worse, for those portable extensions that don't
use @WithAnnotations, CDI needs to have a list of all classes in
the application, right?

So even though CDI might define many fewer beans by default, it
still needs to be able to find out about all classes in the application,
and in that respect it's the same as CDI 1.0. The reduced overhead is
not in the class scanning or annotation discovery, its in the bean
initialization, right?

> OPEN ISSUE: Should auto-discover be false by default for beans.xml with
> version 1.1. This would mean that adding a beans.xml would have no impact
> on discovery for 1.1 apps, however it is a significant change from 1.0.

There's some potential cost to developers (in confusion) if you change the
behavior when a beans.xml is present, but if you don't think that's a big
issue the default should probably be the programming model you most want
to encourage.

> OPEN ISSUE: Should only scopes for which a CDI context exists be
> considered component defining? This could introduce some thorny edge
> cases, but would address the JSR-330 compatibility issue better.

How does a CDI context come to exist for a given scope?

> OPEN ISSUE: Should we extend auto-discover in
> beans.xml to allow complete disablement of scanning
> e.g. auto-discover="all|bean-defining-annotations-only|none" ?

This seems reasonable, although I would probably name it something like
"beans=all|annotated|none".

> OPEN ISSUE: How should the ProcessAnnotatedType event instruct the
> container to discover a class as a bean? Perhaps something like
> event.discover(clazz)?

I don't understand this issue.

> OPEN ISSUE: Should we integrate this with the package level scanning
> control we have proposed for CDI 1.1?

I'm not familiar with the package level scanning control, but this sounds
like a reasonable approach.