I am using expand_modules at work. It may not be the best solution to
my problem, but it seemed appropriate. Let's see if I can describe
what I'm doing.

I have a thing that just happens to be a Catalyst application, using
Catalyst::Engine::Stomp to respond to ActiveMQ messages instead of
HTTP requests. Since the actual logic of the application does not
depend on the fact that we're using Catalyst as a module loader and
dispatcher, I have written a sort of "insulation layer" between
Catalyst and the actual business logic.

The "insulated" consumer modules look like this:

package MyApp::Consume::Something;
use Moose;
extends 'MyFramework::Base::Consume';

sub routes {
return {
a_queue_name => {
a_message_type => \&a_method_to_handle_it,
another_message_type => \&you_get_the_idea,
a_different_queue => {
and_so => \&on_and_on,

# here go the actual subs / methods

The MyFramework::Base::Consume class is a Catalyst::Component (well,
better said, ->can('COMPONENT')), and implements a expand_modules
method that does more or less this:

- collect the queues this module wants to listen on
- create (via Moose::Meta::Class->create, and only if it's not already
there) a Catalyst Controller per queue, under the appropriate
namespace (the controller inherits from
Catalyst::Controller::MessageDriven, part of the
Catalyst::Engine::Stomp distributino)
- add a "after 'register_actions'" modifier on the controller to
create the actions that will dispatch the message to the appropriate
method as required


sub expand_modules {
my ($class) = @_;
my @ret = ();
for my $queue (keys %{$class->routes}) {
my $controller_name = the_name_for($queue);
if (not is_controller_there($controller_name)) {
for my $message_type (keys %{$class->routes->{$queue}}) {
push @ret, $controller_name;
return @ret;

Answers to some probable questions:

- Can't your Consume modules be Controllers, and then you do
$something to the Dispatcher?

Maybe, but Catalyst::Engine::Stomp /
Catalyst::Controller::MessageDriven do enough strange things to the
dispatch, and I prefer not to rewrite them

- Do you really need to insulate your modules so much from Catalyst?

There is talk to use some other system to handle ActiveMQ in the
future, and I don't want to have to touch my code more than strictly

- How the &%$%$^# did you think this was a good idea?

Well, it *is* documented :) And it seems to be the obvious hook:
when loaded, my component creates more components…


- am I insane? :)

- is there a better / cleaner / more future-proof way of getting the
same result?

- will the "much better solution" that t0m hinted at still allow me
this kind of contortions?

Thanks :)

Dakkar - <Mobilis in mobile>
GPG public key fingerprint = A071 E618 DD2C 5901 9574
6FE2 40EA 9883 7519 3F88
key id = 0x75193F88

Beyond the top of the sky was the place the Thing had called the
universe. It contained -- according to the Thing -- everything and
nothing. And there was very little everything and more nothing than
anyone could imagine. -- (Terry Pratchett, Wings)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110728/101e9488/signature.pgp

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 1 | next ›
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJul 28, '11 at 11:44a
activeJul 28, '11 at 11:44a

1 user in discussion

Gianni Ceccarelli: 1 post



site design / logo © 2022 Grokbase