Http Kernel Bundle Laravel Package

Getting Started

Before you install anything, read the archive banner. This package is deprecated, archived, and its last release was 2020‑03‑16. It exists to give you a custom HttpKernel for Symfony — a base kernel class plus bundle wiring that lets you override boot/handle behaviour without forking Symfony itself. On any Symfony 5.4+/6+/7 project you almost certainly do not need it; native Kernel, MicroKernelTrait, HttpKernelInterface decoration, and symfony/runtime cover the same ground with maintained code. Treat adoption as a legacy‑integration decision, not a greenfield one.

If you are inheriting a project that already depends on it:

1. composer show m6web/http-kernel-bundle — confirm the installed version and read its composer.json for the Symfony/PHP constraint ceiling. That constraint, not the feature set, is usually what forces a migration.
2. Open vendor/m6web/http-kernel-bundle/ and find the kernel class first. That class — not the README — is the real documentation. Look at which Kernel methods it overrides (boot(), handle(), registerBundles(), getCacheDir()) and which are left as protected hooks for you.
3. Read DependencyInjection/Configuration.php and Resources/config/*.xml|yaml to learn the actual config tree and service IDs. Do not trust blog posts or the archived README for key names.
4. Register it in config/bundles.php (or AppKernel::registerBundles() on older projects) and make your app kernel extend the shipped base class.

First use case: point your front controller at a kernel that extends the bundle's base class instead of Symfony's Kernel, run bin/console cache:clear, and confirm the app still boots. That single change is the whole integration surface for most installations — everything else is behaviour the base class already implements for you.

// src/Kernel.php
// Match the FQCN from vendor/m6web/http-kernel-bundle/ before writing this import.
use Vendor\HttpKernelBundle\Kernel as BaseKernel;

class Kernel extends BaseKernel
{
    public function registerBundles(): iterable
    {
        yield new Symfony\Bundle\FrameworkBundle\FrameworkBundle();
        // ...
    }
}

Implementation Patterns

Keep registerBundles() in your app, not in the base class. The bundle's value is the kernel lifecycle; bundle selection belongs to the application. Every override you add should be justified by a hook the base class does not already provide.

Decorator over subclass where possible. If the only thing you need is custom handling around handle(), prefer a decorator implementing HttpKernelInterface and aliasing it over http_kernel. This is the pattern that survives migration to native Symfony:

final class TracingHttpKernel implements HttpKernelInterface
{
    public function __construct(
        private HttpKernelInterface $inner,
        private LoggerInterface $logger,
    ) {}

    public function handle(Request $request, int $type = self::MASTER_REQUEST, bool $catch = true): Response
    {
        $this->logger->debug('handle', ['uri' => $request->getRequestUri(), 'type' => $type]);
        return $this->inner->handle($request, $type, $catch);
    }
}

Multi-kernel / multi-site dispatch. The historical reason teams reached for this package was running several kernels out of one codebase (one front controller per site, sharing bundles and config). If you inherit that layout, keep the shared pieces in config/packages/ and let each kernel differ only in getCacheDir(), getLogDir(), and registerBundles(). Add a hard rule that no two kernels share a cache directory — that's the number one source of "works locally, breaks in CI" in this setup.

Prefer kernel events to kernel overrides. kernel.request, kernel.response, and kernel.exception listeners give you the same interception points with none of the inheritance coupling. Reach for a Kernel subclass only when you genuinely need something before the container exists.

Functional testing. Boot the kernel exactly as the front controller does; assert against the response, not against kernel internals. With Symfony's test client:

$client = static::createClient();
$client->request('GET', '/health');
self::assertResponseIsSuccessful();

Migration path. Almost everything this bundle does maps onto native Symfony in a few steps: delete the inheritance, move overrides into event listeners or an http_kernel decorator, move multi-site concerns into environment-specific config, and drop the dependency. Do this as a standalone PR before any framework upgrade — mixing the two makes the upgrade diff unreadable.

Gotchas and Tips

• Version ceiling is the real blocker. A 2020 release targets the Symfony 4/5 and PHP 7.x era. Symfony's HttpKernelInterface and Kernel signatures have gained return types since then; subclassing will produce fatal signature-mismatch errors, not warnings. Check constraints before assuming it "just works" on a newer runtime.
• The kernel is not a service you can inject. If you need it in a service, reference the kernel alias, and never call boot()/shutdown() yourself — you'll double-boot and reset the container under a live request.
• Cache and log directory collisions. Nested or sibling kernels that resolve to the same getCacheDir() will silently serve each other's compiled container. Namespace each one by kernel name or environment.
• Console vs. HTTP asymmetry. A package that markets itself as an HttpKernel may not extend the same behaviour to bin/console. Verify commands boot against the same kernel before relying on shared config.
• Reboot semantics. Long-running workers and functional tests that reboot kernels rely on kernel.reset / ResetInterface being wired. Older bundled services often aren't resettable; state leaks between requests.
• Class-name collisions. If the bundle ships a class literally named Kernel, your App\Kernel import resolution gets confusing fast. Always import with an alias.
• Debugging: debug:container --tag=kernel.event_listener, debug:router, and the profiler's request timeline will tell you more than reading the archive. When something behaves differently from vanilla Symfony, diff the shipped kernel class against the framework version you're running — the delta is the bundle.
• Extension points, in order of preference: kernel event listeners → service decoration → compiler pass → kernel subclass override. Every step down that list costs you more at migration time.
• Support posture: zero dependents, no releases in years, no security response. Pin the exact version in composer.lock, add a # deprecated note next to it in composer.json, and put a removal ticket in the backlog the day you touch it.