activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From artnaseef <>
Subject Re: ActiveMQ Console - let's get the problem defined
Date Tue, 04 Feb 2014 13:53:17 GMT
Interesting - where do the ActiveMQ-specific parts live then?  I
understand how the JMX-parts can be done without an activemq-specific
dependency, although they could easily be used in a way that creates a
dependency (e.g. coding the ObjectNames of specific MBeans).

Reading through one of the other chains of email, I understood there are
activemq-specific parts in  Using the UI, I recall seeing an
"ActiveMQ" tab, which further gives the impression that must be so.

BTW, not having server-side code, and being able to run against various
broker versions, isn't adequate to avoid a circular dependency.  Any part
of the solution that breaks if the server-side changes, together with the
console being pulled into ActiveMQ, making it so that ActiveMQ is now
dependent on the console, creates the circular dependency.

Just look at the poms; if activemq's poms have a dependency on and's poms have a dependency on activemq, then it's circular.

A better test than the poms check is this: if a change to project A might
require a simultaneous change to project B, and the same change to project
B requires a simultaneous change back in project A, it's a circular
dependency.  I can't even figure out how one would solve the problem of
releases in this case since it would not be possible to build a release
(and upload to Nexus) of either project without first releasing (and
uploading) the other.  Of course, that dilema only arises once such a
two-way change is made - meaning its entirely feasible to get into that
situation well after the circular dependency has been created.

This really raises an interesting question for me.  Isn't built to
integrate multiple solutions intelligently?  If that's so, it's a
higher-level abstraction than any one of those solutions, and therefore
doesn't really belong inside any one of them.

Consider, if you will, if I have 3 tools that manages, I wouldn't
want three separate instances of - one in each of the 3 tools;
that defeats the point.  Perhaps a viable approach for is to
define a standard interaction between the UI and any tool it will manage,
drive that down as a lower-level dependency (i.e. have its own project),
and then use that standard to communicate with each tool.  JMX fits that
model already.  Joolokia also fits that - unless I'm mistaken.  However,
JMX and Joolokia might be too low level and, therefore, not ensure the
interactions really needs.

By the way - why put into ActiveMQ?  Just the desire to stop
maintaining the old console and have a nicer console? can be used
with ActiveMQ even though it's not built-in to ActiveMQ, right?

> On 4 February 2014 04:27, artnaseef <> wrote:
>> By the way, on the topic of using an external console to replace the
>> current
>> built-in console, there's very real concern with circular dependency.
> FWIW there's no circular dependency with hawtio; it contains no server
> side
> parts and can run against ActiveMQ 5.x, 5.8, 5.9, 5.10 et al just fine.
> --
> James
> -------
> Red Hat
> Email:
> Web:
> Twitter: jstrachan, fusenews
> Blog:
> Open Source Integration
> _______________________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> To start a new topic under ActiveMQ - Dev, email
> To unsubscribe from ActiveMQ Console - let's get the problem defined,
> visit

View this message in context:
Sent from the ActiveMQ - Dev mailing list archive at
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message