Annotation Interface EnableBroadleafAutoConfiguration


STOP. This is probably not the annotation you want currently.

Broadleaf is progressing towards the Spring Framework's methodology of bean definition and priority. The following are the different phases Broadleaf will progress through with this goal in mind.

Phase 1 (current) - Broadleaf framework XML configuration is separated out into site and admin specific directories within /blc-config in at least one module. For this reason, you must use EnableBroadleafAdminAutoConfiguration and EnableBroadleafSiteAutoConfiguration for admin and site applications respectively.

Phase 2 - Medium level of effort - All Broadleaf modules have had ConditionalOnAdmin applied to admin specific beans and the XML configuration files have been moved to just /blc-config. You can now use EnableBroadleafAutoConfiguration for both site and admin applications, however it isn't a requirement to migrate EnableBroadleafAdminAutoConfiguration and EnableBroadleafSiteAutoConfiguration as they also include root /blc-config in addition to the admin and site specific directories.

Phase 3 - Very high level of effort - All framework bean definitions in Broadleaf have been migrated to JavaConfig or annotation based configuration and have applied a Spring Boot Autoconfiguration ConditionalOn... annotation that defines the condition on which it should be registered. The most common of these will be ConditionalOnMissingBean which will check if a client application has registered a bean of this type, and if so the framework bean won't get registered. Additionally all Broadleaf module configuration is bootstrapped using spring.factories which references a Configuration classes that contains Bean definitions and a ComponentScan of its entire package to pick up any other beans defined using annotations. The Configuration classes referenced by spring.factories are discovered by using the Spring Boot Autoconfiguration EnableAutoConfiguration annotation. Client applications will now be required to migrate to using EnableAutoConfiguration instead of EnableBroadleafAutoConfiguration, although this annotation could be modified to compose EnableAutoConfiguration to mitigate this requirement. When modules are bootstrapped by EnableAutoConfiguration/spring.factories those bean definitions are placed in a deferred registration list so they will get registered last, so by the time framework beans are evaluated for registration all client beans that override framework beans have already been registered and the framework bean's ConditionalOnMissingBean annotation will prevent it from getting registered and consequently overriding the client bean. Also, in order to facilitate commercial framework modules overriding beans defined in community framework modules, the Order annotation is leveraged in commercial modules with a priority set higher than the default Ordered.LOWEST_PRECEDENCE; this could be simplified by using annotation composition on Order to create something like FrameworkPriority. At this phase there will be little to no XML configuration remaining in the Broadleaf Framework as XML configuration does not support these conditionals. Also, the use of bean IDs will be severely reduced as they generally aren't required for bean overriding decisions when using ConditionalOnMissingBean. Bean IDs will still be used for the situations that Spring has defined such as having multiple DataSource beans all with unique IDs and one marked as Primary for injections where a Qualifier isn't specified.

Bootstraps Broadleaf configuration XML using a glob import.

This import utilizes the FrameworkXmlBeanDefinitionReader so that framework XML bean definitions will not overwrite beans defined in a project.

Since:
5.2
Author:
Philip Baggett (pbaggett), Brandon Hines (bhines), Nick Crum (ncrum)
See Also: