Activemq Bundle Laravel Package

Technical Evaluation

Architecture fit — poor as a direct dependency. overblog/activemq-bundle is a Symfony bundle, not a Laravel package. Its value is delivered through Symfony's Bundle/Extension/CompilerPass machinery: a Configuration tree built with TreeBuilder, service definitions wired via YAML/XML, and event subscribers that hook into Symfony's kernel. Laravel has no equivalent bundle contract — there is no registerBundles() step, no DI compiler pass, no config-tree validation, and no HttpKernel event lifecycle. Adopting it means either pulling a large slice of symfony/* into a Laravel app (framework-bundle, dependency-injection, config, http-kernel) or forking and re-homing the logic.

More importantly, the bundle solves a problem Laravel already solves at a different layer. Laravel's queue subsystem is built around Illuminate\Queue\Connectors\ConnectorInterface, Queue, and Job contracts, with a worker loop that handles retries, backoff, failed_jobs persistence, timeouts, signals, and Horizon-style supervision. The bundle predates and ignores all of that — it provides a STOMP connection factory, a producer service, and a Symfony-idiomatic consumer command. There is no Laravel queue driver, no Job serialization contract, no failed-job store, no worker integration.

Integration feasibility — low as-is, moderate as a reference implementation. The genuinely reusable asset is not the bundle; it is the pattern of fusesource/stomp-php + a connection factory + a consumer loop. That pattern is roughly 200–400 lines to reimplement natively as a Laravel queue connector. Buying the bundle to get that pattern costs you a Symfony dependency tree and an unmaintained transitive graph.

Technical risk — high, concentrated in abandonment.

The reported opportunity score of 10.21 and quality score of ~0.91 are misleading in this context — they reward recency-neutral signals like license and metadata completeness. For a package with zero dependents and no release in eight years, low adoption is a negative signal, not headroom. Treat the score as noise.

Key questions for the broker owner / stakeholders:

1. Which broker, exactly? ActiveMQ Classic, ActiveMQ Artemis, or Amazon MQ (which fronts Classic or Artemis)? Artemis has materially different STOMP behavior and management semantics than 5.x Classic. This changes the answer.
2. Why STOMP? Is it a hard constraint from an existing producer/consumer estate, or an inherited default? If we control both ends, AMQP 1.0 or a Laravel-native transport is the better bet.
3. Is the broker in the request path or async-only? Synchronous send() in a web request changes latency and failure-mode requirements substantially.
4. What is the actual throughput and durability requirement? Orders-of-magnitude differences between 10 msg/s and 5k msg/s determine whether a hand-rolled connector is credible.
5. Who owns the fork? If the answer is "whoever adopts this," the cost is not the integration — it is perpetual custodianship of ~2,000 lines of abandoned PHP plus its dependency tree.
6. Is there an existing ActiveMQ client elsewhere in the org (Java/.NET) whose message envelope and header conventions we must match? Wire-format compatibility is usually the real constraint, not the client library.

Integration Approach

Recommendation: do not adopt the bundle. Adopt the broker, and implement the client natively behind Laravel's queue contracts.

Ranked options:

1. Preferred — Laravel-native queue connector over stomp-php. Implement ConnectorInterface + Queue, register via QueueServiceProvider extension in a first-party package. You get dispatch(), dispatchSync(), retries, failed_jobs, queue:work, queue:retry, and Telescope/Horizon-adjacent observability for free. Effort: ~1–2 engineer-weeks including tests. This is the same work the bundle would force on you anyway, minus the Symfony baggage.
2. Acceptable — evaluate an existing community STOMP/ActiveMQ Laravel driver first. Even a lightly maintained Laravel-native package beats a well-structured Symfony bundle, because it speaks the framework's contracts. Vet its PHP/Laravel constraints and its last-commit date with the same rigor you applied here.
3. Fallback — fork the bundle and shim it. Wrap the bundle's connection factory and producer in a Laravel service provider, but keep the queue/worker surface native. Acceptable as a time-boxed spike to prove broker connectivity; not acceptable as a long-lived dependency.
4. Rejected — composer require overblog/activemq-bundle as-is. Expect immediate resolution conflicts; resolving them means --ignore-platform-reqs or patching composer.json, which is where maintainability ends.

Stack fit and compatibility. Verify before anything else: composer require --dry-run against your actual PHP and Laravel versions. Expect php: ^7.0|^7.1 and symfony/framework-bundle: ^3.0|^4.0-style constraints. Note that stomp-php itself is independently maintained and may be usable directly even if the bundle is not — this is the key decoupling move: extract the dependency you actually need and drop the wrapper.

Sequencing.

• Week 0 — Spike (2–3 days). Stand up a container against the real broker (Classic vs Artemis, matching prod). Prove connect / send / consume / ack with stomp-php directly from a Laravel artisan command. No bundle. Output: a go/no-go on protocol feasibility and a measured round-trip latency under nominal load.
• Week 1 — Contract design. Define the message envelope (JSON, versioned header, correlation ID, idempotency key). Decide sync vs async per call site. Explicitly document that serialize()-style PHP object payloads are forbidden — they make replay across releases impossible.
• Weeks 2–3 — Build the connector. ConnectorInterface, Queue, Job, plus reconnect/backoff, prefetch tuning, visibility timeout mapping, and DLQ routing. Unit tests with a fake broker; one integration test against the container.
• Week 4 — Cutover rehearsal. Dual-run a low-risk consumer, compare output, then migrate queue-by-queue. Keep the broker behind the Laravel queue abstraction so a swap to Redis/SQS/RabbitMQ is a config change, not a rewrite.

Compatibility guardrail. If any part of the path requires --ignore-platform-reqs, treat that as a hard stop and escalate — it means the dependency graph is already drifted from your runtime and will silently break on the next PHP minor.

Operational Impact

Maintenance. Upstream maintenance is effectively zero: no releases since March 2018, no meaningful dependent base to surface bugs, no realistic expectation of a CVE response. You inherit full custodianship on day one. Budget roughly 10–15% of one engineer's capacity for dependency patching, broker-client upgrades, and envelope-format migrations. If the fork option is chosen, add the cost of rebasing against nothing — there is no upstream to rebase from, so the fork is a hard divergence and should be treated as first-party code.

Support. No maintainer SLA, no active issue triage, and the available community knowledge skews to Symfony 2/3-era idioms (service IDs, @service annotations, services.yml). Engineers searching for answers will find guidance that does not apply to the code in front of them. Escalation path is internal-only — name an owner in the ADR.

Scaling. Consumer-side horizontal scaling is straightforward: STOMP is a persistent TCP connection, so each queue:work process holds one socket to the broker. Watch connection count against broker limits as worker count grows, and watch connection churn — reconnect storms after a broker restart are the most common production incident here. Prefetch and ack-mode tuning materially affect throughput and redelivery volume. On the broker side, ActiveMQ Classic's STOMP path is the least performant of its protocol options; if throughput targets are aggressive, that is an argument for AMQP or OpenWire and against this entire package family.

Failure modes to design for explicitly:

Ramp-up. A mid-level Laravel engineer is productive on a native connector in 2–3 days. The same engineer needs 3–5 days just to read the Symfony bundle source competently — bundles, compiler passes, and tag-based service collection are not transferable Laravel knowledge, and the effort yields nothing reusable after the fork. That asymmetry is the clearest operational argument for option 1: you pay less to build the thing you understand than to understand the thing you didn't build.

Bottom line. This package is a 2018 Symfony artifact with no adoption and no maintenance path. It is useful as a reference implementation of ActiveMQ-over-STOMP integration, and should be read, not required. The correct move is to adopt the broker if the organization genuinely needs it, and implement the Laravel queue connector directly — behind the framework's queue abstraction, so the next migration is a config change rather than another archaeology project.