Container Building Workflow

In the preceding pages of this section of the componentsthere has been

little to saywhere the various files and classes should be located. This

is because thisdepends on the application, library or framework you want

to usethe container in. Looking at how the container is configured and built

in theSymfony2 full stack framework will help you see how this all fits

togetherwhether you are using the full stack framework or looking to use

the servicecontainer in another application.

In the preceding pages of this section,there has been little to say about

where the various files and classes should be located. This is because this

depends on the application, library or frameworkin whichyou want to use

the container. Looking at how the container is configured and built in the

Symfony2 full stack framework will help you see how this all fits together,

whether you are using the full stack framework or looking to use the service

container in another application.

The full stack framework uses the ``HttpKernel`` component to manage the loading

of service container configuration from theapp levelandfrombundlesas well

as with the compilation and caching. Even if you are not usingthe``HttpKernel``

it should give you an idea ofa way oforganising configuration in a modular

oftheservice container configuration from theapplicationand bundlesand

also handles the compilation and caching. Even if you are not using ``HttpKernel``,

it should give you an idea ofone way oforganizing configuration in a modular

application.

Working with cachedcontainer

Working with cachedContainer

Before building the container a cached version is checked for. The ``HttpKernel``

has a debug setting, if this is false then the cached version is used if it

exists. If debug is true then the:doc:`cached configuration is checked for freshness<components/config/caching>`

and the cached version of the container used if it is. If not then the container

is built from the app level configuration and the bundle's extension configuration.

Before building it, the kernel checks to see if a cached version of the container

exists. The ``HttpKernel`` has a debug setting and if this is false, the

cached version is used if it exists. If debug is true then the kernel

:doc:`checks to see if configuration is fresh<components/config/caching>`

and if it is, the cached version of the container is. If not then the container

is built from the application-level configuration and the bundles's extension

configuration.

Read:ref:`Dumping the Configuration for Performance<components-dependency-injection-dumping>`

for more details.

Applicationlevelconfiguration

Application-levelConfiguration

Application level config is loaded from the ``app/config`` directory. Multiple

files are loaded which are then merged when the extensions are processed. This

allows for differentconfig for different environments e.g. dev, prod.

allows for differentconfiguration for different environments e.g. dev, prod.

These files contain parameters and servicesto be loaded directly into

These files contain parameters and servicesthat are loaded directly into

the container as per:ref:`Setting Up the Container with Configuration Files<components-dependency-injection-loading-config>`.

They all contain config to be processed by extensions as per:ref:`Managing Configuration with Extensions<components-dependency-injection-extension>`.

They also contain configuration that is processed by extensions as per

:ref:`Managing Configuration with Extensions<components-dependency-injection-extension>`.

These are considered to be bundle configuration since each bundle contains

an Extension class.

Bundlelevelconfig withextensions

Bundle-levelConfiguration withExtensions

By convention each bundle contains an Extension class which is in the bundle's

Dependency Injection directory. These are registered with the ``ContainerBuilder``

when theKernel is booted. When the ContainerBuilder is:doc:`compiled<components/dependency-injection/compilation>`

theapplevelconfig relevant to the bundle's extension is passed to the Extension

which also usually loads its own config file(s), typically from the bundle's

``Resources/config`` directory. Theapplevel config is usually processed with

a:doc:`Configuration object<components/config/definition>` also stored in the

bundle's ``DependencyInjection`` directory.

By convention, each bundle contains an Extension class which is in the bundle's

``DependencyInjection`` directory. These are registered with the ``ContainerBuilder``

when thekernel is booted. When the``ContainerBuilder`` is:doc:`compiled<components/dependency-injection/compilation>`,

theapplication-levelconfiguration relevant to the bundle's extension is

passed to the Extensionwhich also usually loads its own config file(s), typically from the bundle's

``Resources/config`` directory. Theapplication-level config is usually processed

witha:doc:`Configuration object<components/config/definition>` also stored

in thebundle's ``DependencyInjection`` directory.

Compiler passes to allowinteraction betweenbundles

Compiler passes to allowInteraction betweenBundles

:ref:`Compiler passes<components-dependency-injection-compiler-passes>` are

used to allow interaction between different bundles as they cannot affect

each others configuration in the extension classes. One of the main uses is

to process tagged services, allowing bundles to register services to picked

up by otherbundle, such as Monolog loggers, Twig extensions and Data Collectors

up by otherbundles, such as Monolog loggers, Twig extensions and Data Collectors

for the Web Profiler. Compiler passes are usually placed in the bundle's

``DependencyInjection/Compiler`` directory.

Compilation andcaching

Compilation andCaching

After the compilation process has loaded the services from the configuration,

extensions and the compiler passes it is dumped so that the cache can be used

next time and thedumped version then used duringthe request as it is more

efficient.

extensions and the compiler passes, it is dumped so that the cache can be used

next time. Thedumped versionisthen used duringsubsequent request as it

is moreefficient.