1. The discovery mechanism of (ejb )cdiunit (Beandetection)

The detection works by doing some initialisations and afterwards running a loop.

Manipulated data

The following sets of data are used/manipulated:

Name	Type of Elements	Function
classesToProcess	Class	the current set of classes to process
discoveredClasses	Class	the classes as found to be used as CDI-Beans
classesProcessed	Class	the classes already processed. They may not be found in classesToProcess anymore
classesToIgnore	Class	classes which may not be added to classesToProcess, this set is initialized by The Type of fields of the testclass and its superclasses annotated by @Mock
cdiClassPaths	URL	These can describe: directories containing binary classfiles (i.e. target/classes, target/test-classes) all jars in the classpath containing a beans.xml.
extensions	Extension	package: javax.enterprise.inject.spi, later given back as result of getExtensions of the Deployment-Object
beansXml	BeansXml	as described above

The Algorithm

• The detection works inside a loop which runs as long as classesToProcess is not empty.

• For all classes in classesToProcess, which are refered to by an entry of cdiClassPaths or are Extensions and can not be found in classesProcessed and classesToIgnore

• the class is added to discoveredClasses, if it is no annotation

• is added to extensions, if it is derived from Extension

• The Annotations of the class are analyzed

Annotation	Effect
Interceptor	leads to adding the class to beansXml.interceptors
Decorator	leads to adding the class to beansXml.decorators
Stereotype and Alternative	leads to adding the class to beansXml.enabledAlternativeStereoTypes
AdditionalClasses	classes found in the value-array are added to classesToProcess
AdditionalPackages	for all classes found in the value-array: all classes which can be found in the package of the class are added to classesToProcess
AdditionalClasspaths	for all classes found in the value-array: all classes which can be found in the classpath of the classes are added to classesToProcess. Because of the restriction to cdiClasspaths, this means, that only classes in Jarfiles containing beans.xml are really subsequently handled.
ActivatedAlternatives	for all classes found in the value-array are added to classesToProcess and to beansXml.enabledAlternatives
each annotation itself	is added to classesToProcess, if it does not have the package org.jglue.cdiunit.

• All superclasses of the class are added to classesToProcess
• The types of all fields which are annotated with @Produces or @Inject are added to classesToProcess
• The types of all methods which are annotated with @Produces or @Inject are added to classesToProcess
• the class is added to classesProcessed.

Inconsistencies

• only classes of fields of the testclass annotated with @Mock are ignored. If you try to mock beans using this annotation at fields of helping beans, the corresponding class is given to Weld which at last leads to an error produced by the validator.
• Since CDI 1.1 beans.xml is not necessary to denote a ClassPath containing CDI-Beans. Beans in such Jars can never be included in a test-container.
• The algorithm of adding classes by inspecting @Inject and @Produces can sometimes help, sometimes not:
  • classes of fields and methods annotated by @Inject are automatically added to the container. This is reasonable, because these fields must be initialized by the container in any kind. But this automatism helps only, if that type is no abstract-class or interface. The same holds, if the class normally is created as subclass.
  • classes of fields and methods annotated by @Produces are further analyzed and added as classesToProcess. This is only necessary, if an injection of a class of that type is found. There is also the danger, that the added classes might not be necessary for injection, but itself leads to a tree of classes to process which the test-developer initially did not intend to add to the testing container.
• Parameter-Injects by producer and Constructors are not considered.
• A problem with weld, but what should be solved by a test-environment is: If you replace classes by Alternatives in your test, though the original class will not be instanciated, the weld-validation mechanism will check it's injects.