This document describes changes in the Weld SPI between versions 1.x and 2.0. It also describes changes necessary for an integrator to implement in order for the product to be spec-compliant.

Weld SPI changes

BeansXml.getUrl()

The BeansXml interface, which provides an abstraction over a beans.xml file now contains the following method:

public URL getUrl();

This method has to be implemented by the integrating side. It returns the URL of the beans.xml file. This is necessary for implementing https://issues.jboss.org/browse/CDI-105

See the commit for details.

Executor services and concurrent processing

Weld 2.x uses a concurrent BeanDeployer and Validator by default. It uses the ExecutorServices service which distributes subtasks over multiple threads. The ExecutorServices interface has been expanded. The service is optional and Weld will use its own implementation (with its own thread pool) if no implementation is provided by the integrator. Unless the integrator had been providing ExecutorServices before, there are no changes required.

Injection Services

The injection services SPI has been changed. This includes

• EjbInjectionServices
• JpaInjectionServices
• ResourceInjectionServices

The old versions of the interfaces allowed a resource to be looked up at runtime. For example:

public EntityManager resolvePersistenceContext(InjectionPoint injectionPoint);

These methods did not allow deployment errors to be detected at bootstrap. If a resource was not available to the application, an exception would be thrown at runtime. These methods are now deprecated (and Weld will not use them). Instead of these methods, for each resource injection point Weld now calls this type of method:

public ResourceReferenceFactory<EntityManagerFactory> registerPersistenceUnitInjectionPoint(InjectionPoint injectionPoint);

Weld calls these types of method at the deployment time and obtains an instance of the ResourceFactory for a given resource or receives a deployment error if there is a problem with the resource injection point. Weld won't try to look up a resource for which a factory has not been previously obtained. Therefore, each resource injection point can now be validated and runtime errors avoided.

BootstrapService

The Service interface, which is used by Weld to interact with its environment (integrators), has been extended. The new BootstrapService interface may be optionally implemented should a service require a callback after bootstrap sequence is complete. This is used by services that are used heavily during bootstrap to clean up resources / release memory. This is purely optional and only provided for convenience.

Merging multiple beans.xml files in a flat deployment structure

Bootstrap.parse(Iterable<URL> urls, boolean removeDuplicates)

has been introduced. This methods allows Weld to work properly in a flat deployment (such as arquillian embedded container, Weld SE) if there are multiple beans.xml files with overlapping declarations. The original

Bootstrap.parse(Iterable<URL> urls)

method defaults to false (files are not merged and possible overlap conflicts are reported).

Other required changes

This section lists changes done in the Weld-AS7 integration bundle that are not enforced by changes in the SPI but still these changes are mostly required for the integrator to pass the CDI TCK.

WeldPhaseListener

WeldPhaseListener has been removed. The listener served as a hook for activating / deactivating conversations. In CDI 1.1 (CDI-80) conversations are now available for pure Servlet requests and therefore conversation activation is handled in the WeldListener (which is a Servlet listener).

WeldListener

The Weld (Servlet) listener now requires resource (BeanManager) injection, so it must be registered as a Servlet listener with dependency injection performed.

CDIProvider

CDI 1.1 provides a simplified approach to accessing the BeanManager / CDI container from components that do not support injection. This is done by the CDI class API. The integrating part can either use the implementation provided by Weld core and register it using javax.enterprise.inject.spi.CDIProvider file that is visible to the CDI API classes or use the

CDI.setCDIProvider(CDIProvider provider)

method early in the deployment. Alternatively, an integrating part may provide a specialized implementation such as the one provided by AS7 integration.

Standardized definition/deployment exceptions

If the integrating part detects a definition / deployment error, it should throw one of the standardized exceptions as per CDI-118

Request scope during @PostConstruct callback invocation

CDI 1.1 requires the request scope to be active during any @PostConstruct callback invocation (CDI-219). Weld handles that for CDI managed beans and expects the integrating part to activate/deactivate the request scope for other types of EE components (AS7 example).

Context activation events

CDI now requires an event with qualifiers @Initialized(RequestScoped.class) and @Destroyed(RequestScoped.class) to be fired when the request scope is activated or destroyed, respectivelly. Weld does this for scope activations caused by a Servlet request. Weld expects the integrating part to take the reponsibility for other types of requests (remote invocation, @Timeout invocation, @Asynchronous invocation, message delivery). AS7 example