Elastic Path Core Commerce uses a lightweight plug-in architecture based on Spring functionality. This architecture allows you to create plug-ins that work with existing Core Commerce modules, without needing to make any changes to the core application code or configuration files.
The Spring contexts of Elastic Path applications use wildcards to include Spring configuration files from well-known classpath locations. There are two patterns:
The first pattern is for the plug-ins to be included from an
For example, the
elastic-path-servlet.xmlfile in the
<import resource="classpath*:META-INF/elasticpath/conf/spring/plugin.xml"/> <import resource="classpath*:META-INF/conf/ep-core-plugin.xml"/>
The second pattern is for the extensions to be included from a
For example the
import-export-context.xmlfile in the
<import resource="classpath*:META-INF/conf/ep-core-plugin.xml"/> <import resource="classpath*:META-INF/conf/ep-importexport-plugin.xml" />
These statements cause the application to examine all
JARs on the classpath and automatically include any copies of these files.
There are three separate plug-in conventions in these examples:
This is used to automatically import Spring configuration from any
JARon the classpath with a
META-INF/conf/ep-core-plugin.xml. Modules that declare Spring configuration in this location must not rely on any specific order in which their
plugin.xmlfile is processed.
Examples of modules that use this convention are the
ep-messaging-camelmodule, and most Accelerator Kit modules.
This is used to import the
ext-coremodule’s configuration into other
extensionsmodules. The import should always be done after the generic
plugin.xmlimports to allow overriding generic
This is defined in
ep-import-exportto create an extension point that is implemented by the
ep-importexport-plugin.xmlfile in the