Sam Ecore Application Manager Bundle Laravel Package

Getting Started

Install

composer require canaltp/sam-ecore-application-manager-bundle

Register the bundle the way your Symfony version expects (it comes from the CanalTP ecosystem, so assume Symfony 3/4-era conventions until the composer.json says otherwise):

// config/bundles.php
SamEcore\ApplicationManagerBundle\SamEcoreApplicationManagerBundle::class => ['all' => true],

Where to look first, in this order

1. Entity/ — this is the heart of the bundle. Look for Application, key/token, and endpoint classes. Everything else (controllers, repositories, DI config) hangs off these.
2. Resources/config/services.yml (or config/services.xml) — confirms the service IDs and bundle alias you'll inject. The alias is usually derived from the bundle name (sam_ecore_application_manager), but verify — CanalTP bundles have been inconsistent.
3. DependencyInjection/Configuration.php — shows every configurable option. Small file, read it fully before wiring anything.
4. Tests/ and any DataFixtures/ — the most reliable documentation for how entities are meant to be constructed and related.

First real use case

Provisioning a consumer of your Sam API. The typical flow is: create an Application, attach one or more endpoint/coverage associations, generate a key, and let your authentication layer validate incoming requests by looking up that key. Get that single happy path working end-to-end in a test before touching configuration.

Implementation Patterns

Treat entities as the integration surface, services as the behaviour. Read Entity/ and Repository/ together; the repository methods are what you'll actually call day-to-day. Inject the manager service via its service ID rather than instantiating entities yourself where a factory/manager exists — key generation and timestamping logic is usually encapsulated there.

Authentication integration. The most common pattern is a listener or guard that reads an Authorization/X-Api-Key header, resolves it to an Application via the bundle's repository, and stamps the authenticated application onto the request/token. Keep that glue in your app, not in the bundle — you want to control failure modes (missing key vs. revoked key vs. wrong endpoint).

Doctrine mapping. If your own application/user entities need a relationship to Application, use @ManyToOne on your side pointing at the bundle entity, not the reverse. Modifying the bundle's mapping (e.g. to add a foreign key back to your User) requires mapping overrides and is a maintenance trap.

Fixture-driven development. Because this package is niche, tests are your specification. Copy the patterns from Tests/ into your own functional tests: build an application, attach endpoints, assert the key authenticates and that a revoked/deleted application does not.

Version pinning. Pin the exact version in composer.json. With no dependents and no stars, upstream is effectively unmaintained for your purposes; a minor bump should not silently rewrite your data model.

Gotchas and Tips

• This is an obscure, likely internal package. Zero stars and zero dependents means no community answers, no Stack Overflow coverage, and possibly no maintainer watching issues. Budget time to read the source rather than search for help. Consider vendoring or forking if it's critical infrastructure.
• Abandonment risk is the headline concern. Before adopting, check the last commit date and open issues against your Symfony version. If it targets Symfony 2.x/3.x, plan for shims (symfony/deprecation-contracts, container compatibility) or a fork.
• Bundle alias mismatch. CanalTP bundles have shipped with inconsistent service/alias naming. Always confirm the alias from DependencyInjection/*Extension.php rather than guessing — this is the #1 source of "service not found" errors.
• Doctrine schema ownership. Run doctrine:schema:validate and inspect the generated migration carefully before running it against a real database. You do not want this bundle silently adding/dropping columns in a shared schema.
• Key lifecycle. Verify whether key regeneration revokes the old key or adds a new one. Test both paths explicitly; the difference matters for clients mid-rotation.
• Debugging. Use debug:container --show-private (or debug:container on older Symfony) to confirm the services are actually registered; if commands or entities are missing, the bundle likely failed to register due to a missing extension/config block, not a code error.
• Extension point that actually works. If you need custom behaviour, favour decorating the bundle's manager service with your own class over patching the bundle. This survives composer update and keeps the fork option open.
• Log at the boundary. Add your own logging around whatever validates keys — the bundle won't tell you why an auth check failed, and you'll need that telemetry the first time a client reports a rejected key.
• Don't assume the description is accurate. "Application bundle" tells you almost nothing; validate against the actual Entity/ contents whether this is a tenant/consumer registry, a key manager, an endpoint catalogue, or all three, before designing around it.