On 20 Oct 2009, at 01:24, Roberto Chinnici wrote:
>
>
> No it doesn't! Thats the whole point!
>
> Pete of course has implemented this without scanning of non-bean
> deployment archives.
>
Scanning for @Resource at deployment time, not scanning for beans as
such.
Let's step through this, as there seems to be a lot of confusion here
(particularly around new scanning requirements):
* Something which is allowed to perform injection (such as a Java EE
component class or a managed bean *in a bean deployment archive*, so
no *new* scanning here), has an injection point which has @New on it:
@Inject @New Foo foo
where Foo is a class which exists in a module or library which is not
a bean deployment archive.
* When this injection point is registered with the 299 container, it
sees that it doesn't know about Foo as a bean already, so it creates a
new Bean object (e.g. of type NewManagedBean)
* In creating this Bean object, it scans the class for annotations on
fields, methods, constructors and parameters (this I guess is extra
scanning [1])
[1] Scanning a class like this has a very low overhead (at least in
the Sun JDK) when compared to loading class definitions for scanning
for class level annotations (such as @ManagedBean). I offered to do
some profiling on this to back up my assertion, but never got asked to
take it further. Further, an implementor is free to centralise their
scanning and thus lower their overhead further.