LOL. Nice try James. Check out the current plugins for hawtio: http://hawt.io/plugins/index.html
we've worked pretty well with every version of pretty much every decent open source software library from camel / cxf / activemq / karaf / tomcat / jetty / osgi / git / fabric8 / osgi / jmx / quartz - by being a stand alone separate project. And the hawtio ActiveMQ tooling is way beyond anything in the old console. Open source projects can actually, you know, collaborate. There's really no technical reason to force a 22Mb legacy turd into the ActiveMQ broker project or distro. On 31 January 2014 18:41, James Carman <[email protected]> wrote: > Right, but you were at the mercy of what was currently exposed. > Adding new functionality would involve instrumenting it in the MBeans > (if it's not already there of course). That's the key reason they > shouldn't be separated. > > On Fri, Jan 31, 2014 at 1:32 PM, Robin Kåveland Hansen <[email protected]> > wrote: > > I will try write up some thoughts on this later, but I have a pretty > strong > > opinion that the responsibility of the broker is only to offer an API > that > > a web console may use. At my current client we wrote a web console using > > the jmx api. This lets us use a different JVM for the webapp, minimising > > the risk that an error in it will affect the service of the most critical > > piece of infrastructure on our platform. It also lets us monitor and work > > on messages on brokers that are not in a network from the same webapp. I > > don't know what things are like now, but this was difficult back in 5.5. > > > > If this is interesting to people I can probably share a lot of thoughts > and > > ideas about the web console. > > On Jan 31, 2014 6:14 PM, "Hiram Chirino" <[email protected]> wrote: > > > >> The core ActiveMQ is all about message passing. The skill set needed > >> for that is a bit different than the one need to design and build > >> beautiful, modern web applications. Perhaps folks have just been > >> focused in areas where they feel they can contribute best to. > >> > >> > >> On Fri, Jan 31, 2014 at 8:56 AM, James Carman > >> <[email protected]> wrote: > >> > Out of curiosity, why did work stop on the old console? Did folks > >> > just lose interest? Why was it neglected? > >> > > >> > On Fri, Jan 31, 2014 at 7:52 AM, Hiram Chirino < > [email protected]> > >> wrote: > >> >> As far as why the old console is a headache take a peek at the CVE > >> >> reported against ActiveMQ in the past. Notice most deal with the old > >> >> console: > >> >> > >> >> > >> > http://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-19047/Apache-Activemq.html > >> >> > >> >> It's also lacking a modern a responsive look /w automatic status > >> >> refreshing that most modern web apps are implementing today. > >> >> > >> >> > >> >> On Thu, Jan 30, 2014 at 5:16 PM, artnaseef <[email protected]> > wrote: > >> >>> Reading through the arguments for and against removal of the current > >> console, > >> >>> or moving it to a subproject, is getting confusing. Positions are > >> hard to > >> >>> understand, and options unclear. > >> >>> > >> >>> I propose getting the problem clearly and concisely defined, then > >> discuss > >> >>> the merits of each position, and then go back to proposing > solutions. > >> >>> > >> >>> So, what are the problems? > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> View this message in context: > >> > http://activemq.2283324.n4.nabble.com/ActiveMQ-Console-let-s-get-the-problem-defined-tp4677105.html > >> >>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. > >> >> > >> >> > >> >> > >> >> -- > >> >> Hiram Chirino > >> >> Engineering | Red Hat, Inc. > >> >> [email protected] | fusesource.com | redhat.com > >> >> skype: hiramchirino | twitter: @hiramchirino > >> > >> > >> > >> -- > >> Hiram Chirino > >> Engineering | Red Hat, Inc. > >> [email protected] | fusesource.com | redhat.com > >> skype: hiramchirino | twitter: @hiramchirino > >> > -- James ------- Red Hat Email: [email protected] Web: http://fusesource.com Twitter: jstrachan, fusenews Blog: http://macstrac.blogspot.com/ Open Source Integration
