- Is overblog/activemq-bundle a Laravel package I can just install?
- No. It is a Symfony bundle, not a Laravel package, and its value is delivered entirely through Symfony's Bundle/Extension/CompilerPass machinery, a TreeBuilder config tree, and kernel event subscribers. Laravel has no registerBundles() step, no DI compiler pass, no config-tree validation, and no HttpKernel lifecycle to hook into. Making it work means either pulling a large slice of symfony/* (framework-bundle, dependency-injection, config, http-kernel) into your app or forking and re-homing the logic.
- Can I use overblog/activemq-bundle with Laravel 10 or 11 on PHP 8.2/8.3?
- Practically no. The last release is from March 2018, and its 2018-era constraints almost certainly pin PHP to 7.x and Symfony to 4.x, which will collide with PHP 8.2/8.3 and Laravel 10/11. Composer may resolve it in an isolated sandbox, but nothing in it registers with Laravel's container, so it would provide no usable functionality. You would be paying the dependency cost for zero framework integration.
- How do you install and configure overblog/activemq-bundle?
- In Symfony you would require it via Composer, register the bundle in bundles.php or AppKernel, and configure the connection factory, producer, and consumer settings under a bundle-specific config key. None of those steps exist in Laravel, so there is no equivalent installation path. You would have to instantiate the underlying STOMP connection factory and producer services manually from a service provider, which is more work than writing the client yourself.
- Does it provide a Laravel queue driver, worker integration, or failed_jobs support?
- No. There is no implementation of Illuminate\Queue\Connectors\ConnectorInterface, no Queue or Job contract serialization, and no failed-job store or worker integration. The bundle predates and ignores Laravel's worker loop with its retries, backoff, timeouts, signal handling, and Horizon supervision. You would be building all of that yourself on top of a Symfony-idiomatic consumer command.
- Is overblog/activemq-bundle still maintained?
- Effectively not. The last release was 2018-03-05, roughly eight years ago, with about 10 GitHub stars, zero dependents, and a handful of contributors. There is no realistic upstream fix path for bugs or security issues, so adopting it means accepting perpetual custodianship of the code and its dependency tree. Metrics that reward license and metadata completeness can make it look healthier than it is; treat those scores as noise for a package with no releases and no dependents.
- Which broker should I target: ActiveMQ Classic, Artemis, or Amazon MQ?
- Answer this before choosing any client library. ActiveMQ Artemis has materially different STOMP behavior and management semantics than 5.x Classic, and Amazon MQ fronts either one depending on how it was provisioned. The bundle only speaks STOMP, so if you are on Artemis or plan to move there, AMQP 1.0 via php-amqplib is the safer bet. If you control both producers and consumers, a Laravel-native AMQP transport usually beats STOMP.
- Is STOMP a good protocol choice for ActiveMQ from PHP?
- Only if it is a hard constraint inherited from an existing producer or consumer estate. ActiveMQ Classic's STOMP path is slower and less featured than OpenWire or AMQP, with weaker flow control and less mature management semantics. If both ends are yours, AMQP 1.0 or a Laravel-native transport gives you better durability and observability. Also confirm whether the broker sits in the synchronous request path, since a synchronous send() inside a web request changes latency and failure-mode requirements significantly.
- What are the security risks of depending on this package?
- High, and concentrated in abandonment. Its transitive dependencies, including stomp-php and Symfony 3/4 components, inherit known CVEs, and there is no upstream to ship patches. Because nothing will be fixed for you, your team owns vulnerability triage for the entire graph. That is a recurring cost, not a one-time integration cost.
- Can I use it as a reference implementation without adopting it?
- Yes, and that is the sensible use. The genuinely reusable asset is the pattern, not the bundle: fusesource/stomp-php plus a connection factory plus a consumer loop. That is roughly 200 to 400 lines to reimplement natively as a Laravel queue connector behind ConnectorInterface. Read the source for the message envelope and header conventions, then leave the Symfony dependency tree behind.
- How should I test an ActiveMQ integration in a Laravel application?
- Separate the dispatch path from the transport. Use Queue::fake() or a mocked connector to assert that jobs are pushed with the correct payload and headers, then run integration tests against a containerized broker to verify wire-format compatibility, reconnect behavior, and redelivery. Because a hand-rolled consumer loop gets no Horizon-style introspection, add explicit tests for retry, backoff, timeout, and poison-message handling. Match the message envelope and header conventions used by any existing Java or .NET ActiveMQ clients in your organization, since wire-format compatibility is usually the real constraint.