Having an option of a nice-looking console like hawt.io is nice for users. But removing the webconsole is about more than that.
The number one benefit of the webconsole, in my experience, is getting information about the state of the broker quickly and easily - especially for folk that are new to ActiveMQ. In that regard, pretty isn't too important, right? Here's a "problem description" or requirement -- users need a means to see the state of destinations, including the lists of existing destinations, and message stats, which can tell them whether messages are moving across the brokers as needed, and moving to/from amq clients as expected. One complaint that dogged me over time was the "our clients are not recieving messages.". We need an easy way to get more info to solve those cases - especially new folks doing their technology selection who are new and trying to prove or disprove that AMQ does the job. Sent from my iPhone > On Jan 31, 2014, at 10:37 AM, "chirino [via ActiveMQ]" > <[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 > <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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. > >> [hidden email] | fusesource.com | redhat.com > >> skype: hiramchirino | twitter: @hiramchirino > > > > -- > Hiram Chirino > Engineering | Red Hat, Inc. > [hidden email] | fusesource.com | redhat.com > skype: hiramchirino | twitter: @hiramchirino > > > If you reply to this email, your message will be added to the discussion > below: > http://activemq.2283324.n4.nabble.com/ActiveMQ-Console-let-s-get-the-problem-defined-tp4677105p4677197.html > To start a new topic under ActiveMQ - Dev, email > [email protected] > To unsubscribe from ActiveMQ Console - let's get the problem defined, click > here. > NAML -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-Console-let-s-get-the-problem-defined-tp4677105p4677206.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
