Multiple App Kernel Bundle Laravel Package

Getting Started

This is a Symfony2 bundle, not a Laravel package — so before anything else, understand that it targets a framework that reached end-of-life in 2018. There is no Laravel equivalent to install; the closest Laravel parallel is "several apps sharing one codebase" via separate artisan entry points or domain-based route groups. If you're evaluating this for a Laravel project, stop here and use Laravel's routing/domain features instead. If you're maintaining a legacy Symfony2 codebase, read on.

Minimal steps:

1. Require it through Composer (Symfony2-era, so expect PHP 5.x/7.0 constraints and a very old dependency tree):

   composer require vbardales/multiple-app-kernel-bundle
   

2. Register the bundle in app/AppKernel.php inside registerBundles().
3. Look first at:
   • The bundle's README.md — this repo has 0 stars and 0 dependents, so the README is effectively the only spec you'll get.
   • DependencyInjection/ — to see what services and compiler passes it registers.
   • Any Resources/config/ YAML — to see how an "app" is defined (kernel class, config path, cache dir, routing entry).
4. The mental model: instead of one AppKernel, you get N kernels/apps (e.g. frontend, admin, api) that share vendor/ and common bundles but each load their own config.yml, routing.yml, and cache/log directory — essentially Symfony1's "apps" concept retrofitted onto Symfony2.

First use case: splitting a growing monolith into frontend + admin without duplicating Composer dependencies. You define each app's kernel and config directory, then point separate vhosts (or front controllers) at them.

Implementation Patterns

Per-app directory layout (the core pattern). Expect to organize config by app rather than the default single app/config/:

app/
  config/            # shared parameters, security base, services
  frontend/
    config/config.yml
    config/routing.yml
    FrontendKernel.php
  admin/
    config/config.yml
    config/routing.yml
    AdminKernel.php
web/
  frontend.php       # front controller -> FrontendKernel
  admin.php          # front controller -> AdminKernel

Each kernel only registers the bundles that app needs, and only imports that app's config. Shared bundles and parameters live in app/config/ and are imported by every kernel.

Web server / entry-point wiring. The typical integration is either:

• Separate vhosts — www.example.com → web/frontend.php, admin.example.com → web/admin.php; or
• Path-based — a single front controller that dispatches to the right kernel based on the request path prefix.

Path-based dispatch is more common in these bundles because it keeps one vhost. Look for a request listener in the bundle that selects the kernel; if none exists, you write a small web/app.php that inspects $_SERVER['REQUEST_URI'] and boots the matching kernel.

Console per app. Symfony's bin/console equivalent should be per-app too — a ConsoleKernel per app (or a --app=admin flag) so cache:clear, assets:install, and doctrine:migrations:* targets the correct cache/config. Without this, commands silently operate on the wrong app's container.

Sharing across apps. Put domain code (entities, repositories, business services) in shared bundles, and keep app-specific controllers, templates, and config in the app's directory. This is the same layering discipline you'd use for Laravel modules — shared app/Domain, per-app delivery layers.

Cache and logs isolation. Every app needs its own cache/ and logs/ subdirectory. The bundle should handle this if you pass distinct app names; verify the generated paths in var/ (or app/cache/) before trusting it.

Laravel mental mapping (for context):

Gotchas and Tips

The biggest gotcha is the package itself. Zero stars, zero dependents, a Symfony2 target, and no Laravel relevance means: no community validation, no security review, no maintenance. Treat it as an unvetted internal tool. If the code is small (likely), read all of it and consider vendoring or copying the approach rather than depending on it.

Symfony2 is EOL. PHP 8 will not run this. If you're on a modern stack, the correct move is to migrate off Symfony2 (to Symfony 5/6/7 with the same multi-kernel idea, which modern Symfony supports natively via multiple Kernel classes and framework.cache/framework.router per kernel). This bundle is a bridge for legacy codebases only.

Cache collisions are the #1 failure mode. If two apps share a cache directory, the second booted kernel will read the first's container cache and explode with confusing "service not found" or "class not found" errors. Always confirm the cache dir is derived from the app name, and clear it per app:

php web/frontend.php cache:clear   # or bin/console --app=frontend cache:clear

Kernel selection bugs are silent. If your dispatcher picks the wrong kernel, you'll get a valid response from the wrong app (e.g. admin routes leaking into the public app) rather than an error. Add a health-check endpoint per app that echoes its kernel name and config hash, and assert on it in deployment smoke tests.

Config drift between apps. Because each app has its own config.yml, shared parameters can diverge accidentally. Keep shared values in one imported file and add a test that loads each kernel's container and asserts key parameters match.

Composer conflicts. With an old Symfony2 constraint, adding modern Composer plugins or PHP version pins will fight the lock file. If composer update is off the table, pin the lock file and treat dependency changes as a migration project.

Extension points to inspect:

• The bundle's DependencyInjection/Extension.php — where app definitions are parsed.
• Compiler passes — where kernels/services get tagged per app.
• A request listener (if present) — where kernel selection happens.

Debugging checklist for a "wrong app / blank page":

1. Dump get_class($kernel) in the front controller and confirm it's the kernel you expect.
2. Confirm kernel.cache_dir, kernel.logs_dir, and kernel.config_dir per app.
3. Check routing.yml is imported with the right prefix in the right app.
4. Confirm the vhost's DocumentRoot/rewrite rules point at the correct front controller.
5. rm -rf app/cache/<app>/* and rebuild — stale caches masquerade as code bugs constantly in Symfony2 multi-app setups.

Where it shines: consolidating two or three legacy Symfony2 apps into one Composer install to kill dependency duplication. Where it doesn't: new projects, Laravel projects, or anything requiring PHP 7.4+. For a new multi-surface product, use modern Symfony's native multi-kernel support or a Laravel app with domain-scoped route groups — both are safer than adopting an orphaned bundle.