Api Logger Bundle Laravel Package

Getting Started

Since this is a sportnco internal bundle with zero dependents and stars, treat it as an internal-first package — expect thin docs and behavior driven by the Sportnco codebase conventions rather than generic Symfony best practice.

Where to look first (in this order):

1. composer.json in the repo — check require for the minimum Symfony version (this bundle was almost certainly built against Symfony 3.x/4.x-era APIs; verify the symfony/http-kernel constraint before installing).
2. DependencyInjection/Configuration.php — this is the single most important file. It tells you every tunable knob (log destination, sampling, redaction rules, header allow/deny lists).
3. EventListener/ or EventSubscriber/ — you'll find the kernel.request / kernel.response / kernel.exception hooks that do the actual logging.
4. Resources/config/services.xml (or .yaml) — reveals the service IDs you'll inject/override.

Minimal install:

composer require sportnco/api-logger-bundle

Then register the bundle in config/bundles.php:

return [
    // ...
    Sportnco\ApiLoggerBundle\ApiLoggerBundle::class => ['all' => true],
];

First use case: dump the default config to see what actually runs out of the box:

php bin/console config:dump-reference api_logger

If that command fails, the bundle's extension alias isn't api_logger — grep the repo for getAlias() in the DependencyInjection directory to find the real one. Assume nothing: internal bundles frequently alias to the vendor short name.

Start with a single request through your app in dev and tail var/log/dev.log — the bundle almost certainly logs to a dedicated Monolog channel, so check monolog.yaml for a channel named api_logger or similar.

Implementation Patterns

Pattern 1 — Decorating/overriding the listener for custom payload shaping. Most bundles like this log raw request/response bodies. In practice you'll want the logged body sanitized (passwords stripped, PII masked). The idiomatic approach is to override the bundle's service in config/services.yaml rather than fork:

services:
    sportnco.api_logger.event_listener.request:
        class: App\Logging\CustomApiLogListener
        arguments: ['@logger', '%api_logger.config%']
        tags: [{ name: kernel.event_listener, event: kernel.request, priority: 32 }]

Check the original service definition for the exact service ID and tags before overriding.

Pattern 2 — Context enrichment via Monolog processors. Don't hook into kernel.request a second time to add user/tenant IDs. Register a Monolog processor for the bundle's channel — this composes with whatever the bundle writes:

monolog:
    channels: [api_logger]
    processors:
        - { class: App\Logging\TenantContextProcessor, channels: [api_logger] }

Pattern 3 — Sampling / filtering for production. If the bundle exposes a sample_rate or should_log callback in config, use it. If it doesn't, wrap the destination itself — a custom handler is cleaner than patching the listener. For high-traffic APIs, logging every 200 OK response is a mistake; target error/5xx responses plus a fraction of successes.

Pattern 4 — Routing integration for scope control. If the bundle keys off _route, use route attributes or a RequestMatcher to exclude health checks, metrics endpoints, and static assets rather than filtering after the fact:

api_logger:
    paths:
        - { path: '^/api', methods: ['POST', 'PUT', 'PATCH', 'DELETE'] }

Pattern 5 — Async dispatch. If the bundle writes to Doctrine (an ApiLog entity), and the DB write happens inline on kernel.response, you'll add latency to every request. Verify the write path isn't synchronous — if it is, either disable the Doctrine persister and log to a file instead, or wrap the write in a kernel.terminate listener so it runs after the response is flushed.

Pattern 6 — Testing. Kernel event listeners are easy to unit test: dispatch a RequestEvent with a mocked Request and assert on the log call. Do this rather than spinning up a full WebTestCase — internal bundles often have surprising container wiring that's painful to reproduce in test kernels.

Gotchas and Tips

Symfony version drift. Bundles from Sportnco's era frequently rely on ContainerAwareEventDispatcher or symfony/http-kernel < 5.0 internals. Run composer why-not symfony/framework-bundle 6.* immediately after install — if the constraint pins you to an EOL Symfony, that alone may disqualify the package for new work.

Service visibility surprises. Symfony 3.4+ made services private by default; older bundles assume public services. If the bundle works in dev but fails in prod after cache warmup, this is almost always why. The fix is a compiler pass or explicit public: true — but you should flag it upstream rather than patch inline.

Double-logging when a response is streamed. Listeners on kernel.response that call getContent() on a StreamedResponse throw. If your API uses streaming (SSE, file downloads), verify the bundle guards for StreamedResponse — many don't, and you'll get LogicException in prod only under specific endpoints.

Sensitive-data leakage in request bodies. Internal bundles commonly log the raw POST body. That means passwords, tokens, and card data hit your log aggregation. Audit Configuration.php for a sanitize or redact option before enabling in any environment that ships logs off-host. If it's absent, override the listener — don't trust the default.

kernel.exception ordering. If the bundle registers an exception listener to log failures, its priority vs Symfony\Component\HttpKernel\EventListener\ErrorListener matters. Too low and you log the raw exception before it's converted to a Response; too high and you miss it. Check priorities in services.xml, and prefer logging in a TerminateEvent where possible.

Monolog channel misconfiguration is silent. If the bundle writes to api_logger but Monolog has no such channel declared, logs vanish without a warning in some Symfony versions. Confirm with php bin/console monolog:config:dump (or debug:container monolog.logger.api_logger).

No maintenance = no CVE coverage. With zero dependents and no stars, this package is likely abandoned or purely internal. Pin the composer version exactly ("sportnco/api-logger-bundle": "1.2.*"), vendor the source into your repo if you can, and plan for a fork if you need a fix. Don't assume composer update will be safe.

Extension points worth knowing. If the bundle exposes a loggable_entity or storage service ID, that's your extension seam — swap for an SQS/Redis/file logger without touching the listener. If it doesn't, the only clean extension point is kernel.event_listener priority juggling, which is fragile. Document which path you took; the next developer will need it.