Re: Special Board Report

[James Carman]

For what it's worth, I agree with Hadrian that HornetQ should go to the
incubator.  The fact that I gave up on pushing the issue doesn't mean I
don't think that's the right course of action.  It just didn't seem like it
was going to happen.


On Mon, Apr 20, 2015 at 6:46 PM Hadrian Zbarcea  wrote:

> Uhm, what were we doing for the past 2 weeks? On two lists, multiple
> threads?
>
> I assume you are aware of my recommendation to have hornetq grow
> independently in the incubator. That proposal was rejected, but no
> reason given besides that the RH engineers would have to do the work
> twice. My request was to include that in the report (or whatever other
> reason might exist). The way it looks is that Fuse/RH/(the Damarillo
> group), anyway you want to describe that faction is dead set on
> replacing the existing ActiveMQ with HornetQ (or whatever code name) in
> version 6 or 10. By keeping HornetQ under the ActiveMQ PMC influence its
> future will be heavily influenced by the already biased PMC and at the
> same time hide the lack of diversity in HornetQ. In the incubator,
> HornetQ will have the opportunity and freedom to grow in any direction
> and build a diverse community.
>
> Since there is all this concern about the viral nature of the plan, why
> not allow HornetQ to take its course, build more diversity in the
> ActiveMQ community (actually both) and influence it based on technical
> merits instead of abundance of votes?
>
> Does that clarify my request?
> Hadrian
>
>
> On 04/20/2015 05:51 PM, Bruce Snyder wrote:
> > Agreed, we need to get this report published/submitted, so time is off
> the
> > essence here.
> >
> > Hadrian, you have raised some points that you would like to have included
> > in the report, but nobody can read your mind. Please add your points to
> the
> > report so that others can see them and discuss them ASAP.
> >
> > Bruce
> >
> > On Mon, Apr 20, 2015 at 4:42 PM, Hiram Chirino 
> > wrote:
> >
> >> So we are running into a time crunch here.  I'm hoping all the PMC
> >> members will pitch in and apply any edits to the report they deem
> >> necessary.  Many thanks to those who have helped out.  Seems like some
> >> folks are still now happy with it, so that's why have held off in
> >> sending it so that they get a chance to add their input.  But your
> >> right, I do have to send this in before the 22nd so really today is
> >> the last day I can hold off so that I can send it on the 21st so that
> >> the board has at least 24 hours to review before their meeting.
> >>
> >> On Mon, Apr 20, 2015 at 5:38 PM, Hadrian Zbarcea 
> >> wrote:
> >>> One more thing. It's the responsibility of the PMC chair to provide a
> >> timely
> >>> report to the board. It's entirely his choice how he wants to go about
> >> it,
> >>> what he decides to include and what to leave out. The report should be
> >>> published in a timely manner though, so that comments (usually from the
> >>> board) could be addressed before the meeting.
> >>>
> >>> Cheers,
> >>> Hadrian
> >>>
> >>>
> >>> On 04/20/2015 05:23 PM, Hiram Chirino wrote:
> 
>  Ok so, then it sounds like your ok with the report the way it is right
>  now.
> 
>  On Mon, Apr 20, 2015 at 3:16 PM, Hadrian Zbarcea 
>  wrote:
> >
> > I have nothing to write. There were some claims made that were not
> > substantiate. My request was for the party that made the claims to
> > provide
> > an explanation.
> >
> > I cannot explain somebody else's point of view. I can explain my
> views
> >> if
> > anybody requires it.
> >
> > Cheers,
> > Hadrian
> >
> >
> >
> > On 04/20/2015 02:39 PM, Hiram Chirino wrote:
> >>
> >>
> >> Hadrian, please write up what you want to include in the board
> report
> >> that way the rest of the PMC can review.
> >>
> >> On Mon, Apr 20, 2015 at 2:23 PM, Hadrian Zbarcea <
> hzbar...@gmail.com>
> >> wrote:
> >>>
> >>>
> >>> First, the report is late. Second, I don't think it addresses the
> >>> problems.
> >>> Third, I made a request to please include in the report an
> >> explanation
> >>> about
> >>> why hornetq moving to the incubator is a non-starter for Fuse
> crowd.
> >> It
> >>> is
> >>> very frustrating that requests get ignored.
> >>>
> >>> Hadrian
> >>>
> >>>
> >>>
> >>>
> >>> On 04/20/2015 02:16 PM, Hiram Chirino wrote:
> 
> 
> 
>  Are they any other updates folks want to make to this report?
> >> Please
>  apply your updates soon.  The board meets on the 22nd and I'd like
> >> to
>  submit the report on the 21st at the latest.
> 
>  On Fri, Apr 17, 2015 at 10:03 AM, Hiram Chirino
>  
>  wrote:
> >
> >
> >
> > Hi guys.  The board requested a report this month and had some
> > specific questions around the hornetq code donation.  I've 

Re: [VOTE] Pick a code name for the HornetQ code donation

[James Carman]

Is anyone willing to change their vote?

On Friday, April 17, 2015, Clebert  wrote:

> My wife voted for reactive. Does it count? Lol
>
> Sent from my iPad
>
> > On Apr 17, 2015, at 09:39, James Carman  > wrote:
> >
> > Troublemaker ;). Now we have a tie.
> >
> >> On Friday, April 17, 2015, Gary Tully  > wrote:
> >>
> >> +1 for [a] ActiveMQ Artemis
> >>
> >> On 14 April 2015 at 16:42, Hiram Chirino  
> >> > wrote:
> >>> Now that we have chosen to give the HornetQ code donation a code name,
> >>> it's time to pick what that code name will be.  Please select from one
> >>> of the following options:
> >>>
> >>> [a] ActiveMQ Artemis
> >>> [b] ActiveMQ Luna
> >>> [c] ActiveMQ Reactive
> >>>
> >>> Vote will be open for 72 hours.  The option with the most votes will
> win.
> >>>
> >>> Regards,
> >>> Hiram
> >>>
> >>> --
> >>> Hiram Chirino
> >>> Engineering | Red Hat, Inc.
> >>> hchir...@redhat.com   | fusesource.com |
> redhat.com
> >>> skype: hiramchirino | twitter: @hiramchirino
> >>
>

Re: [VOTE] Pick a code name for the HornetQ code donation

[James Carman]

Troublemaker ;). Now we have a tie.

On Friday, April 17, 2015, Gary Tully  wrote:

> +1 for [a] ActiveMQ Artemis
>
> On 14 April 2015 at 16:42, Hiram Chirino  > wrote:
> > Now that we have chosen to give the HornetQ code donation a code name,
> > it's time to pick what that code name will be.  Please select from one
> > of the following options:
> >
> > [a] ActiveMQ Artemis
> > [b] ActiveMQ Luna
> > [c] ActiveMQ Reactive
> >
> > Vote will be open for 72 hours.  The option with the most votes will win.
> >
> > Regards,
> > Hiram
> >
> > --
> > Hiram Chirino
> > Engineering | Red Hat, Inc.
> > hchir...@redhat.com  | fusesource.com | redhat.com
> > skype: hiramchirino | twitter: @hiramchirino
>

[DISCUSS] ActiveMQ {CodeName} Must-Have Features...

[James Carman]

In order for ActiveMQ {CodeName} to take over as the next generation
of ActiveMQ, it obviously must have some level of feature parity with
the existing ActiveMQ 5.x (or 6.x if it's released before that
transition) offering.  We should come up with some level of a roadmap
together about which features are required.  Thus far, the only
big-ticket items that have been addressed are:

1.  The OpenWire protocol is supported
2.  Auto-creation of destinations (mostly complete).

This is obviously not all of what the existing ActiveMQ is all about.
What other features are folks wanting to see in the next generation
ActiveMQ?

James

[DISCUSS] Should ActiveMQ {CodeName} Support Backward Compatibility with HornetQ...

[James Carman]

It has come to light that some folks feel that ActiveMQ {CodeName}
should support backward compatibility with HornetQ.  I don't think
this has been discussed specifically within the community yet, so I
thought I'd bring it up.

James

[DISCUSS] ActiveMQ {CodeName} Web Console...

[James Carman]

The new codebase does not include a web console for management
purposes.  If it is to be the next generation ActiveMQ, it will need
this feature.  Here at ApacheCon, we have talked a bit about it.  Thus
far, folks seem happy with the idea of an AngularJS-based front-end
which talks to ActiveMQ using Jolokia only.  Something this large
obviously needs to be discussed with the whole community, thus this
email.

James

Re: [VOTE] Pick a code name for the HornetQ code donation

[James Carman]

+1 [a] ActiveMQ Artemis


On Tue, Apr 14, 2015 at 10:42 AM, Hiram Chirino  wrote:
> Now that we have chosen to give the HornetQ code donation a code name,
> it's time to pick what that code name will be.  Please select from one
> of the following options:
>
> [a] ActiveMQ Artemis
> [b] ActiveMQ Luna
> [c] ActiveMQ Reactive
>
> Vote will be open for 72 hours.  The option with the most votes will win.
>
> Regards,
> Hiram
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino

[jira] [Commented] (AMQ-5717) Add support for suffix destination filtering

[James Carman (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490898#comment-14490898
 ] 

James Carman commented on AMQ-5717:
---

The email thread in question:

http://activemq.2283324.n4.nabble.com/How-to-use-destination-wildcards-to-match-a-common-suffix-tt4694596.html


> Add support for suffix destination filtering
> 
>
> Key: AMQ-5717
> URL: https://issues.apache.org/jira/browse/AMQ-5717
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 5.11.1
>Reporter: James Carman
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Recently we had a question on the mailing list about whether we supported 
> matching destinations based on suffixes.  Unfortunately, the answer was 'no'. 
>  Suffix matching should be supported, using a similar pattern that we use for 
> prefix matching:
> < matches anything
> <.A matches A, foo.A, foo.bar.A
> <.A.B matches A.B, foo.A.B, foo.bar.A.B



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5717) Add support for suffix destination filtering

[James Carman (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490896#comment-14490896
 ] 

James Carman commented on AMQ-5717:
---

Submitted pull request which implements this feature:

https://github.com/apache/activemq/pull/85


> Add support for suffix destination filtering
> 
>
> Key: AMQ-5717
> URL: https://issues.apache.org/jira/browse/AMQ-5717
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 5.11.1
>Reporter: James Carman
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Recently we had a question on the mailing list about whether we supported 
> matching destinations based on suffixes.  Unfortunately, the answer was 'no'. 
>  Suffix matching should be supported, using a similar pattern that we use for 
> prefix matching:
> < matches anything
> <.A matches A, foo.A, foo.bar.A
> <.A.B matches A.B, foo.A.B, foo.bar.A.B



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5717) Add support for suffix destination filtering

[James Carman (JIRA)]

James Carman created AMQ-5717:
-

 Summary: Add support for suffix destination filtering
 Key: AMQ-5717
 URL: https://issues.apache.org/jira/browse/AMQ-5717
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 5.11.1
Reporter: James Carman


Recently we had a question on the mailing list about whether we supported 
matching destinations based on suffixes.  Unfortunately, the answer was 'no'.  
Suffix matching should be supported, using a similar pattern that we use for 
prefix matching:

< matches anything
<.A matches A, foo.A, foo.bar.A
<.A.B matches A.B, foo.A.B, foo.bar.A.B




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Naming Suggestions?

[James Carman]

It is a good name.  Do we need to engage trademarks@ for code names?

On Thursday, April 9, 2015, Hiram Chirino  wrote:

> I do like Artemis.  ActiveMQ Artemis has a nice ring to it.
>
> On Wed, Apr 8, 2015 at 11:04 PM, Christian Posta
> > wrote:
> > Nice, Dan! ArtemisMQ! I like it.
> >
> > On Wed, Apr 8, 2015 at 1:41 PM, Daniel Kulp  > wrote:
> >
> >>
> >> > On Apr 8, 2015, at 4:23 PM, Hiram Chirino  >
> >> wrote:
> >> >
> >> > Naming things is hard.  If we gave the hornetq code grant a code name
> >> > other than HornetQ or ActiveMQ 6, I think we would be avoid lots of TM
> >> > confusion.  Anybody have any suggestion what would be a good name to
> >> > give it?
> >>
> >> Hermes?That would be Apollo’s half brother.
> >>
> >> Or Artemis, Apollo’s twin sister.
> >>
> >>
> >> Dan
> >>
> >>
> >>
> >> >
> >> > --
> >> > Hiram Chirino
> >> > Engineering | Red Hat, Inc.
> >> > hchir...@redhat.com  | fusesource.com | redhat.com
> >> > skype: hiramchirino | twitter: @hiramchirino
> >>
> >> --
> >> Daniel Kulp
> >> dk...@apache.org  - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >>
> >
> >
> > --
> > *Christian Posta*
> > twitter: @christianposta
> > http://www.christianposta.com/blog
> > http://fabric8.io
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com  | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
>

Re: [DISCUSS} HornetQ & ActiveMQ's next generation

[James Carman]

I am trying to understand the picture that has been painted for us thus
far.  Maybe you can help me.  First of all, the argument for why we need to
start from the HornetQ code base is because the current core broker is in
such disrepair that we can't fix it (and some feel that we should thank our
lucky stars these guys came along when they did to save us all from our own
incompetence).  Now we are being told that our opinions really shouldn't
matter and we should just blindly trust the folks who made it that way
(they wrote most of the code, right) when they tell us that this is the
right thing to do for the future of ActiveMQ?

Now, please don't take this as my opinion.  I have nothing but respect for
the folks you mentioned as well as the other folks who have contributed to
this project.  I'm just trying to point out how the arguments seem to
contradict one another.

On Wednesday, April 8, 2015, Guillaume Nodet  wrote:

> I think most of the code has been written over the years by James, Rob,
> Hiram, Garry, Dejan and Tim.  I can't speak for them, but I don't recall
> having read anything from them that could lead me to believe they were in
> any way reluctant about replacing the activemq broker with the one from the
> hornetq donation.  Rather the opposite, and I certainly trust them on the
> technical side...
>
> 2015-04-08 22:33 GMT+02:00 Tracy Snell :
>
> > Who are in the 90% club and are they really all on board with the new
> > broker?
> >
> > > On Apr 8, 2015, at 3:52 PM, Guillaume Nodet  wrote:
> > >
> > > In this very case, I think this is a technical decision, and my trust
> > > clearly goes to the ones that know and wrote 90% of the code, and when
> > they
> > > all  seem to say the "hornetq" broker should replace the activemq 5
> one,
> > I
> > > don't see why I should give it any more second thoughts.
> >
> >
>

Re: Naming Suggestions?

[James Carman]

I believe nest is trademarked already.  Is it cold in here? ;)

On Wednesday, April 8, 2015, Clebert Suconic 
wrote:

> *If* we have to rename anything, I liked the name "Nest" as the
> ActiveMQ Nest broker
>
> On Wed, Apr 8, 2015 at 4:23 PM, Hiram Chirino  > wrote:
> > Naming things is hard.  If we gave the hornetq code grant a code name
> > other than HornetQ or ActiveMQ 6, I think we would be avoid lots of TM
> > confusion.  Anybody have any suggestion what would be a good name to
> > give it?
> >
> > --
> > Hiram Chirino
> > Engineering | Red Hat, Inc.
> > hchir...@redhat.com  | fusesource.com | redhat.com
> > skype: hiramchirino | twitter: @hiramchirino
>
>
>
> --
> Clebert Suconic
> http://community.jboss.org/people/clebert.suco...@jboss.com
> http://clebertsuconic.blogspot.com
>

Re: Naming Suggestions?

[James Carman]

Apache  incubating has a very nice ring to it

On Wednesday, April 8, 2015, Hiram Chirino  wrote:

> Naming things is hard.  If we gave the hornetq code grant a code name
> other than HornetQ or ActiveMQ 6, I think we would be avoid lots of TM
> confusion.  Anybody have any suggestion what would be a good name to
> give it?
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com  | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
>

Re: Naming Suggestions?

[James Carman]

http://activemq.apache.org/hermes-jms.html

On Wednesday, April 8, 2015, Rob Davies  wrote:

> +1 Hermes
>
>   Daniel Kulp 
>  8 April 2015 21:41
>
> On Apr 8, 2015, at 4:23 PM, Hiram Chirino  
>  wrote:
>
> Naming things is hard.  If we gave the hornetq code grant a code name
> other than HornetQ or ActiveMQ 6, I think we would be avoid lots of TM
> confusion.  Anybody have any suggestion what would be a good name to
> give it?
>
> Hermes?That would be Apollo’s half brother.
>
> Or Artemis, Apollo’s twin sister.
>
>
> Dan
>
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, inc.hchir...@redhat.com 
>  | fusesource.com | 
> redhat.com
> skype: hiramchirino | twitter: @hiramchirino
>
>   Hiram Chirino 
>  8 April 2015 21:23
> Naming things is hard. If we gave the hornetq code grant a code name
> other than HornetQ or ActiveMQ 6, I think we would be avoid lots of TM
> confusion. Anybody have any suggestion what would be a good name to
> give it?
>
>

Re: [PROPOSAL] Pluggable Brokers...

[James Carman]

Pluggable *within* ActiveMQ.  That is what doesn't exist.  The idea is that
the underlying engine could be optimized on a case-by-case basis.  For
instance, you may be able to streamline the implementation of a broker that
doesn't require persistence at all.  Right now, we have one implementation
that tries to be the end-all-be-all solution for everything.

On Wednesday, April 8, 2015, Jim Gomes  wrote:

> I'm with Guillaume on this. From the NMS perspective, the broker already is
> a plugin implementation. I don't understand why it would need to go any
> deeper than that. NMS can talk to TIBCO or ActiveMQ brokers via one common
> API. The idea of pluggable brokers already exists.
>
> On Mon, Mar 30, 2015, 8:32 AM Guillaume Nodet  > wrote:
>
> > Fwiw, the whole broker implementation looks like an implementation detail
> > from a user point of view that uses the JMS spec... ;-)
> >
> > 2015-03-30 17:12 GMT+02:00 Hadrian Zbarcea  >:
> >
> > > +1.
> > >
> > > The blocking today it merely an implementation detail than can be
> > > addressed.
> > >
> > > Hadrian
> > >
> > >
> > > On 03/30/2015 09:23 AM, James Carman wrote:
> > >
> > >> All,
> > >>
> > >> With all the talk over the last week or so regarding the "Broker
> > >> Wars", especially after reading Rob Davies' email about how the broker
> > >> has been tweaked through the years to emphasize different aspects
> > >> (long-term storage for instance), it occurred to me that we might be
> > >> able to move past all this craziness by providing an abstraction layer
> > >> above the broker and try to make them "pluggable."
> > >>
> > >> If there really are situations where the broker needs to focus on one
> > >> particular aspect of message delivery, that sounds to me like the
> > >> "strategy" pattern.  If a broker can be written in such a way that it
> > >> is allowed to focus on certain aspects and maybe ignore or completely
> > >> forego others, then it would seem to me that the code could be made
> > >> much more straight-forward, because it doesn't have to try to be the
> > >> "swiss army knife", solving everyone's problems at one time.
> > >>
> > >> Of course, this may be just a pipe dream and there's no way to do it
> > >> (admittedly I'm not terribly familiar with the code), but I thought
> > >> I'd throw it out there as a possible approach.  I mean, we do this
> > >> sort of thing already with the persistence providers, so maybe there's
> > >> an opportunity here as well.
> > >>
> > >> Thoughts?
> > >>
> > >> James
> > >>
> > >>
> >
>

Re: [DISCUSS] dev mailing list is cluttered

[James Carman]

Sounds good.  There's no reason to rush this by any stretch of the
imagination.  Lazy consensus is just fine for this sort of thing, I'd
think.


On Tue, Apr 7, 2015 at 4:36 PM, Hiram Chirino  wrote:
> How about this.. Lets request the change 72 hours after this thread
> was started. So 3 days - 5 hours :)  That way, we lets folks in
> different time zones get a chance to object if they want.  After that
> we can call it lazy consensus and be done with it.
>
> On Tue, Apr 7, 2015 at 4:30 PM, Bruce Snyder  wrote:
>> I don't think we need a vote, but I won't stand in the way of one.
>>
>> Bruce
>>
>> On Tue, Apr 7, 2015 at 2:26 PM, James Carman 
>> wrote:
>>
>>> Unless anyone objects, I don't think we need an "official" VOTE.  Thus
>>> far, it appears we have consensus.  Anyone?  Anyone?  Bueller?
>>>
>>> On Tue, Apr 7, 2015 at 4:21 PM, Hiram Chirino 
>>> wrote:
>>> > Do we need an official vote thread for these kinds of changes?
>>> > Perhaps this discussion thread is good enough?
>>> >
>>> > On Tue, Apr 7, 2015 at 3:14 PM, James Carman 
>>> wrote:
>>> >> I think we need to have Hiram request this since he is the chair of the
>>> PMC.
>>> >>
>>> >> On Tuesday, April 7, 2015, James Carman 
>>> wrote:
>>> >>
>>> >>> Actually the mailing lists are different
>>> >>>
>>> >>> https://infra.apache.org/officers/mlreq
>>> >>>
>>> >>>
>>> >>> On Tuesday, April 7, 2015, Bruce Snyder >> >>> > wrote:
>>> >>>
>>> >>>> Anything that requires assistance from the Infra team is accomplished
>>> by
>>> >>>> creating a JIRA issue. Just create a new issue in JIRA (
>>> >>>> https://issues.apache.org/jira/secure/Dashboard.jspa) and select the
>>> >>>> Infrastructure project.
>>> >>>>
>>> >>>> Bruce
>>> >>>>
>>> >>>> On Tue, Apr 7, 2015 at 12:36 PM, artnaseef  wrote:
>>> >>>>
>>> >>>> > Hey Bruce - I would like to learn the process here.  Can you help
>>> me?
>>> >>>> >
>>> >>>> > Was the request made simply by creating a Jira entry?
>>> >>>> >
>>> >>>> >
>>> >>>> >
>>> >>>> > --
>>> >>>> > View this message in context:
>>> >>>> >
>>> >>>>
>>> http://activemq.2283324.n4.nabble.com/DISCUSS-dev-mailing-list-is-cluttered-tp4694420p4694448.html
>>> >>>> > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>> >>>> >
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> perl -e 'print
>>> >>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E>> );'
>>> >>>>
>>> >>>> ActiveMQ in Action: http://bit.ly/2je6cQ
>>> >>>> Blog: http://bruceblog.org/
>>> >>>> Twitter: http://twitter.com/brucesnyder
>>> >>>>
>>> >>>
>>> >
>>> >
>>> >
>>> > --
>>> > Hiram Chirino
>>> > Engineering | Red Hat, Inc.
>>> > hchir...@redhat.com | fusesource.com | redhat.com
>>> > skype: hiramchirino | twitter: @hiramchirino
>>>
>>
>>
>>
>> --
>> perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E>
>> ActiveMQ in Action: http://bit.ly/2je6cQ
>> Blog: http://bruceblog.org/
>> Twitter: http://twitter.com/brucesnyder
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino

Re: [DISCUSS] dev mailing list is cluttered

[James Carman]

Unless anyone objects, I don't think we need an "official" VOTE.  Thus
far, it appears we have consensus.  Anyone?  Anyone?  Bueller?

On Tue, Apr 7, 2015 at 4:21 PM, Hiram Chirino  wrote:
> Do we need an official vote thread for these kinds of changes?
> Perhaps this discussion thread is good enough?
>
> On Tue, Apr 7, 2015 at 3:14 PM, James Carman  
> wrote:
>> I think we need to have Hiram request this since he is the chair of the PMC.
>>
>> On Tuesday, April 7, 2015, James Carman  wrote:
>>
>>> Actually the mailing lists are different
>>>
>>> https://infra.apache.org/officers/mlreq
>>>
>>>
>>> On Tuesday, April 7, 2015, Bruce Snyder >> > wrote:
>>>
>>>> Anything that requires assistance from the Infra team is accomplished by
>>>> creating a JIRA issue. Just create a new issue in JIRA (
>>>> https://issues.apache.org/jira/secure/Dashboard.jspa) and select the
>>>> Infrastructure project.
>>>>
>>>> Bruce
>>>>
>>>> On Tue, Apr 7, 2015 at 12:36 PM, artnaseef  wrote:
>>>>
>>>> > Hey Bruce - I would like to learn the process here.  Can you help me?
>>>> >
>>>> > Was the request made simply by creating a Jira entry?
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > View this message in context:
>>>> >
>>>> http://activemq.2283324.n4.nabble.com/DISCUSS-dev-mailing-list-is-cluttered-tp4694420p4694448.html
>>>> > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> perl -e 'print
>>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E>>>
>>>> ActiveMQ in Action: http://bit.ly/2je6cQ
>>>> Blog: http://bruceblog.org/
>>>> Twitter: http://twitter.com/brucesnyder
>>>>
>>>
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino

Re: [DISCUSS] dev mailing list is cluttered

[James Carman]

I think we need to have Hiram request this since he is the chair of the PMC.

On Tuesday, April 7, 2015, James Carman  wrote:

> Actually the mailing lists are different
>
> https://infra.apache.org/officers/mlreq
>
>
> On Tuesday, April 7, 2015, Bruce Snyder  > wrote:
>
>> Anything that requires assistance from the Infra team is accomplished by
>> creating a JIRA issue. Just create a new issue in JIRA (
>> https://issues.apache.org/jira/secure/Dashboard.jspa) and select the
>> Infrastructure project.
>>
>> Bruce
>>
>> On Tue, Apr 7, 2015 at 12:36 PM, artnaseef  wrote:
>>
>> > Hey Bruce - I would like to learn the process here.  Can you help me?
>> >
>> > Was the request made simply by creating a Jira entry?
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> >
>> http://activemq.2283324.n4.nabble.com/DISCUSS-dev-mailing-list-is-cluttered-tp4694420p4694448.html
>> > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>> >
>>
>>
>>
>> --
>> perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E>
>> ActiveMQ in Action: http://bit.ly/2je6cQ
>> Blog: http://bruceblog.org/
>> Twitter: http://twitter.com/brucesnyder
>>
>

Re: [DISCUSS] dev mailing list is cluttered

[James Carman]

Actually the mailing lists are different

https://infra.apache.org/officers/mlreq


On Tuesday, April 7, 2015, Bruce Snyder  wrote:

> Anything that requires assistance from the Infra team is accomplished by
> creating a JIRA issue. Just create a new issue in JIRA (
> https://issues.apache.org/jira/secure/Dashboard.jspa) and select the
> Infrastructure project.
>
> Bruce
>
> On Tue, Apr 7, 2015 at 12:36 PM, artnaseef  > wrote:
>
> > Hey Bruce - I would like to learn the process here.  Can you help me?
> >
> > Was the request made simply by creating a Jira entry?
> >
> >
> >
> > --
> > View this message in context:
> >
> http://activemq.2283324.n4.nabble.com/DISCUSS-dev-mailing-list-is-cluttered-tp4694420p4694448.html
> > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> >
>
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>

Re: [DISCUSS] dev mailing list is cluttered

[James Carman]

I don't think they work that way, but it couldn't hurt. :)

On Tuesday, April 7, 2015, Bruce Snyder  wrote:

> Good point, Clebert.
>
> Bruce
>
> On Tue, Apr 7, 2015 at 12:45 PM, Clebert Suconic <
> clebert.suco...@gmail.com >
> wrote:
>
> > https://issues.apache.org/jira/browse/INFRA-9394
> >
> >
> > Vote the JIRA, I guess that will bother infra guys to do it sooner ;)
> >
> > On Tue, Apr 7, 2015 at 2:43 PM, James Carman  >
> > wrote:
> > > Agreed.  +1
> > >
> > > On Tuesday, April 7, 2015, Clebert Suconic  >
> > > wrote:
> > >
> > >> paste the JIRA? I will vote for it.
> > >>
> > >>
> > >> I would keep github on dev for now.. there are a few discussions that
> > >> would happen through github (embedded comments.. etc) that I think
> > >> it's worth to mirror to the dev... we can later move out if they start
> > >> to bother.
> > >>
> > >> On Tue, Apr 7, 2015 at 2:35 PM, Bruce Snyder  
> > >> > wrote:
> > >> > I already submitted a request.
> > >> >
> > >> > Bruce
> > >> >
> > >> > On Tue, Apr 7, 2015 at 12:18 PM, artnaseef  
> > >> > wrote:
> > >> >
> > >> >> It sounds like the Jira list is the way to go.
> > >> >>
> > >> >> How can I go about getting the list created and messages
> > redirected?  I
> > >> >> think iss...@activemq.apache.org   is
> the way to go.
> > >> >>
> > >> >> Art
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> View this message in context:
> > >> >>
> > >>
> >
> http://activemq.2283324.n4.nabble.com/DISCUSS-dev-mailing-list-is-cluttered-tp4694420p4694440.html
> > >> >> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > perl -e 'print
> > >> > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > );'
> > >> >
> > >> > ActiveMQ in Action: http://bit.ly/2je6cQ
> > >> > Blog: http://bruceblog.org/
> > >> > Twitter: http://twitter.com/brucesnyder
> > >>
> > >>
> > >>
> > >> --
> > >> Clebert Suconic
> > >> http://community.jboss.org/people/clebert.suco...@jboss.com
> > >> http://clebertsuconic.blogspot.com
> > >>
> >
> >
> >
> > --
> > Clebert Suconic
> > http://community.jboss.org/people/clebert.suco...@jboss.com
> > http://clebertsuconic.blogspot.com
> >
>
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>

Re: [DISCUSS] dev mailing list is cluttered

[James Carman]

Agreed.  +1

On Tuesday, April 7, 2015, Clebert Suconic 
wrote:

> paste the JIRA? I will vote for it.
>
>
> I would keep github on dev for now.. there are a few discussions that
> would happen through github (embedded comments.. etc) that I think
> it's worth to mirror to the dev... we can later move out if they start
> to bother.
>
> On Tue, Apr 7, 2015 at 2:35 PM, Bruce Snyder  > wrote:
> > I already submitted a request.
> >
> > Bruce
> >
> > On Tue, Apr 7, 2015 at 12:18 PM, artnaseef  > wrote:
> >
> >> It sounds like the Jira list is the way to go.
> >>
> >> How can I go about getting the list created and messages redirected?  I
> >> think iss...@activemq.apache.org  is the way to go.
> >>
> >> Art
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://activemq.2283324.n4.nabble.com/DISCUSS-dev-mailing-list-is-cluttered-tp4694420p4694440.html
> >> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> >>
> >
> >
> >
> > --
> > perl -e 'print
> > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E >
> > ActiveMQ in Action: http://bit.ly/2je6cQ
> > Blog: http://bruceblog.org/
> > Twitter: http://twitter.com/brucesnyder
>
>
>
> --
> Clebert Suconic
> http://community.jboss.org/people/clebert.suco...@jboss.com
> http://clebertsuconic.blogspot.com
>

Re: ApacheCon 2015

[James Carman]

I'll be there from Sunday night to Friday morning

On Saturday, April 4, 2015, Bruce Snyder  wrote:

> Who is planning to attend ApacheCon later this month in Austin, TX? I am
> really interested in collaborating with others and helping to sort out some
> of the issues that the project is currently facing. Oftentimes, some
> face-to-face time is helpful to reach consensus (I've been through other
> bumpy times on ASF projects so I much experience in this realm).
>
> I haven't made travel arrangements yet, but if I can swing it schedule wise
> I'd like to come for a 2-3 days if possible. Before I do this, however, I'd
> like to know who else is planning to attend.
>
> Bruce
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>

Re: [VOTE] Apache ActiveMQ 6.0.0 (RC3)

[James Carman]

On Wed, Apr 1, 2015 at 7:23 AM, Gary Tully  wrote:
> Would version 10 allow you to pause and be happy with 5.x for the next
> few years, till 10.x gets a chance to bed in?
>

A higher number isn't the answer.  HQ needs to go to the incubator.

[PROPOSAL] Pluggable Brokers...

[James Carman]

All,

With all the talk over the last week or so regarding the "Broker
Wars", especially after reading Rob Davies' email about how the broker
has been tweaked through the years to emphasize different aspects
(long-term storage for instance), it occurred to me that we might be
able to move past all this craziness by providing an abstraction layer
above the broker and try to make them "pluggable."

If there really are situations where the broker needs to focus on one
particular aspect of message delivery, that sounds to me like the
"strategy" pattern.  If a broker can be written in such a way that it
is allowed to focus on certain aspects and maybe ignore or completely
forego others, then it would seem to me that the code could be made
much more straight-forward, because it doesn't have to try to be the
"swiss army knife", solving everyone's problems at one time.

Of course, this may be just a pipe dream and there's no way to do it
(admittedly I'm not terribly familiar with the code), but I thought
I'd throw it out there as a possible approach.  I mean, we do this
sort of thing already with the persistence providers, so maybe there's
an opportunity here as well.

Thoughts?

James

Re: [DISCUSS} HornetQ & ActiveMQ's next generation

[James Carman]

I think I'm missing something here.  How does the existence of some
other messaging broker in the incubator (or anywhere for that matter)
cause extra work for the AMQ community?  If you mean they'll have to
try to keep up with the Joneses, then maybe I get it, but that's
what's called competition.  And, it's good for the market.  What would
the world be like if Pepsi and Coke merged (aside from the unfortunate
name "poke")?  It'd be "dogs and cats living together... mass
hysteria!"

On Fri, Mar 27, 2015 at 2:43 PM, Jon Anstey  wrote:
> All the devs writing/maintaining the code?
>
> On Fri, Mar 27, 2015 at 4:06 PM, Hadrian Zbarcea  wrote:
>
>> Really Jon?
>>
>> How will that "make more work for everyone"? Who is everyone.
>>
>> Hadrian
>>
>>
>> On 03/27/2015 02:30 PM, Jon Anstey wrote:
>>
>>> If you read the initial thread for the code grant, the whole point was to
>>> NOT have 2 brokers & communities; it was to work together as one.
>>>
>>> "There is a lot of overlap in the capabilities of the two brokers today
>>> and
>>> it strikes us that it would be beneficial to both communities for us to
>>> join
>>> forces to build one truly great JMS broker rather than spend our time
>>> duplicating efforts on both brokers."
>>>
>>> http://activemq.2283324.n4.nabble.com/Possible-HornetQ-
>>> donation-to-ActiveMQ-td4682971.html
>>>
>>> IMO putting this new broker in the incubator is a bad idea and will just
>>> make more work for everyone...
>>>
>>>
>>> On Fri, Mar 27, 2015 at 3:23 PM, James Carman >> >
>>> wrote:
>>>
>>>  I'm with Hadrian on this one.  Incubation seems like the proper route
>>>> for this code, to me.  HornetQ already has a well-established
>>>> community and apparently a kick-ass code base.  One might wonder why
>>>> HornetQ wants to come here in the first place if everything is so
>>>> unicorns and rainbows.  Anyway, if there are features of AMQ that
>>>> HornetQ (or whatever name it decides to take on here at the ASF) wants
>>>> from AMQ, it can easily integrate them as they see fit, without the
>>>> burden of trying to maintain backward compatibility and develop a
>>>> smooth migration path.
>>>>
>>>> On Fri, Mar 27, 2015 at 1:28 PM, Hiram Chirino 
>>>> wrote:
>>>>
>>>>> I've been trying to keep quite to get an idea of different folks view
>>>>> points.  At this point I think it's fair to say that the ActiveMQ
>>>>> project has not reached consensus that the HornetQ code contribution
>>>>> is ready to become the successor to ActiveMQ 5.
>>>>>
>>>>> So calling the git repo for the code donation activemq-6, was probably
>>>>> a bad idea.  A this point I think the code donation should follow the
>>>>> path the apollo took and switch to a code name.  It should continue to
>>>>> do milestone release and solicit the help of ActiveMQ 5.x
>>>>> users/developers to help mature into the successor that it wants to
>>>>> become.
>>>>>
>>>>> We can then revisit renaming to an ActiveMQ N, once it has matured to
>>>>> the point there is little objection to it becoming the successor.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 27, 2015 at 11:22 AM, Rich Bowen 
>>>>> wrote:
>>>>>
>>>>>> [I see that some of what I put in this email has already been said by
>>>>>> others, but I'm going to go ahead and send it, because it needs to be
>>>>>> heard.)
>>>>>>
>>>>>> On 03/26/2015 12:02 PM, Hiram Chirino wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> If you take a peek at the source code for the code grant I think
>>>>>>> you'll notice that all the original HornetQ references have been
>>>>>>> removed/replaced by ActiveMQ.  So I think we are ok from a TM
>>>>>>> perspective.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> A much larger concern (at least to me) is not merely the naming, but
>>>>>> the
>>>>>> perception that a completely new codebase has 

Re: [DISCUSS} HornetQ & ActiveMQ's next generation

[James Carman]

So, how does this make more work for the AMQ community?  Or the
HornetQ community for that matter?

On Fri, Mar 27, 2015 at 2:36 PM, Jon Anstey  wrote:
> Then we are back to having 2 brokers & communities.
>
> On Fri, Mar 27, 2015 at 4:03 PM, James Carman 
> wrote:
>
>> How does it make more work for "everyone"?
>>
>> On Fri, Mar 27, 2015 at 2:30 PM, Jon Anstey  wrote:
>> > If you read the initial thread for the code grant, the whole point was to
>> > NOT have 2 brokers & communities; it was to work together as one.
>> >
>> > "There is a lot of overlap in the capabilities of the two brokers today
>> and
>> > it strikes us that it would be beneficial to both communities for us to
>> > join
>> > forces to build one truly great JMS broker rather than spend our time
>> > duplicating efforts on both brokers."
>> >
>> >
>> http://activemq.2283324.n4.nabble.com/Possible-HornetQ-donation-to-ActiveMQ-td4682971.html
>> >
>> > IMO putting this new broker in the incubator is a bad idea and will just
>> > make more work for everyone...
>> >
>> >
>> > On Fri, Mar 27, 2015 at 3:23 PM, James Carman <
>> ja...@carmanconsulting.com>
>> > wrote:
>> >
>> >> I'm with Hadrian on this one.  Incubation seems like the proper route
>> >> for this code, to me.  HornetQ already has a well-established
>> >> community and apparently a kick-ass code base.  One might wonder why
>> >> HornetQ wants to come here in the first place if everything is so
>> >> unicorns and rainbows.  Anyway, if there are features of AMQ that
>> >> HornetQ (or whatever name it decides to take on here at the ASF) wants
>> >> from AMQ, it can easily integrate them as they see fit, without the
>> >> burden of trying to maintain backward compatibility and develop a
>> >> smooth migration path.
>> >>
>> >> On Fri, Mar 27, 2015 at 1:28 PM, Hiram Chirino 
>> >> wrote:
>> >> > I've been trying to keep quite to get an idea of different folks view
>> >> > points.  At this point I think it's fair to say that the ActiveMQ
>> >> > project has not reached consensus that the HornetQ code contribution
>> >> > is ready to become the successor to ActiveMQ 5.
>> >> >
>> >> > So calling the git repo for the code donation activemq-6, was probably
>> >> > a bad idea.  A this point I think the code donation should follow the
>> >> > path the apollo took and switch to a code name.  It should continue to
>> >> > do milestone release and solicit the help of ActiveMQ 5.x
>> >> > users/developers to help mature into the successor that it wants to
>> >> > become.
>> >> >
>> >> > We can then revisit renaming to an ActiveMQ N, once it has matured to
>> >> > the point there is little objection to it becoming the successor.
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Mar 27, 2015 at 11:22 AM, Rich Bowen 
>> wrote:
>> >> >> [I see that some of what I put in this email has already been said by
>> >> >> others, but I'm going to go ahead and send it, because it needs to be
>> >> >> heard.)
>> >> >>
>> >> >> On 03/26/2015 12:02 PM, Hiram Chirino wrote:
>> >> >>>
>> >> >>> Hi Chris,
>> >> >>>
>> >> >>> If you take a peek at the source code for the code grant I think
>> >> >>> you'll notice that all the original HornetQ references have been
>> >> >>> removed/replaced by ActiveMQ.  So I think we are ok from a TM
>> >> >>> perspective.
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >> A much larger concern (at least to me) is not merely the naming, but
>> the
>> >> >> perception that a completely new codebase has been brought to the
>> >> project,
>> >> >> replaced the existing work wholesale, and been called the next
>> version.
>> >> This
>> >> >> is how it's been described to me by several different members of the
>> >> project
>> >> >> community, and their perception is that this has been done without
>> the
>> >> >> consent of the community. This is, of

Re: [DISCUSS} HornetQ & ActiveMQ's next generation

[James Carman]

How does it make more work for "everyone"?

On Fri, Mar 27, 2015 at 2:30 PM, Jon Anstey  wrote:
> If you read the initial thread for the code grant, the whole point was to
> NOT have 2 brokers & communities; it was to work together as one.
>
> "There is a lot of overlap in the capabilities of the two brokers today and
> it strikes us that it would be beneficial to both communities for us to
> join
> forces to build one truly great JMS broker rather than spend our time
> duplicating efforts on both brokers."
>
> http://activemq.2283324.n4.nabble.com/Possible-HornetQ-donation-to-ActiveMQ-td4682971.html
>
> IMO putting this new broker in the incubator is a bad idea and will just
> make more work for everyone...
>
>
> On Fri, Mar 27, 2015 at 3:23 PM, James Carman 
> wrote:
>
>> I'm with Hadrian on this one.  Incubation seems like the proper route
>> for this code, to me.  HornetQ already has a well-established
>> community and apparently a kick-ass code base.  One might wonder why
>> HornetQ wants to come here in the first place if everything is so
>> unicorns and rainbows.  Anyway, if there are features of AMQ that
>> HornetQ (or whatever name it decides to take on here at the ASF) wants
>> from AMQ, it can easily integrate them as they see fit, without the
>> burden of trying to maintain backward compatibility and develop a
>> smooth migration path.
>>
>> On Fri, Mar 27, 2015 at 1:28 PM, Hiram Chirino 
>> wrote:
>> > I've been trying to keep quite to get an idea of different folks view
>> > points.  At this point I think it's fair to say that the ActiveMQ
>> > project has not reached consensus that the HornetQ code contribution
>> > is ready to become the successor to ActiveMQ 5.
>> >
>> > So calling the git repo for the code donation activemq-6, was probably
>> > a bad idea.  A this point I think the code donation should follow the
>> > path the apollo took and switch to a code name.  It should continue to
>> > do milestone release and solicit the help of ActiveMQ 5.x
>> > users/developers to help mature into the successor that it wants to
>> > become.
>> >
>> > We can then revisit renaming to an ActiveMQ N, once it has matured to
>> > the point there is little objection to it becoming the successor.
>> >
>> >
>> >
>> > On Fri, Mar 27, 2015 at 11:22 AM, Rich Bowen  wrote:
>> >> [I see that some of what I put in this email has already been said by
>> >> others, but I'm going to go ahead and send it, because it needs to be
>> >> heard.)
>> >>
>> >> On 03/26/2015 12:02 PM, Hiram Chirino wrote:
>> >>>
>> >>> Hi Chris,
>> >>>
>> >>> If you take a peek at the source code for the code grant I think
>> >>> you'll notice that all the original HornetQ references have been
>> >>> removed/replaced by ActiveMQ.  So I think we are ok from a TM
>> >>> perspective.
>> >>>
>> >>
>> >>
>> >>
>> >> A much larger concern (at least to me) is not merely the naming, but the
>> >> perception that a completely new codebase has been brought to the
>> project,
>> >> replaced the existing work wholesale, and been called the next version.
>> This
>> >> is how it's been described to me by several different members of the
>> project
>> >> community, and their perception is that this has been done without the
>> >> consent of the community. This is, of course, a fairly serious
>> accusation.
>> >>
>> >> Related to this is the assertion that the PMC has been somewhat biased
>> on
>> >> who has been invited to join their numbers, based on corporate
>> affiliation -
>> >> an even more serious accusation.
>> >>
>> >> The analogy that was offered to me was that of the IIS code being
>> imported
>> >> into the Apache httpd code tree, and released as httpd 3.0, by virtue
>> of a
>> >> majority Microsoft presence on the PMC.
>> >>
>> >> I recognize that this is a very harsh accusation. The folks that have
>> >> brought this concern to me have done so privately because they feel that
>> >> their voice is ignored on the PMC list.
>> >>
>> >> In terms of how this situation might be resolved, two things have been
>> >> suggested.
>> >>
>> >> 1) Invite some of your 30+ non-PMC committers onto the PMC.
>> >>
>> >> 2) Go ahead and release something based on HornetQ, just don't call it
>> the
>> >> next version of ActiveMQ over the objections of the minority. (I see
>> that
>> >> this solution has been addressed by others, recommending that the code
>> be
>> >> taken to the incubator.)
>> >>
>> >>
>> >> --
>> >> Rich Bowen - rbo...@rcbowen.com - @rbowen
>> >> http://apachecon.com/ - @apachecon
>> >
>> >
>> >
>> > --
>> > Hiram Chirino
>> > Engineering | Red Hat, Inc.
>> > hchir...@redhat.com | fusesource.com | redhat.com
>> > skype: hiramchirino | twitter: @hiramchirino
>>
>
>
>
> --
> Cheers,
> Jon
> ---
> Red Hat, Inc.
> Email: jans...@redhat.com
> Web: http://redhat.com
> Twitter: jon_anstey
> Blog: http://janstey.blogspot.com
> Author of Camel in Action: http://manning.com/ibsen

Re: [DISCUSS} HornetQ & ActiveMQ's next generation

[James Carman]

I'm with Hadrian on this one.  Incubation seems like the proper route
for this code, to me.  HornetQ already has a well-established
community and apparently a kick-ass code base.  One might wonder why
HornetQ wants to come here in the first place if everything is so
unicorns and rainbows.  Anyway, if there are features of AMQ that
HornetQ (or whatever name it decides to take on here at the ASF) wants
from AMQ, it can easily integrate them as they see fit, without the
burden of trying to maintain backward compatibility and develop a
smooth migration path.

On Fri, Mar 27, 2015 at 1:28 PM, Hiram Chirino  wrote:
> I've been trying to keep quite to get an idea of different folks view
> points.  At this point I think it's fair to say that the ActiveMQ
> project has not reached consensus that the HornetQ code contribution
> is ready to become the successor to ActiveMQ 5.
>
> So calling the git repo for the code donation activemq-6, was probably
> a bad idea.  A this point I think the code donation should follow the
> path the apollo took and switch to a code name.  It should continue to
> do milestone release and solicit the help of ActiveMQ 5.x
> users/developers to help mature into the successor that it wants to
> become.
>
> We can then revisit renaming to an ActiveMQ N, once it has matured to
> the point there is little objection to it becoming the successor.
>
>
>
> On Fri, Mar 27, 2015 at 11:22 AM, Rich Bowen  wrote:
>> [I see that some of what I put in this email has already been said by
>> others, but I'm going to go ahead and send it, because it needs to be
>> heard.)
>>
>> On 03/26/2015 12:02 PM, Hiram Chirino wrote:
>>>
>>> Hi Chris,
>>>
>>> If you take a peek at the source code for the code grant I think
>>> you'll notice that all the original HornetQ references have been
>>> removed/replaced by ActiveMQ.  So I think we are ok from a TM
>>> perspective.
>>>
>>
>>
>>
>> A much larger concern (at least to me) is not merely the naming, but the
>> perception that a completely new codebase has been brought to the project,
>> replaced the existing work wholesale, and been called the next version. This
>> is how it's been described to me by several different members of the project
>> community, and their perception is that this has been done without the
>> consent of the community. This is, of course, a fairly serious accusation.
>>
>> Related to this is the assertion that the PMC has been somewhat biased on
>> who has been invited to join their numbers, based on corporate affiliation -
>> an even more serious accusation.
>>
>> The analogy that was offered to me was that of the IIS code being imported
>> into the Apache httpd code tree, and released as httpd 3.0, by virtue of a
>> majority Microsoft presence on the PMC.
>>
>> I recognize that this is a very harsh accusation. The folks that have
>> brought this concern to me have done so privately because they feel that
>> their voice is ignored on the PMC list.
>>
>> In terms of how this situation might be resolved, two things have been
>> suggested.
>>
>> 1) Invite some of your 30+ non-PMC committers onto the PMC.
>>
>> 2) Go ahead and release something based on HornetQ, just don't call it the
>> next version of ActiveMQ over the objections of the minority. (I see that
>> this solution has been addressed by others, recommending that the code be
>> taken to the incubator.)
>>
>>
>> --
>> Rich Bowen - rbo...@rcbowen.com - @rbowen
>> http://apachecon.com/ - @apachecon
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino

Re: CPU core/thread scaling test

[James Carman]

Oh, I misunderstood.  Gotcha.  I was thinking the idea was that AMQ
wasn't doing a good job spreading itself across the available
cores/CPUs.  I'm picking up what you're putting down now.  Thanks,
Hiram.

On Fri, Mar 27, 2015 at 9:11 AM, Hiram Chirino  wrote:
> What ideally should happen is that under high load the network should
> be the bottleneck.  But right now CPU is the bottleneck.
>
> On Fri, Mar 27, 2015 at 8:53 AM, James Carman
>  wrote:
>> Is the expected behavior that even under high load AMQ would only be
>> using one core/CPU, or less than it could/should be in some way?
>>
>> On Fri, Mar 27, 2015 at 8:37 AM, Jamie G.  wrote:
>>> Thank you for the links - I'll try setting this up on my test lab.
>>>
>>> Cheers,
>>> Jamie
>>>
>>> On Fri, Mar 27, 2015 at 9:59 AM, Gary Tully  wrote:
>>>> you can also use the producer/consumer examples from a distro.
>>>> Last time I was trying to saturate a network I uses some of the scripts at
>>>> https://github.com/gtully/broker-run/blob/master/scripts/clients.sh
>>>>
>>>> I have not been in there for a while but you may find it useful to run
>>>> parallel load over multiple destinations.
>>>>
>>>> On 27 March 2015 at 10:14, Jamie G.  wrote:
>>>>> Hi All,
>>>>>
>>>>> It was mentioned on another thread that ActiveMQ has hard challenges
>>>>> with CPU core/thread scaling - I was wondering if there was a test
>>>>> case/script published some where that shows this issue occurring?
>>>>>
>>>>> Cheers,
>>>>> Jamie
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino

Re: CPU core/thread scaling test

[James Carman]

Is the expected behavior that even under high load AMQ would only be
using one core/CPU, or less than it could/should be in some way?

On Fri, Mar 27, 2015 at 8:37 AM, Jamie G.  wrote:
> Thank you for the links - I'll try setting this up on my test lab.
>
> Cheers,
> Jamie
>
> On Fri, Mar 27, 2015 at 9:59 AM, Gary Tully  wrote:
>> you can also use the producer/consumer examples from a distro.
>> Last time I was trying to saturate a network I uses some of the scripts at
>> https://github.com/gtully/broker-run/blob/master/scripts/clients.sh
>>
>> I have not been in there for a while but you may find it useful to run
>> parallel load over multiple destinations.
>>
>> On 27 March 2015 at 10:14, Jamie G.  wrote:
>>> Hi All,
>>>
>>> It was mentioned on another thread that ActiveMQ has hard challenges
>>> with CPU core/thread scaling - I was wondering if there was a test
>>> case/script published some where that shows this issue occurring?
>>>
>>> Cheers,
>>> Jamie

Re: [VOTE] Apache ActiveMQ 6.0.0 (RC3)

[James Carman]

I for one do not agree with this direction the project is taking.
What are the benefits to AMQ as a project?  I have heard some talk of
a "cleaner codebase" or whatever, but that sounds very subjective.
How does switching to HornetQ benefit the users of AMQ?  Will their
migration be a pain?  Is the AMQ codebase that far gone, with nothing
left but to abandon ship and take everything of value over to HornetQ?

Don't get me wrong, I'm all for leaner, cleaner, more maintainable
code.  Honestly, I haven't had time to take a look at what's there for
"AMQ6" yet.  It may be the cat's pajamas for all I know.  From the
original [VOTE], it wasn't obvious (at least not to me) that the
direction would be to completely abandon the current AMQ code.  It
would have seemed like we would adapt code from HornetQ (is that last
Q supposed to be capitalized?) into AMQ, not the other way around.
This seems like a classic "bait-and-switch", honestly.


On Tue, Mar 24, 2015 at 9:26 AM, Hadrian Zbarcea  wrote:
> That's my point :). How do you define general consensus?
>
> This very much looks like HornetQ taking over ActiveMQ. It very much looks
> to me like two different groups doing their own thing independently on the
> same mailing list.
>
> More I have to think about it, more uneasy I feel. One would have expected
> to see some activemq6/hornetq presence at apachecon for instance. I don't
> see any efforts to build a community besides this 'evolution' from
> activemq5. Are there breakout sessions planned at the redhat summit? How is
> the community going to grow?
>
> I am totally confused. You inform us that you will "follow up with a new RC
> based on the 6.0.0.M# versioning". Ok, and then what?
>
> Cheers,
> Hadrian
>
>
>
>
> On 03/24/2015 08:59 AM, Martyn Taylor wrote:
>>
>> I realise there is still some anxiety, but the general consensus seems
>> to be to move forward with the ActiveMQ 6.0.0.M#. I'd like to continue
>> moving forward with getting an initial release of the HornetQ code
>> donation out there for people to use and evaluate. I'll follow up with a
>> new RC based on 6.0.0.M# versioning.
>>
>> On 24/03/15 12:07, Hadrian Zbarcea wrote:
>>>
>>> Hi David,
>>>
>>> I actually fully agree with your statement in principle. Personally, I
>>> would be all for it, we did the same kind of rewrite in Camel when we
>>> moved from 1.x to 2.0, and it was a long and painful process. Speaking
>>> of which there were talks about a Camel 3.0 for at least 3 years that
>>> I am quite skeptical of.
>>>
>>> In this case, hornetq is actually a completely different product,
>>> voted into the community by a vendor who has the vast majority of the
>>> pmc votes. Even that would not matter that much if the rest of the
>>> community would buy into the vision of hornetq morphing into the next
>>> amq, more or less a drop in replacement as others stated in the thread.
>>>
>>> Your analogy with Apollo is exactly what I mean. As much as I like the
>>> elegance of scala I did not buy into its ability to catalyse a
>>> community. If enough users jump off the activemq 5.x wagon and its
>>> successor doesn't get enough steam, then activemq would reach a "dead
>>> end".
>>>
>>> I don't know what the future would bring. And honestly, I don't know
>>> what the best choice is. Based on my previous experience, I choose to
>>> err on the conservative side, yet I wish for the best.
>>>
>>> The onus is on the new podling to build a community. The fact that it
>>> was adopted by the activemq project doesn't mean that it must use the
>>> same name, it means that the activemq pmc took on the duty of
>>> mentoring the new committers (past example, among others: smx kernel
>>> moving to felix and then going tlp).
>>>
>>> Speaking of mentoring, it is not something that can be imposed.
>>> Personally, I have never been asked anything by new committers in the
>>> activemq community. I do however mentor other communities. Tinkerpop
>>> is such an example, and man, it's a joy, the project is growing well
>>> and the technology is awesome. There are other examples where it
>>> doesn't work so well.
>>>
>>> Bottom line, activemq6 must build a community. With a different name
>>> it could prove that it's capable of doing it on its own. This way it's
>>> stealing from the activemq5 community. That's fine, but then address
>>> its needs and make the users happy: seamless migration, near drop in
>>> replacement.
>>>
>>> Cheers,
>>> Hadrian
>>>
>>>
>>>
>>> On 03/23/2015 10:43 PM, David Jencks wrote:

 It seems to me that a different name would mean a different project.
 IIUC AMQ accepted the code so not having it turn into amq-xxx seems a
 bit odd to me.

 What is stopping all the non-jboss-employees (yes, showing my age
 here) from enthusiastically digging into the code and adapting from
 amq 5 or implementing anew all the missing bits? My limited
 understanding is that the amq 5 broker sort of reached a dead end and
 needed a rew

Re: [VOTE] Apache ActiveMQ 6.0.0 (RC3)

[James Carman]

I think the point is from the user's perspective it's not a complete
rewrite.  Most things look and smell like good ole Tomcat when you
upgrade.  Sure there are new features sprinkled about, but you don't
have to learn everything anew.


On Fri, Mar 20, 2015 at 1:19 PM, Hiram Chirino  wrote:
> Tomcat has had complete re-writes.  That's what major ver number
> change can mean.
>
> On Fri, Mar 20, 2015 at 12:30 PM, artnaseef  wrote:
>> One thing I see different here from other project major version bumps - we're
>> still talking a complete rewrite.  With something like Tomcat 7 to Tomcat 8,
>> there's still a reasonable expectation that the knowledge carried from
>> working with Tomcat 7 carries forward to Tomcat 8 (e.g. the artifacts are
>> likely to have the same purposes; config files are likely to carry the same
>> name, etc).  While major versions will break some of that, a good amount
>> usually remains.
>>
>> For that reason, I'm on the fence about the -M1 idea.  I like the
>> distinguishing name approach.
>>
>> How about activemq-ng (ng = next-gen)?
>>
>>
>>
>> --
>> View this message in context: 
>> http://activemq.2283324.n4.nabble.com/VOTE-Apache-ActiveMQ-6-0-0-tp4692911p4693549.html
>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino

[jira] [Commented] (AMQ-5574) OSGi import ranges for javax.jms should include version 2.0

[James Carman (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14313059#comment-14313059
 ] 

James Carman commented on AMQ-5574:
---

You'd probably not want to go up to just 2.  Most times folks do this:

[1.1,3)

Otherwise, if 2.0.1 was in the mix (assuming that would ever exist), you 
wouldn't see it using "2]"

> OSGi import ranges for javax.jms should include version 2.0
> ---
>
> Key: AMQ-5574
> URL: https://issues.apache.org/jira/browse/AMQ-5574
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: OSGi/Karaf
>Affects Versions: 5.11.0
>Reporter: Matt Pavlovich
>Priority: Minor
>
> The import ranges for the ActiveMQ client bundles should allow, not exclude 
> version 2.0 of the javax.jms API, since JMS 2.0 is backwards compatible with 
> 1.1.  
> This allows for ActiveMQ client jars to be used in runtimes with other JMS 
> 2.0 clients.
> Should be:
> javax.jms;version=[1.1,2] 
> instead of:
> javax.jms;version=[1.1,2)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] How to proper support blueprint in karaf?

[James Carman]

Maybe I'm misunderstanding, but isn't the common approach to providing
plug-in support in blueprint to use the "whiteboard pattern"?


On Wed, Feb 4, 2015 at 1:23 PM, Daniel Kulp  wrote:
>
> Just to follow up on list about this to fully describe the issue and 
> potential solution…
>
> In the ActiveMQ schema that is used for both Blueprint and Spring, we use a 
> bunch of:
>
> 
>
> in places where the user may want to add custom implementation of various 
> things.   Plugins, transports, etc….  In Spring, the normal way this 
> would work is to use the Spring “bean” element to define a bean there.   
> However, blueprint does not have a top level “bean” element.  The only 
> top-level element that blueprint defines is the “blueprint” element.  Thus, 
> you cannot define a custom bean in those locations when using blueprint 
> unless you create a NamespaceHandler and register it and use a custom 
> namespaced element in those locations.   Definitely more work than should be 
> necessary (and certainly more work than when using Spring).
>
> I just committed some changes to aries/blueprint to add “bean” and 
> “reference” elements to the aries “extensions” namespace handler.While 
> that’s not in the blueprint namespace itself, it should work.  The users 
> would need to use something like:
>
> 
>   
>   xmlns:bp="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.5.0";
>class="org.apache.activemq.plugin.StatisticsBrokerPlugin" />
>   
> …..
> 
>
> to get it to work.  This will obviously require a new release of the aries 
> blueprint module and karaf releases and such.  I’m going to do some more 
> testing and verification before pursuing that.   No changes required for 
> ActiveMQ though.
>
> Any additional thoughts/ideas on this are more than welcome.
>
>
> Dan
>
>
>
>> On Feb 4, 2015, at 9:32 AM, Hadrian Zbarcea  wrote:
>>
>> There is rather serious issue related to supporting blueprint in karaf. In 
>> case the jira [1] and it's relevance is not immediately obvious, I am 
>> pointing to it here to draw a bit of attention and choose among the two 
>> proposed solutions (or throw in other options). Lazy consensus defaults to 
>> the 2nd solution. Unfortunately, either solution requires a new bundle.
>>
>> Thanks,
>> Hadrian
>>
>> [1] https://issues.apache.org/jira/browse/AMQ-5554
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: [VOTE][RESULT] Apache ActiveMQ 5.11.0

[James Carman]

I think the misunderstanding is the 72 "business hours" here.  I don't
know that I've ever heard that stipulation.  I've always just heard it
as 72 hours, and this vote satisfies that.

On Wed, Feb 4, 2015 at 12:10 PM, artnaseef  wrote:
> Hey - any thoughts on the length of votes?  Did I misunderstand?
>
> By the way - my tests finally finished - after 17:42!  almost 18 hours!  Who
> said they take 5 hours, or even 10?
>
> There were a few failures, but they all passed on the second try - except
> the karaf test that failed because my system was using ports 61616 and 1099.
> That one passed after freeing those ports.
>
> Cheers.
>
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/VOTE-RESULT-Apache-ActiveMQ-5-11-0-tp4690937p4691059.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: [VOTE] Apache ActiveMQ 5.11.0

[James Carman]

You're splitting hairs here.  Our users expect to be able to download
the source distribution and use THE BUILD to generate the resulting
software.  Part of the build is running the appropriate tests to
assure it is working properly.  How many maven tutorials do you see
that say "run mvn clean install -Dmaven.test.skip=true"?  None; they
tell you to run "mvn clean install".  That's how people expect things
to work.

Why not listen to a legitimate concern from a PMC member (and various
contributors) and hold off on this release to address the test
failure?  It appears that there is a fix for this test already
available, right?  So, merge it in and re-cut the release.

On Thu, Jan 29, 2015 at 8:33 AM, Gary Tully  wrote:
> Hadrian,
> the true writer really is the reader. If the guidelines replaced "
> compile it as provided", with " compile and tests it as provided" your
> suggestion would have some merit.
> We even document[1] the maven skip tests build option.
>
> [1] http://activemq.apache.org/building.html
>
> On 29 January 2015 at 12:06, Hadrian Zbarcea  wrote:
>> Gary,
>>
>> It's a very simple matter. We release source distributions, not binaries.
>> One cannot reliably build binaries from the source distro. Even with -fae,
>> everything else depending stomp is skipped, so failures may be hiding other
>> problems. I would suggest carefully reviewing the ASF release policy [1], in
>> particular the #what and #approving-a-release sections. Note the use of
>> terms "must" (pmc must obey requirements [...]) and "may" (releases may not
>> be vetoed).
>>
>> How about re-cutting the release after making sure the tests pass reliably?
>>
>> Cheers,
>> Hadrian
>>
>>
>> [1] http://www.apache.org/dev/release.html
>>
>>
>>
>> On 01/29/2015 06:17 AM, Gary Tully wrote:
>>>
>>> Dan,
>>> the test is mixing stomp and openwire and asserting a jms semantic in
>>> the event of a stomp disconnect without an unsubscribe. The patch
>>> applied broker configuration that makes the test work reliably. Having
>>> a reliable redelivery flag semantic has been evolving for some time.
>>> Stomp users have never had redelivery flag semantics that could be
>>> relied on so they won't care. The full story is in the commit log.
>>>
>>> On 28 January 2015 at 17:26, Daniel Kulp  wrote:

 I’m more or less -1 until someone can more fully explain the issue with
 the failing tests.

 The “patch” changes the test, but my question really is whether the
 original test code is “correct” and is really exposing some flaw in the
 stomp code that the new patch is really just working around.   Are users
 that are using stomp going to have to make the same changes that were done
 in the test in their environments?   If so, that’s a bigger issue.

 Thanks!
 Dan



> On Jan 26, 2015, at 4:02 PM, Gary Tully  wrote:
>
> Hi folks,
>
> I've just cut a second release candidate for the long-awaited 5.11.0
> release.
> This release has more than 120 bug fixes and improvements.
>
> Could you review the artifacts and vote? Especially, it would be great
> if
> you could test the unix shell script and make sure there's no any
> regressions
> on the platform you're using.
>
> The list of resolved issues is here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12324951
>
> You can get binary distributions here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/apache-activemq/5.11.0/
>
> Source archives are here:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/activemq-parent/5.11.0/
>
> Maven2 repository is at:
>
> https://repository.apache.org/content/repositories/orgapacheactivemq-1014/
>
> Source tag:
>
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=f6eb86ee31640427d0f953847f38fcf81a71f9e1
>
> The vote will remain open for 72 hours.
>
> [ ] +1 Release the binary as Apache ActiveMQ 5.11.0
> [ ] -1 Veto the release (provide specific comments)
>
> Here's my +1
>
> Regards
>
> Gary

 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

>>

Re: [DISCUSS] Have every committer on the PMC by default

[James Carman]

-1.  Showing you have the technical chops to code (merit) != the
ability to be a good steward and act on behalf of the foundation in
order to manage the project effectively.

On Thu, Jan 29, 2015 at 8:42 AM, Gary Tully  wrote:
> In that way, committers that are interested in project management
> duties can indicate same with their votes. Effectively self elect to
> step up to the task.
>
> What is the down side?

Re: [VOTE] Apache ActiveMQ 5.11.0

[James Carman]

If it doesn't build reliably from src, then I wouldn't suggest we
release it.  -1 from me

On Mon, Jan 26, 2015 at 4:02 PM, Gary Tully  wrote:
> Hi folks,
>
> I've just cut a second release candidate for the long-awaited 5.11.0 release.
> This release has more than 120 bug fixes and improvements.
>
> Could you review the artifacts and vote? Especially, it would be great if
> you could test the unix shell script and make sure there's no any regressions
> on the platform you're using.
>
> The list of resolved issues is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12324951
>
> You can get binary distributions here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/apache-activemq/5.11.0/
>
> Source archives are here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/activemq-parent/5.11.0/
>
> Maven2 repository is at:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1014/
>
> Source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=f6eb86ee31640427d0f953847f38fcf81a71f9e1
>
> The vote will remain open for 72 hours.
>
> [ ] +1 Release the binary as Apache ActiveMQ 5.11.0
> [ ] -1 Veto the release (provide specific comments)
>
> Here's my +1
>
> Regards
>
> Gary

Re: [VOTE] Release Apache ActiveMQ 5.10.1 (3rd attempt)

[James Carman]

So much for a quick answer. ;-) I am not alone in my thinking. Obviously
someone else feels the same way, the author of that document. It is not a
huge issue to me, otherwise I would've voted -1.  Regardless, I am happy to
see you more frequent releases out of this project. It is a great sign!

On Monday, January 19, 2015, Hadrian Zbarcea  wrote:

> Hi James,
>
> We can debate this off the vote thread if you prefer, but a quick answer
> would be that the PMC approves a release. It has absolutely no relation
> with who builds it.
>
> (check) the release process requires code modifications (pom.xml) it MUST
> be performed by a committer.
> (check) artifacts MUST be digitally signed (PGP) key.
> (check) Key MUST be recorded in the repository (KEYS)
> (check) Key SHOULD be published in a public key store
> (check) Key SHOULD be signed by another ASFer
>
> The only awkward aspect is that if the release manager is not a PMC
> member, he has a non-binding vote on his own release. So if a community
> trusts a committer to build a legally binding release, it probably trusts
> him to provide project oversight. That's one way to build merit to become a
> PMC member. So I don't see anything improper to prompt a *negative* zero.
>
> Cheers,
> Hadrian
>
>
> On 01/19/2015 03:48 PM, James Carman wrote:
>
>> Hadrian,
>>
>> I'm not inventing anything and I didn't say it was a rule, only my
>> preference:
>>
>> "Note that the PMC is responsible for all artifacts in their distribution
>> directory, which is a subdirectory of www.apache.org/dist/ ; and all
>> artifacts placed in their directory must be signed by a committer,
>> preferably by a PMC member. It is also necessary for the PMC to ensure
>> that
>> the source package is sufficient to build any binary artifacts associated
>> with the release."
>>
>> http://www.apache.org/dev/release.html
>>
>>
>> On Monday, January 19, 2015, Hadrian Zbarcea  wrote:
>>
>>  +1 (binding)
>>>
>>> Looks good, solid release, improvement from 5.10.0. Comments:
>>>
>>> * sigs, legal files, look good
>>> * build from source looks good (DbRestartJDBCQueueMasterSlaveL
>>> easeQuiesceTest
>>> failed, passed on second run)
>>> * smoke test in karaf looks good
>>> * this is actually the 4th attempt
>>> * @James: are we inventing new rules?
>>>
>>> Somebody, I think Dejan, suggested we should have automated builds on the
>>> maintenance branches to spot regressions earlier. Great suggestion, not
>>> sure if we should do it for 5.10.x, but definitely for 5.11.x.
>>>
>>> @Art, great work! This was your first release at ASF if I am not
>>> mistaken,
>>> right?
>>>
>>> Cheers,
>>> Hadrian
>>>
>>>
>>>
>>> On 01/15/2015 12:23 PM, James Carman wrote:
>>>
>>>  -0, I would prefer to see the releases signed by a PMC member.
>>>>
>>>> On Thu, Jan 15, 2015 at 12:10 PM, artnaseef  wrote:
>>>>
>>>>  The release candidate for the activemq 5.10.1 release is now built and
>>>>> ready
>>>>> for a vote.
>>>>> This release comes with 34 fixes and 1 administrative jira entry.
>>>>>
>>>>> Please see the list of jira entries here:
>>>>> https://issues.apache.org/jira/issues/?jql=fixVersion%
>>>>> 20%3D%205.10.1%20AND%20project%20%3D%20AMQ
>>>>>
>>>>>
>>>>> You can get binary distributions here:
>>>>> https://repository.apache.org/content/repositories/
>>>>> orgapacheactivemq-1013/org/apache/activemq/apache-activemq/5.10.1/
>>>>>
>>>>>
>>>>> Source archives are here:
>>>>> https://repository.apache.org/content/repositories/
>>>>> orgapacheactivemq-1013/org/apache/activemq/activemq-parent/5.10.1/
>>>>>
>>>>>
>>>>> Maven2 repository is here:
>>>>> https://repository.apache.org/content/repositories/
>>>>> orgapacheactivemq-1013/
>>>>>
>>>>> Source tag:
>>>>> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=
>>>>> 8938d14d434447193b02ba635606aa0fb7a80353
>>>>>
>>>>>
>>>>> NOTE: I used Hadrian's prior thread as a template (thank you Hadrian).
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context: http://activemq.2283324.n4.
>>>>> nabble.com/VOTE-Release-Apache-ActiveMQ-5-10-1-3rd-
>>>>> attempt-tp4689959.html
>>>>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>>>>
>>>>>
>

Re: [VOTE] Release Apache ActiveMQ 5.10.1 (3rd attempt)

[James Carman]

Hadrian,

I'm not inventing anything and I didn't say it was a rule, only my
preference:

"Note that the PMC is responsible for all artifacts in their distribution
directory, which is a subdirectory of www.apache.org/dist/ ; and all
artifacts placed in their directory must be signed by a committer,
preferably by a PMC member. It is also necessary for the PMC to ensure that
the source package is sufficient to build any binary artifacts associated
with the release."

http://www.apache.org/dev/release.html


On Monday, January 19, 2015, Hadrian Zbarcea  wrote:

> +1 (binding)
>
> Looks good, solid release, improvement from 5.10.0. Comments:
>
> * sigs, legal files, look good
> * build from source looks good (DbRestartJDBCQueueMasterSlaveLeaseQuiesceTest
> failed, passed on second run)
> * smoke test in karaf looks good
> * this is actually the 4th attempt
> * @James: are we inventing new rules?
>
> Somebody, I think Dejan, suggested we should have automated builds on the
> maintenance branches to spot regressions earlier. Great suggestion, not
> sure if we should do it for 5.10.x, but definitely for 5.11.x.
>
> @Art, great work! This was your first release at ASF if I am not mistaken,
> right?
>
> Cheers,
> Hadrian
>
>
>
> On 01/15/2015 12:23 PM, James Carman wrote:
>
>> -0, I would prefer to see the releases signed by a PMC member.
>>
>> On Thu, Jan 15, 2015 at 12:10 PM, artnaseef  wrote:
>>
>>> The release candidate for the activemq 5.10.1 release is now built and
>>> ready
>>> for a vote.
>>> This release comes with 34 fixes and 1 administrative jira entry.
>>>
>>> Please see the list of jira entries here:
>>> https://issues.apache.org/jira/issues/?jql=fixVersion%
>>> 20%3D%205.10.1%20AND%20project%20%3D%20AMQ
>>>
>>>
>>> You can get binary distributions here:
>>> https://repository.apache.org/content/repositories/
>>> orgapacheactivemq-1013/org/apache/activemq/apache-activemq/5.10.1/
>>>
>>>
>>> Source archives are here:
>>> https://repository.apache.org/content/repositories/
>>> orgapacheactivemq-1013/org/apache/activemq/activemq-parent/5.10.1/
>>>
>>>
>>> Maven2 repository is here:
>>> https://repository.apache.org/content/repositories/
>>> orgapacheactivemq-1013/
>>>
>>> Source tag:
>>> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=
>>> 8938d14d434447193b02ba635606aa0fb7a80353
>>>
>>>
>>> NOTE: I used Hadrian's prior thread as a template (thank you Hadrian).
>>>
>>>
>>>
>>> --
>>> View this message in context: http://activemq.2283324.n4.
>>> nabble.com/VOTE-Release-Apache-ActiveMQ-5-10-1-3rd-
>>> attempt-tp4689959.html
>>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>>
>>
>

Re: [VOTE] Release Apache ActiveMQ 5.10.1 (3rd attempt)

[James Carman]

-0, I would prefer to see the releases signed by a PMC member.

On Thu, Jan 15, 2015 at 12:10 PM, artnaseef  wrote:
> The release candidate for the activemq 5.10.1 release is now built and ready
> for a vote.
> This release comes with 34 fixes and 1 administrative jira entry.
>
> Please see the list of jira entries here:
> https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%205.10.1%20AND%20project%20%3D%20AMQ
>
>
> You can get binary distributions here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1013/org/apache/activemq/apache-activemq/5.10.1/
>
>
> Source archives are here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1013/org/apache/activemq/activemq-parent/5.10.1/
>
>
> Maven2 repository is here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1013/
>
> Source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=8938d14d434447193b02ba635606aa0fb7a80353
>
>
> NOTE: I used Hadrian's prior thread as a template (thank you Hadrian).
>
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/VOTE-Release-Apache-ActiveMQ-5-10-1-3rd-attempt-tp4689959.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: [DISCUSS] Renaming "trunk" to "master"

[James Carman]

+1, "master" is the norm, no matter which Git workflow you use.

On Mon, Jan 5, 2015 at 1:27 PM, Hadrian Zbarcea  wrote:
> It's a bit confusing, a leftover from the svn days.
>
> I think the rename was supposed to happen but it was somehow overlooked. Any
> objection to rename?
>
> Hadrian

Re: [VOTE] Apache ActiveMQ 5.11.0

[James Carman]

-1

If the build does not succeed, we need to address that before releasing.

James

On Mon, Dec 29, 2014 at 9:26 AM, Dejan Bosanac  wrote:
> Hi folks,
>
> I've just cut a release candidate for the long-awaited 5.11.0 release. This
> release has
> 127 bug fixes and improvements.
>
> Could you review the artifacts and vote? Especially, it would be great if
> you could test unix shell script and make sure there's no any regressions
> on the platform you're using.
>
> The list of resolved issues is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12324951
>
> You can get binary distributions here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1012/org/apache/activemq/apache-activemq/5.11.0/
>
> Source archives are here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1012/org/apache/activemq/activemq-parent/5.11.0/
>
> Maven2 repository is at:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1012/
>
> Source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=48b0cf396c18216899ceb94ee57c01685104223d
>
>
> Please vote to approve this release. As it's the holiday season, I'll let
> this vote open for longer time than usual, so everybody get the chance to
> review it.
>
> [ ] +1 Release the binary as Apache ActiveMQ 5.11.0
> [ ] -1 Veto the release (provide specific comments)
>
> Here's my +1
>
> Regards
> --
> Dejan Bosanac
> --
> Red Hat, Inc.
> dbosa...@redhat.com
> Twitter: @dejanb
> Blog: http://sensatic.net
> ActiveMQ in Action: http://www.manning.com/snyder/

Re: [VOTE] Apache ActiveMQ 5.11.0

[James Carman]

I would also re-word your VOTE options here.  A -1 is not a "veto",
since releases cannot be vetoed.

On Mon, Dec 29, 2014 at 9:26 AM, Dejan Bosanac  wrote:
> Hi folks,
>
> I've just cut a release candidate for the long-awaited 5.11.0 release. This
> release has
> 127 bug fixes and improvements.
>
> Could you review the artifacts and vote? Especially, it would be great if
> you could test unix shell script and make sure there's no any regressions
> on the platform you're using.
>
> The list of resolved issues is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12324951
>
> You can get binary distributions here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1012/org/apache/activemq/apache-activemq/5.11.0/
>
> Source archives are here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1012/org/apache/activemq/activemq-parent/5.11.0/
>
> Maven2 repository is at:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1012/
>
> Source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=48b0cf396c18216899ceb94ee57c01685104223d
>
>
> Please vote to approve this release. As it's the holiday season, I'll let
> this vote open for longer time than usual, so everybody get the chance to
> review it.
>
> [ ] +1 Release the binary as Apache ActiveMQ 5.11.0
> [ ] -1 Veto the release (provide specific comments)
>
> Here's my +1
>
> Regards
> --
> Dejan Bosanac
> --
> Red Hat, Inc.
> dbosa...@redhat.com
> Twitter: @dejanb
> Blog: http://sensatic.net
> ActiveMQ in Action: http://www.manning.com/snyder/

[jira] [Commented] (AMQ-4949) Webconsole doesn't prompt to username/password

[James Carman (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13902057#comment-13902057
 ] 

James Carman commented on AMQ-4949:
---

I don't know if you've already done this or not, but has there been any 
discussion on the mailing lists about this idea?  Is this the general consensus 
on how it should work?  This could impact anyone upgrading, so perhaps we 
should [DISCUSS] on users@activemq?

> Webconsole doesn't prompt to username/password
> --
>
> Key: AMQ-4949
> URL: https://issues.apache.org/jira/browse/AMQ-4949
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: OSGi/Karaf, webconsole
>Affects Versions: 5.9.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>
> When deploying ActiveMQ in Karaf (feature:install), the default 
> etc/activemq.xml use the Karaf JAAS realm. It means that we have to use 
> username/password on the ConnectionFactory to obtain a Connection.
> The ActiveMQ WebConsole should check if the JAASAuthenticatorPlugin is enable 
> and prompt to username ans password.
> Or, it should use ConfigAdmin to get default principal/credential.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (AMQ-5024) Add paging of messages to the webconsole when viewing a deep queue

[James Carman (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13899094#comment-13899094
 ] 

James Carman commented on AMQ-5024:
---

Great suggestion!  I agree, it's not necessary to pull the message body and 
only retrieve that on-demand

> Add paging of messages to the webconsole when viewing a deep queue
> --
>
> Key: AMQ-5024
> URL: https://issues.apache.org/jira/browse/AMQ-5024
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: webconsole
>Affects Versions: 5.9.0
>Reporter: Arthur Naseef
>Assignee: Arthur Naseef
>
> It is not feasible to browse a deep Queue via the webconsole: navigating to 
> the webconsole's Queue list, then browsing the Queue, if there are a large 
> number of messages stored, the webpage takes a very long time, and may 
> timeout.
> Adding pagination of messages so that the webconsole only displays a number 
> of messages per page will make it feasible to browse deep Queues.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: "optional" dependencies and Maven versions

[James Carman]

I don't mind "managing" the dependencies at the root level, but I
would leave it up to submodules to declare exactly what they need in
their pom (pulling in version info from the parent).  Even with that,
I don't really like it that much.  I usually just use properties in
the root to control version numbers and make the submodules use those
properties when they declare their dependencies.


On Tue, Feb 11, 2014 at 2:43 PM, Hiram Chirino  wrote:
> I personally don't really like defining compile/runtime dependencies
> in parent poms (I'm ok with testing dependencies).
>
> On Tue, Feb 11, 2014 at 12:43 PM, Daniel Kulp  wrote:
>>
>> While working with Art to figure out why his web console war was 
>> significantly smaller than mine, we determined that it comes down to what 
>> version of Maven you use to build.  3.0.5 includes more jars than 3.1.1.  
>> Looking into it, it looks like 3.1.1 is using the parent poms 
>> "optional=true" flags for the transitive dependencies whereas 3.0.5 is not.
>>
>> For example, in the parent pom, we have all the spring stuff (spring-core, 
>> spring-context, spring-beans, spring-aop) as "optional=true".  However, 
>> in activemq-web, we set spring-web and spring-webmvc to optional=false.   
>> With 3.0.5, the transitive dependencies of spring-webmvc/spring-web then 
>> also get changed to optional=false.  However, with 3.1.1, they don't.  They 
>> remain optional=true and thus don't get packaged into the war.
>>
>> For consistency sake, I'd like to get this fixed.   Two options:
>>
>> 1) For all the transitive deps pulled in for activemq-web, 
>> acttivemq-web-console, etc... add them directly to the deps in those poms 
>> with a optional=false flag.
>>
>> 2) Remove the optional=true flag from the parent pom and add it into the 
>> other poms where they truly are optional.Avoid the option=false 
>> construct.
>>
>>
>> Thoughts?I believe #2 would be more "maven standard".
>>
>> --
>> Daniel Kulp
>> dk...@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>
>
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino

[jira] [Comment Edited] (AMQ-5041) JMSClientTest is hanging

[James Carman (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897942#comment-13897942
 ] 

James Carman edited comment on AMQ-5041 at 2/11/14 3:52 PM:


You mean this one:

https://github.com/apache/activemq/commit/a165054df9c354ff17856fe8e6390c09bfdf6a2d

Where he added a bunch of @Ignore tags and that's it?  


was (Author: jwcarman):
You mean this one:

https://github.com/apache/activemq/commit/a165054df9c354ff17856fe8e6390c09bfdf6a2d

Where you added a bunch of @Ignore tags and that's it?  

> JMSClientTest is hanging
> 
>
> Key: AMQ-5041
> URL: https://issues.apache.org/jira/browse/AMQ-5041
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
>Reporter: Kevin Earls
>
> The JMSClientTest is currently hanging on multiple test cases.  I'll attach a 
> stack trace, but it looks like the test is hanging during the broker.stop in 
> tearDown().
> I'm going to add @Ignore tags to most of the tests so this stops hanging CI 
> builds.  



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (AMQ-5041) JMSClientTest is hanging

[James Carman (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897942#comment-13897942
 ] 

James Carman commented on AMQ-5041:
---

You mean this one:

https://github.com/apache/activemq/commit/a165054df9c354ff17856fe8e6390c09bfdf6a2d

Where you added a bunch of @Ignore tags and that's it?  

> JMSClientTest is hanging
> 
>
> Key: AMQ-5041
> URL: https://issues.apache.org/jira/browse/AMQ-5041
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
>Reporter: Kevin Earls
>
> The JMSClientTest is currently hanging on multiple test cases.  I'll attach a 
> stack trace, but it looks like the test is hanging during the broker.stop in 
> tearDown().
> I'm going to add @Ignore tags to most of the tests so this stops hanging CI 
> builds.  



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (AMQ-5041) JMSClientTest is hanging

[James Carman (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897930#comment-13897930
 ] 

James Carman commented on AMQ-5041:
---

Hopefully you did more than @Ignore the tests before you marked this as 
"fixed".  Merely marking them as @Ignored doesn't "fix" anything.  

> JMSClientTest is hanging
> 
>
> Key: AMQ-5041
> URL: https://issues.apache.org/jira/browse/AMQ-5041
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
>Reporter: Kevin Earls
>
> The JMSClientTest is currently hanging on multiple test cases.  I'll attach a 
> stack trace, but it looks like the test is hanging during the broker.stop in 
> tearDown().
> I'm going to add @Ignore tags to most of the tests so this stops hanging CI 
> builds.  



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: "Upgrading" Web Console to AngularJS/Bootstrap...

[James Carman]

Well, I would think first pass, we just need to get the current
functionality working using the "new stack" and then add on from
there.


On Mon, Feb 10, 2014 at 3:41 PM, Zakeria Hassan
 wrote:
> In terms of looks I think we have a running example already done in my
> repo. We don't want to only create a console that looks great but rather we
> want to add value (features, UX, etc). Lets get a list of all the problems
> we have in the console here in this discussion and tackle them one by one.
>
> What features that don't exist do we need?
> What problems exist that we need to solve?
> How will this improve the end user experience?
>
>
>
> On Mon, Feb 10, 2014 at 1:37 PM, Tracy Snell  wrote:
>
>> I'm pretty sure there's another couple of threads with the Hawtio
>> discussion that you can refer to to come up to speed on that debate :)
>>
>> I don't recall Angular or Bootstrap being a pro or con in that debate.
>>
>> On Feb 10, 2014, at 12:52 PM, Zakeria Hassan 
>> wrote:
>>
>> > I think if we are going to use Angular.js and Bootstrap we might as well
>> > just use Hawtio because we don't want to repeat the same efforts already
>> > done by members of this community.
>>
>>

Re: "Upgrading" Web Console to AngularJS/Bootstrap...

[James Carman]

Well, the built-in console needs some love.  In order to make it more
"lovable", let's modernize it a bit.  No doubt, hawt.io has already
done some of the stuff we're talking about, but AMQ needs to maintain
its own console also.  I honestly don't see there being a lot of work
to be done to get the console to a happy state again.  I'd say maybe
8-10 hours or so?

On Mon, Feb 10, 2014 at 12:52 PM, Zakeria Hassan
 wrote:
> Hi James,
>
> I think if we are going to use Angular.js and Bootstrap we might as well
> just use Hawtio because we don't want to repeat the same efforts already
> done by members of this community.
>
> Thanks,
> Zak
>
>
>
>
> On Mon, Feb 10, 2014 at 11:38 AM, James Carman
> wrote:
>
>> Yeah, I just want to hear folks chime in on whether they think this is
>> the right way to go with the code.  It definitely needs a "facelift",
>> so that folks can get excited about working on it.  What I have done
>> with the "angularization" is to just set up Spring-MVC-based REST
>> services to feed the UI.  This wasn't too much of a jump away from
>> what's there, since it already uses Spring.  And, for the type of
>> traffic the webconsole should expect, I think Spring-MVC is just fine.
>>  Other than that, the site is one main html file with a bunch of
>> partials for the different screens.
>>
>> On Mon, Feb 10, 2014 at 11:12 AM, Zakeria Hassan
>>  wrote:
>> > Hi,
>> >
>> >
>> > I agree with Hadrian, we want everyone's input. Lets keep it in the
>> mailing
>> > list because its easier to reference and get our community input.
>> Anything
>> > we can discuss on IRC can but done on this mailing list.
>> > Totally want everyone's input and I want to work in an open transparent
>> > way. So lets keep this conversation flowing and the ideas pouring.
>> >
>> >
>> > Thanks,
>> > Zak
>> > @Prospect1010
>> >
>> >
>> >
>> > On Mon, Feb 10, 2014 at 10:49 AM, James Carman
>> > wrote:
>> >
>> >> Well, what I wanted to do was get a feeler for if there are any
>> >> blockers here, before we start doing any work.  Let's hear from the
>> >> dev community a bit more before we go too far.  I wouldn't want our
>> >> work to be wasted if there were any objections.  Anyone?
>> >>
>> >> As Hadrian said in another email, we should definitely try to discuss
>> >> on-list as much as we can.  There's nothing wrong with chatting about
>> >> issues we're having and stuff on IRC, but any *decisions* need to be
>> >> made on the mailing list.  We have to be open to input from the entire
>> >> community.
>> >>
>> >> On Mon, Feb 10, 2014 at 10:40 AM, Zakeria Hassan
>> >>  wrote:
>> >> > Hi James,
>> >> >
>> >> > We can definitely collaborate and make this web console a much better
>> >> > experience for users. I usually get on IRC after work, it would be
>> great
>> >> to
>> >> > chat with you. I know Angular.js so its great to have someone else
>> that
>> >> > knows it too.  Are you online > 7:00pm (EST). Only one thing we need
>> is
>> >> > lots of issues created so in case people ask why. We can point to some
>> >> > existing issues. Anyway we will chat on IRC and come up with a solid
>> >> plan.
>> >> >
>> >> > Thanks,
>> >> > Zak
>> >> >
>> >> >
>> >> >
>> >> > On Mon, Feb 10, 2014 at 10:32 AM, James Carman
>> >> > wrote:
>> >> >
>> >> >> That's great, Zakeria!  The Angular stuff isn't too hard.  Looks like
>> >> >> you've put together a pretty nice looking console.  I'm not jazzed
>> >> >> about merely doing an "upgrade" of the tech.  I'd like to make the
>> >> >> application work better, too.  Although, I guess a good first draft
>> >> >> would be to modernize the existing functionality and then worry about
>> >> >> revamping things to be a bit more robust.  WDYT?
>> >> >>
>> >> >>
>> >> >> On Mon, Feb 10, 2014 at 10:29 AM, Zakeria Hassan
>> >> >>  wrote:
>> >> >> > Hi James,
>> >> >> >
>> >> >> > I've already updated the site to use bootstrap if you check out my
>> >> repo:
>> >> >> >
>> >> >> > https://github.com/zmhassan/activemq.git
>> >> >> >
>> >> >> > If you want you can checkout screen shots on my blog:
>> >> >> >
>> >> >> >
>> >> >>
>> >>
>> http://bzcareermongodb.blogspot.ca/2014/02/remedy-to-javaoutmemory-when-browsing.html
>> >> >> >
>> >> >> > All that is left is setting up Angular.js ...
>> >> >> >
>> >> >> > Lets tag team and drive some amazing upgrades to this console. If
>> you
>> >> >> want
>> >> >> > to chat a bit about this via irc just email me.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Zak
>> >> >> > @Prospect1010
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Feb 10, 2014 at 10:12 AM, James Carman
>> >> >> > wrote:
>> >> >> >
>> >> >> >> Does anyone have objections to modernizing the web console a bit,
>> >> >> >> using AngularJS and Bootstrap?
>> >> >> >>
>> >> >>
>> >>
>>

Re: "Upgrading" Web Console to AngularJS/Bootstrap...

[James Carman]

Yeah, I just want to hear folks chime in on whether they think this is
the right way to go with the code.  It definitely needs a "facelift",
so that folks can get excited about working on it.  What I have done
with the "angularization" is to just set up Spring-MVC-based REST
services to feed the UI.  This wasn't too much of a jump away from
what's there, since it already uses Spring.  And, for the type of
traffic the webconsole should expect, I think Spring-MVC is just fine.
 Other than that, the site is one main html file with a bunch of
partials for the different screens.

On Mon, Feb 10, 2014 at 11:12 AM, Zakeria Hassan
 wrote:
> Hi,
>
>
> I agree with Hadrian, we want everyone's input. Lets keep it in the mailing
> list because its easier to reference and get our community input. Anything
> we can discuss on IRC can but done on this mailing list.
> Totally want everyone's input and I want to work in an open transparent
> way. So lets keep this conversation flowing and the ideas pouring.
>
>
> Thanks,
> Zak
> @Prospect1010
>
>
>
> On Mon, Feb 10, 2014 at 10:49 AM, James Carman
> wrote:
>
>> Well, what I wanted to do was get a feeler for if there are any
>> blockers here, before we start doing any work.  Let's hear from the
>> dev community a bit more before we go too far.  I wouldn't want our
>> work to be wasted if there were any objections.  Anyone?
>>
>> As Hadrian said in another email, we should definitely try to discuss
>> on-list as much as we can.  There's nothing wrong with chatting about
>> issues we're having and stuff on IRC, but any *decisions* need to be
>> made on the mailing list.  We have to be open to input from the entire
>> community.
>>
>> On Mon, Feb 10, 2014 at 10:40 AM, Zakeria Hassan
>>  wrote:
>> > Hi James,
>> >
>> > We can definitely collaborate and make this web console a much better
>> > experience for users. I usually get on IRC after work, it would be great
>> to
>> > chat with you. I know Angular.js so its great to have someone else that
>> > knows it too.  Are you online > 7:00pm (EST). Only one thing we need is
>> > lots of issues created so in case people ask why. We can point to some
>> > existing issues. Anyway we will chat on IRC and come up with a solid
>> plan.
>> >
>> > Thanks,
>> > Zak
>> >
>> >
>> >
>> > On Mon, Feb 10, 2014 at 10:32 AM, James Carman
>> > wrote:
>> >
>> >> That's great, Zakeria!  The Angular stuff isn't too hard.  Looks like
>> >> you've put together a pretty nice looking console.  I'm not jazzed
>> >> about merely doing an "upgrade" of the tech.  I'd like to make the
>> >> application work better, too.  Although, I guess a good first draft
>> >> would be to modernize the existing functionality and then worry about
>> >> revamping things to be a bit more robust.  WDYT?
>> >>
>> >>
>> >> On Mon, Feb 10, 2014 at 10:29 AM, Zakeria Hassan
>> >>  wrote:
>> >> > Hi James,
>> >> >
>> >> > I've already updated the site to use bootstrap if you check out my
>> repo:
>> >> >
>> >> > https://github.com/zmhassan/activemq.git
>> >> >
>> >> > If you want you can checkout screen shots on my blog:
>> >> >
>> >> >
>> >>
>> http://bzcareermongodb.blogspot.ca/2014/02/remedy-to-javaoutmemory-when-browsing.html
>> >> >
>> >> > All that is left is setting up Angular.js ...
>> >> >
>> >> > Lets tag team and drive some amazing upgrades to this console. If you
>> >> want
>> >> > to chat a bit about this via irc just email me.
>> >> >
>> >> >
>> >> >
>> >> > Thanks,
>> >> > Zak
>> >> > @Prospect1010
>> >> >
>> >> >
>> >> >
>> >> > On Mon, Feb 10, 2014 at 10:12 AM, James Carman
>> >> > wrote:
>> >> >
>> >> >> Does anyone have objections to modernizing the web console a bit,
>> >> >> using AngularJS and Bootstrap?
>> >> >>
>> >>
>>

Re: "Upgrading" Web Console to AngularJS/Bootstrap...

[James Carman]

Well, what I wanted to do was get a feeler for if there are any
blockers here, before we start doing any work.  Let's hear from the
dev community a bit more before we go too far.  I wouldn't want our
work to be wasted if there were any objections.  Anyone?

As Hadrian said in another email, we should definitely try to discuss
on-list as much as we can.  There's nothing wrong with chatting about
issues we're having and stuff on IRC, but any *decisions* need to be
made on the mailing list.  We have to be open to input from the entire
community.

On Mon, Feb 10, 2014 at 10:40 AM, Zakeria Hassan
 wrote:
> Hi James,
>
> We can definitely collaborate and make this web console a much better
> experience for users. I usually get on IRC after work, it would be great to
> chat with you. I know Angular.js so its great to have someone else that
> knows it too.  Are you online > 7:00pm (EST). Only one thing we need is
> lots of issues created so in case people ask why. We can point to some
> existing issues. Anyway we will chat on IRC and come up with a solid plan.
>
> Thanks,
> Zak
>
>
>
> On Mon, Feb 10, 2014 at 10:32 AM, James Carman
> wrote:
>
>> That's great, Zakeria!  The Angular stuff isn't too hard.  Looks like
>> you've put together a pretty nice looking console.  I'm not jazzed
>> about merely doing an "upgrade" of the tech.  I'd like to make the
>> application work better, too.  Although, I guess a good first draft
>> would be to modernize the existing functionality and then worry about
>> revamping things to be a bit more robust.  WDYT?
>>
>>
>> On Mon, Feb 10, 2014 at 10:29 AM, Zakeria Hassan
>>  wrote:
>> > Hi James,
>> >
>> > I've already updated the site to use bootstrap if you check out my repo:
>> >
>> > https://github.com/zmhassan/activemq.git
>> >
>> > If you want you can checkout screen shots on my blog:
>> >
>> >
>> http://bzcareermongodb.blogspot.ca/2014/02/remedy-to-javaoutmemory-when-browsing.html
>> >
>> > All that is left is setting up Angular.js ...
>> >
>> > Lets tag team and drive some amazing upgrades to this console. If you
>> want
>> > to chat a bit about this via irc just email me.
>> >
>> >
>> >
>> > Thanks,
>> > Zak
>> > @Prospect1010
>> >
>> >
>> >
>> > On Mon, Feb 10, 2014 at 10:12 AM, James Carman
>> > wrote:
>> >
>> >> Does anyone have objections to modernizing the web console a bit,
>> >> using AngularJS and Bootstrap?
>> >>
>>

Re: "Upgrading" Web Console to AngularJS/Bootstrap...

[James Carman]

That's great, Zakeria!  The Angular stuff isn't too hard.  Looks like
you've put together a pretty nice looking console.  I'm not jazzed
about merely doing an "upgrade" of the tech.  I'd like to make the
application work better, too.  Although, I guess a good first draft
would be to modernize the existing functionality and then worry about
revamping things to be a bit more robust.  WDYT?


On Mon, Feb 10, 2014 at 10:29 AM, Zakeria Hassan
 wrote:
> Hi James,
>
> I've already updated the site to use bootstrap if you check out my repo:
>
> https://github.com/zmhassan/activemq.git
>
> If you want you can checkout screen shots on my blog:
>
> http://bzcareermongodb.blogspot.ca/2014/02/remedy-to-javaoutmemory-when-browsing.html
>
> All that is left is setting up Angular.js ...
>
> Lets tag team and drive some amazing upgrades to this console. If you want
> to chat a bit about this via irc just email me.
>
>
>
> Thanks,
> Zak
> @Prospect1010
>
>
>
> On Mon, Feb 10, 2014 at 10:12 AM, James Carman
> wrote:
>
>> Does anyone have objections to modernizing the web console a bit,
>> using AngularJS and Bootstrap?
>>

"Upgrading" Web Console to AngularJS/Bootstrap...

[James Carman]

Does anyone have objections to modernizing the web console a bit,
using AngularJS and Bootstrap?

Re: [GitHub] activemq pull request: AMQ-5033: webconsole url and html encoding ...

[James Carman]

I believe that's called "pull and pray"?  Maybe that's something else. ;)

On Friday, February 7, 2014, artnaseef  wrote:

> Thank you!  I will try the pull method - I prefer to make sure credit goes
> to the original author in the most straight-forward manner possible.
>
> -art
>
> >
> >
> > GitHub user jwcarman opened a pull request:
> >
> > https://github.com/apache/activemq/pull/15
> >
> > AMQ-5033: webconsole url and html encoding missing
> >
> >
> >
> > You can merge this pull request into a Git repository by running:
> >
> > $ git pull https://github.com/apache/activemq trunk
> >
> > Alternatively you can review and apply these changes as the patch at:
> >
> > https://github.com/apache/activemq/pull/15.patch
> >
> > 
> > commit 5264aa212fdd7f4ee94bd41962c8006d4c97d911
> > Author: James Carman >
> > Date:   2014-02-07T22:14:43Z
> >
> > AMQ-5033: webconsole url and html encoding missing
> >
> > 
> >
> >
> >
> >
> >
> > ___
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> http://activemq.2283324.n4.nabble.com/GitHub-activemq-pull-request-AMQ-5033-webconsole-url-and-html-encoding-tp4677647.html
> > To start a new topic under ActiveMQ - Dev, email
> > ml-node+s2283324n2368404...@n4.nabble.com 
> > To unsubscribe from ActiveMQ - Dev, visit
> >
> http://activemq.2283324.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=2368404&code=YXJ0QGFydG5hc2VlZi5jb218MjM2ODQwNHwtMjA1NDcyNjY5MQ==
>
>
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Re-GitHub-activemq-pull-request-AMQ-5033-webconsole-url-and-html-encoding-tp4677649.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[jira] [Commented] (AMQ-5033) webconsole url and html encoding missing

[James Carman (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13895145#comment-13895145
 ] 

James Carman commented on AMQ-5033:
---

I did a little work on this and submitted a pull request:

https://github.com/apache/activemq/pull/15


> webconsole url and html encoding missing
> 
>
> Key: AMQ-5033
> URL: https://issues.apache.org/jira/browse/AMQ-5033
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: webconsole
>Affects Versions: 5.9.0
>Reporter: Arthur Naseef
>Assignee: Arthur Naseef
>
> While working on AMQ-4813, many cases of passing text through to HTML without 
> proper HTML and URL encoding.
> I believe this can cause security risks, failed operations, or a misformatted 
> UI.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: ActiveMQ Console - let's get the problem defined

[James Carman]

Perhaps the "turd" part was the greater offense being raised.
 Clarification? :)

On Monday, February 3, 2014, artnaseef  wrote:

> Crossed off the 22mb concern (strike-through in case anyone wants to make a
> strong case for the concern, or take action to address it).
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-Console-let-s-get-the-problem-defined-tp4677105p4677355.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: ActiveMQ Console - let's get the problem defined

[James Carman]

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  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"  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
>>  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 
>> 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  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.
>> >> hchir...@redhat.com | fusesource.com | redhat.com
>> >> skype: hiramchirino | twitter: @hiramchirino
>>
>>
>>
>> --
>> Hiram Chirino
>> Engineering | Red Hat, Inc.
>> hchir...@redhat.com | fusesource.com | redhat.com
>> skype: hiramchirino | twitter: @hiramchirino
>>

Re: [VOTE] Move the ActiveMQ web-console to a sub-project.

[James Carman]

-1 The webconsole and the core are very tightly-coupled.  In order to
do something new in the console, or fix a bug, typically a change is
needed in the core.  Thus, they should not be split.

On Tue, Jan 28, 2014 at 9:18 AM, Hiram Chirino  wrote:
> Since there seems to be general agreement that the web-console should
> be moved to a sub-project, lets put it to a vote and make it official.
>
> [ ] +1 Create the activemq-web-console sub-project with the associated
> git, wiki, and jira spaces.
> [ ] -1 Veto the making it a sub-project
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
> blog: Hiram Chirino's Bit Mojo

Re: ActiveMQ Console - let's get the problem defined

[James Carman]

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  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  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.
> hchir...@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino

Re: [VOTE] Move the ActiveMQ web-console to a sub-project.

[James Carman]

I suppose all maven plugins are written at apache?

On Thursday, January 30, 2014, Robert Davies  wrote:

> so hawtio isn't aimed at Apache projects - its a general console - see
> http://hawt.io/plugins/index.html. Why should we try and force an open
> source  community to join the ASF ?
>
> On 30 Jan 2014, at 22:33, Tracy Snell >
> wrote:
>
> > Agreed a console for a bunch of Apache projects seems darn near perfect
> for Apache.
> >
> > On Jan 30, 2014, at 4:23 PM, Robert Davies 
> > >
> wrote:
> >
> >> I'm not a member of the hawtio community - but they were pretty clear
> they didn't feel the ASF was the best place to innovate and develop a UI.
> >
>
> Rob Davies
> 
> Red Hat, Inc
> http://hawt.io - #dontcha
> Twitter: rajdavies
> Blog: http://rajdavies.blogspot.com
> ActiveMQ in Action: http://www.manning.com/snyder/
>
>

Re: [VOTE] Move the ActiveMQ web-console to a sub-project.

[James Carman]

Zakeria, make sure you fill out and submit an Individual Contributor
License Agreement.  I'll make sure it gets filed quickly so you can
contribute.  Thanks for jumping in!  It's great to see enthusiastic folks

On Thursday, January 30, 2014, Zakeria Hassan 
wrote:

> Hi Daniel,
>
> Well put ! I really liked your response to the thread "on putting ActiveMQ
> web-console to a subproject..." . I originally voted +1 on this but after
> reading what you emailed, it changed my mind. I want to let you know I am
> ready to help to make the console better, just create some issues and feel
> free to assign them to me. I participated in the comments on this issue:
>
> https://issues.apache.org/jira/browse/AMQ-4994
>
> I am the creator of BZCareer.com  which is a job
> search engine start-up and wrote all the front-end and 97% of the backend
> code. I'm a contributor on many open source projects you can see the list
> on my github account. I'll be able to volunteer if need be after work. I
> got some great ideas on how we can improve the console and I'm really great
> at CSS, Javascript, HTML, Spring, Java, etc. Feel free to email me if there
> is anything needed of me by Apache Foundation. I'd like to be a committer
> on ActiveMQ.
>
> Thanks,
> Zak
> @Prospect1010
> http://www.github.com/zmhassan
>
>
>
> On Thu, Jan 30, 2014 at 1:05 PM, Daniel Kulp >
> wrote:
>
> >
> > > I want the best experience for the end user of ActiveMQ - and that's it
> > - simple.
> >
> > If that's your primary driver for the ActiveMQ project at Apache, we
> > already have a problem.   The primary goal of an Apache project should be
> > to build the community of developers working on and contributing to the
> > Apache project.   The goal needs to be to build a diverse and stable
> > community for the code.
> >
> > I had a long email thread with Roy Fielding (if you don't know who he is,
> > google him.  Short answer is one of the Apache founders, on the Board of
> > Directors forever, etc) about some of this back in December, mostly
> just
> > to get things completely straight in my own head.   Unfortunately, it's a
> > private conversation so I cannot paste directly from it, but basically
> the
> > thoughts come down to:
> >
> > 1) Apache is more than happy to point users that need a more "Enterprise
> > Experience" to the RedHat's, the Talend's, the Savoir Tech's, etc...
> Even
> > pointing at other communities such as hawt.io.  Apache recognizes that
> > for the projects to really succeed, people may need to make money off
> their
> > involvements.   That's NOT a bad thing.   If users need a better console
> > than the Apache community provides, fine, let some other
> community/company
> > provide that.   If they need 24x7 support, fine, let a company provide
> > that.   From what I gather, most, if not all, of the board members would
> > agree with that.  That said, Roy generally takes things even further
> > and really doesn't think Apache should even provide binaries at all, just
> > source, and those companies could provide the enterprise binaries.   That
> > opinion is not shared amongst all the board members.
> >
> > 2) HOWEVER, it's very important that the projects remain fair and
> > unbiased.   From the Apache projects standpoint, that basically means we
> > cannot promote particular third party companies/communities "add ons" or
> > services over any other.   This applies to the releases, it applies to
> the
> > website, etc   As a PMC, we can say "We provide a basic user
> experience,
> > if you need more, here is a list of options.   Try them out and see what
> > fits your needs."As a PMC, we cannot say "Just use hawt.io, it's the
> > only one worth looking at."The main reason is we WANT competitors and
> > such to get involved with the projects at Apache.   They should be able
> to
> > participate in the Apache stuff without having to worry about how they
> > compete with the non-Apache stuff.
> >
> > The reason #2 is important for this conversation is that if the PMC
> > decided to include hawt.io (providing the skinning/branding is fixed),
> it
> > would also HAVE to include any other third party console that met the
> same
> > requirements.   It must be fair and unbiased.  Thus, if I fork hawt.io,
> > remove the fuse stuff, add some Talend stuff, and publish that, ActiveMQ
> > would also have to ship that if asked.  If Johan took the current
> console,
> > forked it, cleaned it up a bit, and released as open source, we'd have to
> > include that as well.  Etc  I don't know about you, but in my
> opinion,
> > shipping 5 consoles would be confusing to people (and result in a
> gigantic
> > bloated download).
> >
> >
> > Dan
> >
> >
> >
> > On Jan 30, 2014, at 3:10 AM, Robert Davies  wrote:
> >
> > > Hi Johan,
> > >
> > > its great to know that you are earning so much money from Apache
> > ActiveMQ!
> > >
> > > I want the best experience for the end user of ActiveMQ - and that's i

Re: [VOTE] Move the ActiveMQ web-console to a sub-project.

[James Carman]

My vote isn't binding anyway.  You guys can (and apparently will) do
whatever you want, since you control the PMC.  I was adding my vote
"for the record."  You guys trying to hamstring the main distribution
of AMQ so that you can push your console is really uncool and goes
against the spirit of what the ASF is all about.

On Tue, Jan 28, 2014 at 10:00 AM, Claus Ibsen  wrote:
> On Tue, Jan 28, 2014 at 3:56 PM, James Carman
>  wrote:
>> -1, activemq needs to have a console bundled with it and it needs to
>> be part of the default distribution.
>>
>
> This is not a valid reason for -1. The vote has NOTHING to do about
> the distribution.
> Only about creating a new sub project for the web console project to live.
>
>
>
>> On Tue, Jan 28, 2014 at 9:18 AM, Hiram Chirino  
>> wrote:
>>> Since there seems to be general agreement that the web-console should
>>> be moved to a sub-project, lets put it to a vote and make it official.
>>>
>>> [ ] +1 Create the activemq-web-console sub-project with the associated
>>> git, wiki, and jira spaces.
>>> [ ] -1 Veto the making it a sub-project
>>>
>>> --
>>> Hiram Chirino
>>> Engineering | Red Hat, Inc.
>>> hchir...@redhat.com | fusesource.com | redhat.com
>>> skype: hiramchirino | twitter: @hiramchirino
>>> blog: Hiram Chirino's Bit Mojo
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> Make your Camel applications look hawt, try: http://hawt.io

Re: [VOTE] Move the ActiveMQ web-console to a sub-project.

[James Carman]

-1, activemq needs to have a console bundled with it and it needs to
be part of the default distribution.

On Tue, Jan 28, 2014 at 9:18 AM, Hiram Chirino  wrote:
> Since there seems to be general agreement that the web-console should
> be moved to a sub-project, lets put it to a vote and make it official.
>
> [ ] +1 Create the activemq-web-console sub-project with the associated
> git, wiki, and jira spaces.
> [ ] -1 Veto the making it a sub-project
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
> blog: Hiram Chirino's Bit Mojo

Re: Is skinning hawt.io enough to allow it be be packaged in ActiveMQ?

[James Carman]

The user doesn't directly interact with Spring when they use AMQ.
It's not the "face" of AMQ.

On Mon, Jan 27, 2014 at 10:23 AM, Christian Posta
 wrote:
> What I'm supporting is the original comparison of the process needed
> to resolve issues with software developed by external communities. If
> it's not to the PMC's liking as HIram (and others) have mentioned,
> then we take steps to do something about it.
>
> We didn't write our own DI framework. If there were bugs in it then we
> would report them to Spring's community and work with their devs to
> fix it.
>
> If we built on top of Spring, then that's cool too. We are devs and
> can use other projects to leverage when it makes sense.
>
>
> On Mon, Jan 27, 2014 at 7:43 AM, Johan Edstrom  wrote:
>> No, we wrote the NS handling and supporting classes to tie into those DI
>> frameworks, CXF, Camel, AMQ and so on has/have had support for
>> Blueprint, Spring, Guice, CDI and so on in various forms.
>>
>> Those weren't a "skinned" spring namespacehandler for camel residing
>> in a Spring repo with spring access so you can kinda cut that type of 
>> argument.
>>
>> What you are comparing is "supporting" libraries, as stated earlier, CXF for
>> example was heavily built on Spring, now not so heavily as it lead to deps
>> on spring that became incompatible with other 3rd party frameworks.
>>
>>
>> On Jan 27, 2014, at 9:37 AM, Christian Posta  
>> wrote:
>>
>>> I guess the argument to be made is that the web console isn't a 3rd
>>> party library, it's a more involved part of the user experience. Which
>>> is true. But so is the Spring Framework. We didn't write our own DI
>>> framework for that.
>>>
>>> The point is the "process" to resolving any issues would be the same
>>> process we follow for any other outside community software we use.
>>>
 If we the PMC does not like some detail of
 hawtio we just need to open issues to address them and once it's to
 the PMC's liking we can then package it.
>>>
>>>
>>> And this is exactly the way we've been doing it with other external
>>> community software.
>>>
>>>
>>>
>>> On Wed, Jan 22, 2014 at 3:44 PM, Hiram Chirino  
>>> wrote:
 Starting up a new thread to avoid hijacking the original POLL thread.

 On Wed, Jan 22, 2014 at 5:29 PM, Hadrian Zbarcea  
 wrote:
> Without the hawt.io community donating the relevant ActiveMQ portions to 
> the
> ASF we will not be able to get a consensus around proposal #3. Thus, that
> needs to be taken off the table.

 I think that's a faulty assumption that needs to get discussed and 
 addressed.

 Any hawtio UI that we package in the ActiveMQ will be reviewed by the
 PMC.  Like any 3rd party library that we ship, it has to have an
 approved license and it's functionality has to be tested and verified
 by the ActiveMQ project.  If we the PMC does not like some detail of
 hawtio we just need to open issues to address them and once it's to
 the PMC's liking we can then package it.  This is no different from
 any other 3rd party lib we use so why are we treating it differently?

 --
 Hiram Chirino
>>>
>>>
>>>
>>> --
>>> Christian Posta
>>> http://www.christianposta.com/blog
>>> twitter: @christianposta
>>
>
>
>
> --
> Christian Posta
> http://www.christianposta.com/blog
> twitter: @christianposta

Re: [DISCUSS] Create an ActiveMQ Web Console sub-project

[James Carman]

I think the console should be part of the main distribution.  They should
be released together.  Release early, release often.

On Saturday, January 25, 2014, Robert Davies  wrote:

>
> The recent poll [1] and discussions [2] around what to do with the current
> ActiveMQ web console demonstrated there’s a mix bag of views. There are
> developers who passionately believe that the current Web Console is a large
> technical debt on the project, hasn’t been actively developed for years and
> is a security risk - whilst others believe it benefits users immensely to
> have such a web console available.
>
> What I would like to propose is that the Web Console is moved to a sub
> project of ActiveMQ - where those interested in maintaining and developing
> it can work independently of the ActiveMQ broker release. Ideally there
> would be collaboration - so that the Web console could be released in the
> same time frame as every new minor and major release of the broker.
> However, having it as a sub project will also allow for it to be released
> independently - so that if folks want to iterate releases of the web
> console whilst they improve it or to fix issues as they arise they can. It
> also has the benefit of freeing up ActiveMQ developers who want to
> concentrate on the core broker functionality.
>
> This is a compromise, but I believe its the best way forward. What do you
> guys think ?
>
> thanks,
>
> Rob
>
> [1] https://www.mail-archive.com/dev@activemq.apache.org/msg37711.html
> [2]
> http://activemq.2283324.n4.nabble.com/DISCUSS-Remove-the-old-ActiveMQ-Console-td4675925.html
>
> Rob Davies
> 
> Red Hat, Inc
> http://hawt.io - #dontcha
> Twitter: rajdavies
> Blog: http://rajdavies.blogspot.com
> ActiveMQ in Action: http://www.manning.com/snyder/
>
>

Re: [POLL] - Remove the old ActiveMQ Console

[James Carman]

This whole "then we shouldn't use any 3rd party libraries" argument is
getting old, Hiram.  You know there's a difference between using a
library behind the scenes and the entire web console itself that the
users interact with directly. Come on, man.  Give it up.


On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino  wrote:
> On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp  wrote:
>> That’s completely BS. If I download “activemq-###.tar.gz” from 
>> ActiveMQ’s website and I run the startup scripts and such that are 
>> documented in that bundle and I find a problem that directly pertains to 
>> ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an 
>> issue.  I also completely expect to be able to do a “git clone” of 
>> ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
>>
>
> If this is true then we should not be using ANY 3rd party libs at all.
>  Most users cannot tell where the line is between 3rd party libs and
> ActiveMQ's source.  The ActiveMQ project is ultimately responsible for
> all functionality shipped (if its 3rd party or not).  If it's a 3rd
> party defect then the ActiveMQ project needs to either work around the
> defect, patch the defect in the 3rd party library or work with the 3rd
> party to fix the defect.  All 3 approaches are possible with hawtio
> too.
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> hchir...@redhat.com | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino

Re: [POLL] - Remove the old ActiveMQ Console

[James Carman]

So why didn't you guys work on this console "in-house"?

On Wednesday, January 22, 2014, Dejan Bosanac  wrote:

> In my opinion, this "control issue" is totally overblown. First of all,
> we're not some newcomers trying to put a malware into the project. We're
> people that are developing this project for the last 5-7 years and are
> trying to position it better for the future, by replacing its most obsolete
> component.
>
> But most importantly, you put it as if Apache releases are totally
> uncontrollable and anybody can sneak into it anything they want. But you
> know well that's not the case, as we use proper releases of other projects
> and all "skinning" is done here. Additionally, every release is voted. So
> there's no chance of any misuse at the release time and once it's released
> it can't be changed. What happens when a project we use loses its track? We
> deal with that at that point (find a replacement, fork and continue
> developing, etc.) and it's the same for Spring, Jetty, HawtIO or any other
> part. So the "risk of losing control" is not valid neither from technical
> nor project image standpoint.
>
> Regards
> --
> Dejan Bosanac
> --
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> dbosa...@redhat.com 
> Twitter: @dejanb
> Blog: http://sensatic.net
> ActiveMQ in Action: http://www.manning.com/snyder/
>
>
> On Tue, Jan 21, 2014 at 11:16 PM, Gary Tully  wrote:
>
> > inline
> >
> > On 21 January 2014 17:36, Daniel Kulp  wrote:
> > >
> > > On Jan 21, 2014, at 12:07 PM, Gary Tully  wrote:
> > >
> > >> On 21 January 2014 16:30, Daniel Kulp  wrote:
> > >>>
> > >>> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ
> > project.   If someone is using ActiveMQ and wants to contribute changes
> to
> > how the console looks or displays items or such, they should be making
> > contributions to ActiveMQ, not some external community (open source,
> free,
> > or otherwise).   The hawt.io “framework” of libraries and such can
> remain
> > outside, but the ActiveMQ specific portions needs to be part of this
> > community.   If it’s going to be the visible frontend of this project, we
> > need to make sure it drives the developer willing to contribute
> > enhancements into ActiveMQ.
> > >>>
> > >> This is putting the cart before the horse!
> > >> If we need some changes and if we can't make contributions to hawtio
> > >> (patches, issues etc) we can deal with that by building our own plugin
> > >> or throwing it out or whatever. But why do that now?
> > >
> > > You are basically asking THIS developer community to completely give up
> > control over how ActiveMQ is presented to the users to a different
> > community.   I personally cannot think of anything much worse for this
> > community than that.   That seems like a horrible idea from an Apache
> > community standpoint.
> > >
> > That is not what I am asking.
> > How can choosing to adopt a better solution to an open problem be
> > giving up control? We can always change our minds and throw it out if
> > it does not serve our needs. The PMC will always be in control of what
> > is released.
> >
> >
> > > The goals of the Apache communities needs to be to make sure developers
> > are driven into the Apache communities, not another community.
> > Any goal that hopes to drive developers is a non starter. Developers
> > choose, they are not driven. I am suggesting we make a sensible choice
> > that helps our community by giving it a better web ui. hawtio wants to
> > have the best activemq web console, we want to ship the best activemq
> > console. The stars are aligned. If the alignment falters we address
> > that.
> >
> > >
> > >> We don't have to own everything that makes activemq better and that
> > >> makes our users experience better, we just have to ensure that it is
> > >> better.
> > >
> > > Making the user experience better is certainly an important aspect of
> > the Apache communities, but the primary focus should be on making sure
> the
> > developer community is healthy and we aren’t driving potential developers
> > elsewhere.   That NEEDS to be the most important thing at this point,
> > especially with the current active makeup of this community.
> > >
> > > In particular, since Apache is a 503b charitable non-profit foundation,
> > we cannot be used to promote other communities, particularly those
> “owned”
> > by a for-profit entity.  (open source or otherwise, that’s somewhat
> > irrelevant)
> > >
> > > Anyway, as far as *I’m* concerned (but I’m not a member of this PMC,
> > just an interested party), if the hawt.io community is unwilling or
> > unable to support the ActiveMQ community to allow ActiveMQ to maintain
> > control over it’s user experience, then there is no-point engaging with
> > them.  It is a waste of time.
> > >
> > > That said, if hawt.io community want to create a full distribution of
> > ActiveMQ + hawt.io to make life easier for users, they certainly are
> > welcome to do so 

Re: [POLL] - Remove the old ActiveMQ Console

[James Carman]

On Tue, Jan 21, 2014 at 12:11 PM, Gary Tully  wrote:
> hadrian, it is the activemq devs that want to include hawtio, not the
> other way around.
> lets concentrate on what we (activemq devs/pmc) can do to make the web
> experience better.
> The only technical issue with hawtio in 5.9 is the branding. I say we
> just fix that.
>

You say that as if they are not one and the same.

Re: [POLL] - Remove the old ActiveMQ Console

[James Carman]

I said console in my statement, not web console.  You need a way to manage
stuff.

On Friday, January 17, 2014, Christian Posta 
wrote:

> well, karaf does ship with a console, the command-line shell.
>
> but i think we're talking about the web console.
>
> in 2.3.3, i don't see a webconsole shipped in the distro:
>
> http://pastebin.com/zepcUHMX
>
> in 3.0.0 i don't either:
>
> http://pastebin.com/cfV3yG0Z
>
>
> On Fri, Jan 17, 2014 at 3:19 PM, Hadrian Zbarcea 
> wrote:
> > Rob, that's not quite correct. Karaf *ships with a console*, ActiveMQ
> also
> > ships with a console. The issue we are discussing now is the distro
> content,
> > right?
> >
> > Hadrian
> >
> >
> >
> >
> > On 01/17/2014 05:07 PM, Robert Davies wrote:
> >>
> >>
> >> On 17 Jan 2014, at 21:53, James Carman 
> wrote:
> >>
> >>> Karaf ships with a console
> >>
> >>
> >> Yes - its not installed by default - which is equivalent to option 1.
> >>
> >>>
> >>> On Friday, January 17, 2014, Robert Davies 
> wrote:
> >>>
> >>>>
> >>>> On 17 Jan 2014, at 16:33, James Carman
> >>>> >
> >>>> wrote:
> >>>>
> >>>>> Agreed.  My point was that we shouldn't just abandon the console that
> >>>>> comes with ActiveMQ.  A messaging "product" should have its own
> >>>>> console, if it is to be taken seriously by potential "customers”.
> >>>>
> >>>>
> >>>> I don’t buy in to that at all - having to hit refresh on the web
> browser
> >>>> in 2014 to see if the message count has increased  just doesn’t cut
> it -
> >>>> and it hasn’t for a long time.
> >>>> As has been said before, the argument about shipping a console to
> >>>> compete
> >>>> can be used for a container too - but Karaf doesn’t, it makes it
> >>>> optional -
> >>>> and that’s a valid point of view that’s worth replicating.
> >>>>
> >>>>> Providing an even playing field for consoles shouldn't be ActiveMQ's
> >>>>> primary concern.  ActiveMQ should concern itself with providing a
> >>>>> best-of-breed messaging system, which should include a management
> >>>>> console.
> >>>>
> >>>>
> >>>> Or point people to a host of alternatives that would enhance the user
> >>>> experience.  What I really don’t understand is that the people who are
> >>>> active committers, and actually fix the security issues as they come
> are
> >>>> all saying get rid of the console and our views are being ignored.
>  Its
> >>>> not
> >>>> our core competence, nor should it have to be - we are writing a
> message
> >>>> broker. If you feel strongly about it you are of course more than
> >>>> welcome
> >>>> to help write a new console that can be incorporated at a later date.
> >>>>
> >>>>>
> >>>>> On Fri, Jan 17, 2014 at 11:27 AM, Hadrian Zbarcea
> >>>>> >
> >>>>
> >>>> wrote:
> >>>>>>
> >>>>>> James,
> >>>>>>
> >>>>>> 5. Is just business as usual, why should it be part of the poll?
> Users
> >>>>
> >>>> raise
> >>>>>>
> >>>>>> an issue, it gets fixed.
> >>>>>>
> >>>>>> My $0.02,
> >>>>>> Hadrian
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 01/17/2014 11:25 AM, James Carman wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> 1. -1
> >>>>>>> 2. -1
> >>>>>>> 3. -1
> >>>>>>> 4. +1
> >>>>>>> 5. Resurrect the "old" console and bring it up-to-date, fixing any
> >>>>>>> outstanding bugs - +1
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies
> >>>>>>> 
> --
> Christian Posta
> http://www.christianposta.com/blog
> twitter: @christianposta
>

Re: [POLL] - Remove the old ActiveMQ Console

[James Carman]

It has the tui on by default

On Friday, January 17, 2014, Robert Davies  wrote:

>
> On 17 Jan 2014, at 21:53, James Carman 
> >
> wrote:
>
> > Karaf ships with a console
>
> Yes - its not installed by default - which is equivalent to option 1.
>
> >
> > On Friday, January 17, 2014, Robert Davies 
> > >
> wrote:
> >
> >>
> >> On 17 Jan 2014, at 16:33, James Carman 
> >> 
> >
> >> wrote:
> >>
> >>> Agreed.  My point was that we shouldn't just abandon the console that
> >>> comes with ActiveMQ.  A messaging "product" should have its own
> >>> console, if it is to be taken seriously by potential "customers”.
> >>
> >> I don’t buy in to that at all - having to hit refresh on the web browser
> >> in 2014 to see if the message count has increased  just doesn’t cut it -
> >> and it hasn’t for a long time.
> >> As has been said before, the argument about shipping a console to
> compete
> >> can be used for a container too - but Karaf doesn’t, it makes it
> optional -
> >> and that’s a valid point of view that’s worth replicating.
> >>
> >>> Providing an even playing field for consoles shouldn't be ActiveMQ's
> >>> primary concern.  ActiveMQ should concern itself with providing a
> >>> best-of-breed messaging system, which should include a management
> >>> console.
> >>
> >> Or point people to a host of alternatives that would enhance the user
> >> experience.  What I really don’t understand is that the people who are
> >> active committers, and actually fix the security issues as they come are
> >> all saying get rid of the console and our views are being ignored.  Its
> not
> >> our core competence, nor should it have to be - we are writing a message
> >> broker. If you feel strongly about it you are of course more than
> welcome
> >> to help write a new console that can be incorporated at a later date.
> >>
> >>>
> >>> On Fri, Jan 17, 2014 at 11:27 AM, Hadrian Zbarcea 
> >>> 
> >
> >> wrote:
> >>>> James,
> >>>>
> >>>> 5. Is just business as usual, why should it be part of the poll? Users
> >> raise
> >>>> an issue, it gets fixed.
> >>>>
> >>>> My $0.02,
> >>>> Hadrian
> >>>>
> >>>>
> >>>>
> >>>> On 01/17/2014 11:25 AM, James Carman wrote:
> >>>>>
> >>>>> 1. -1
> >>>>> 2. -1
> >>>>> 3. -1
> >>>>> 4. +1
> >>>>> 5. Resurrect the "old" console and bring it up-to-date, fixing any
> >>>>> outstanding bugs - +1
> >>>>>
> >>>>>
> >>>>> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies 
> >>>>> 
> 
> >>>
> >>>>> wrote:
> >>>>>>
> >>>>>> I want to take a straw poll to see where everyone stands, because
> >> opinion
> >>>>>> has varied, mine included. Straw polls can be a useful tool to move
> >> towards
> >>>>>> consensus. This isn’t a formal vote, but to reduce the noise, can we
> >> keep it
> >>>>>> to binding votes only ?
> >>>>>>
> >>>>>>
> >>>>>> 1. Have one distribution with no default console, but make it easy
> to
> >>>>>> deploy a console on demand (the original console - or 3rd party
> ones).
> >>>>>> 2. Have two separate distributions, one with no console  - and have
> a
> >>>>>> second distribution with the original console
> >>>>>> 3. One distribution, with hawtio as the console -  ActiveMQ branded.
> >>>>>> 4. One distribution, but uses the original ActiveMQ console only.
> >>>>>>
> >>>>>> Here’s my vote:
> >>>>>>
> >>>>>> [1]. +1
> >>>>>> [2]  0
> >>>>>> [3] 0
> >>>>>> [4] -1
> >>>>>>
> >>>>>> thanks,
> >>>>>>
> >>>>>> Rob
> >>>>>>
> >>>>
> >>
> >> Rob Davies
> >> 
> >> Red Hat, Inc
> >> http://hawt.io - #dontcha
> >> Twitter: rajdavies
> >> Blog: http://rajdavies.blogspot.com
> >> ActiveMQ in Action: http://www.manning.com/snyder/
> >>
> >>
>
> Rob Davies
> 
> Red Hat, Inc
> http://hawt.io - #dontcha
> Twitter: rajdavies
> Blog: http://rajdavies.blogspot.com
> ActiveMQ in Action: http://www.manning.com/snyder/
>
>

Re: [POLL] - Remove the old ActiveMQ Console

[James Carman]

Karaf ships with a console

On Friday, January 17, 2014, Robert Davies  wrote:

>
> On 17 Jan 2014, at 16:33, James Carman 
> >
> wrote:
>
> > Agreed.  My point was that we shouldn't just abandon the console that
> > comes with ActiveMQ.  A messaging "product" should have its own
> > console, if it is to be taken seriously by potential "customers”.
>
> I don’t buy in to that at all - having to hit refresh on the web browser
> in 2014 to see if the message count has increased  just doesn’t cut it -
> and it hasn’t for a long time.
> As has been said before, the argument about shipping a console to compete
> can be used for a container too - but Karaf doesn’t, it makes it optional -
> and that’s a valid point of view that’s worth replicating.
>
> > Providing an even playing field for consoles shouldn't be ActiveMQ's
> > primary concern.  ActiveMQ should concern itself with providing a
> > best-of-breed messaging system, which should include a management
> > console.
>
> Or point people to a host of alternatives that would enhance the user
> experience.  What I really don’t understand is that the people who are
> active committers, and actually fix the security issues as they come are
> all saying get rid of the console and our views are being ignored.  Its not
> our core competence, nor should it have to be - we are writing a message
> broker. If you feel strongly about it you are of course more than welcome
> to help write a new console that can be incorporated at a later date.
>
> >
> > On Fri, Jan 17, 2014 at 11:27 AM, Hadrian Zbarcea 
> > >
> wrote:
> >> James,
> >>
> >> 5. Is just business as usual, why should it be part of the poll? Users
> raise
> >> an issue, it gets fixed.
> >>
> >> My $0.02,
> >> Hadrian
> >>
> >>
> >>
> >> On 01/17/2014 11:25 AM, James Carman wrote:
> >>>
> >>> 1. -1
> >>> 2. -1
> >>> 3. -1
> >>> 4. +1
> >>> 5. Resurrect the "old" console and bring it up-to-date, fixing any
> >>> outstanding bugs - +1
> >>>
> >>>
> >>> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies 
> >>> 
> >
> >>> wrote:
> >>>>
> >>>> I want to take a straw poll to see where everyone stands, because
> opinion
> >>>> has varied, mine included. Straw polls can be a useful tool to move
> towards
> >>>> consensus. This isn’t a formal vote, but to reduce the noise, can we
> keep it
> >>>> to binding votes only ?
> >>>>
> >>>>
> >>>> 1. Have one distribution with no default console, but make it easy to
> >>>> deploy a console on demand (the original console - or 3rd party ones).
> >>>> 2. Have two separate distributions, one with no console  - and have a
> >>>> second distribution with the original console
> >>>> 3. One distribution, with hawtio as the console -  ActiveMQ branded.
> >>>> 4. One distribution, but uses the original ActiveMQ console only.
> >>>>
> >>>> Here’s my vote:
> >>>>
> >>>> [1]. +1
> >>>> [2]  0
> >>>> [3] 0
> >>>> [4] -1
> >>>>
> >>>> thanks,
> >>>>
> >>>> Rob
> >>>>
> >>
>
> Rob Davies
> 
> Red Hat, Inc
> http://hawt.io - #dontcha
> Twitter: rajdavies
> Blog: http://rajdavies.blogspot.com
> ActiveMQ in Action: http://www.manning.com/snyder/
>
>

Re: [POLL] - Remove the old ActiveMQ Console

[James Carman]

Agreed.  My point was that we shouldn't just abandon the console that
comes with ActiveMQ.  A messaging "product" should have its own
console, if it is to be taken seriously by potential "customers".
Providing an even playing field for consoles shouldn't be ActiveMQ's
primary concern.  ActiveMQ should concern itself with providing a
best-of-breed messaging system, which should include a management
console.

On Fri, Jan 17, 2014 at 11:27 AM, Hadrian Zbarcea  wrote:
> James,
>
> 5. Is just business as usual, why should it be part of the poll? Users raise
> an issue, it gets fixed.
>
> My $0.02,
> Hadrian
>
>
>
> On 01/17/2014 11:25 AM, James Carman wrote:
>>
>> 1. -1
>> 2. -1
>> 3. -1
>> 4. +1
>> 5. Resurrect the "old" console and bring it up-to-date, fixing any
>> outstanding bugs - +1
>>
>>
>> On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies 
>> wrote:
>>>
>>> I want to take a straw poll to see where everyone stands, because opinion
>>> has varied, mine included. Straw polls can be a useful tool to move towards
>>> consensus. This isn’t a formal vote, but to reduce the noise, can we keep it
>>> to binding votes only ?
>>>
>>>
>>> 1. Have one distribution with no default console, but make it easy to
>>> deploy a console on demand (the original console - or 3rd party ones).
>>> 2. Have two separate distributions, one with no console  - and have a
>>> second distribution with the original console
>>> 3. One distribution, with hawtio as the console -  ActiveMQ branded.
>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>
>>> Here’s my vote:
>>>
>>> [1]. +1
>>> [2]  0
>>> [3] 0
>>> [4] -1
>>>
>>> thanks,
>>>
>>> Rob
>>>
>

Re: [POLL] - Remove the old ActiveMQ Console

[James Carman]

1. -1
2. -1
3. -1
4. +1
5. Resurrect the "old" console and bring it up-to-date, fixing any
outstanding bugs - +1


On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies  wrote:
> I want to take a straw poll to see where everyone stands, because opinion has 
> varied, mine included. Straw polls can be a useful tool to move towards 
> consensus. This isn’t a formal vote, but to reduce the noise, can we keep it 
> to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to deploy 
> a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console  - and have a second 
> distribution with the original console
> 3. One distribution, with hawtio as the console -  ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2]  0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>

Re: [POLL] - Remove the old ActiveMQ Console

[James Carman]

Can we get a rundown of the issues with the current console?  I don't
really see a lot of traffic on here complaining about it.  Nobody has
really touched it in a long time, right?  So, why not get some folks
who are interested in it to work on it?  I'd be willing to help with
it.


On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies  wrote:
> I want to take a straw poll to see where everyone stands, because opinion has 
> varied, mine included. Straw polls can be a useful tool to move towards 
> consensus. This isn’t a formal vote, but to reduce the noise, can we keep it 
> to binding votes only ?
>
>
> 1. Have one distribution with no default console, but make it easy to deploy 
> a console on demand (the original console - or 3rd party ones).
> 2. Have two separate distributions, one with no console  - and have a second 
> distribution with the original console
> 3. One distribution, with hawtio as the console -  ActiveMQ branded.
> 4. One distribution, but uses the original ActiveMQ console only.
>
> Here’s my vote:
>
> [1]. +1
> [2]  0
> [3] 0
> [4] -1
>
> thanks,
>
> Rob
>

Re: [DISCUSS] Remove the old ActiveMQ Console

[James Carman]

Of course, by shipping with no console, stopping development of the
current one, and with hawt.io already having a working console, I
wonder where we are going to be pointing folks?

On Tue, Jan 7, 2014 at 2:48 PM, Jim Gomes  wrote:
> +1 the ideas that Claus presented below.  I like the idea of a simple
> drop-in install and a level playing field for replacement consoles.  By
> having a default "headless" install, the security of a production
> deployment goes way up.
>
>
> On Mon, Jan 6, 2014 at 12:06 AM, Claus Ibsen  wrote:
>
>> Hi
>>
>> I think the old web console should be moved into a sub-project of ActiveMQ.
>> Other ASF projects like Felix [1], Karaf [2], etc does this with their
>> web-consoles.
>>
>> That may also make it easier for people to contribute to the
>> web-console as a sub-project if there codebase is smaller, and not
>> contains the entire ActiveMQ source code. That may spark a little more
>> life into the old web-console so people can help maintain it.
>>
>> For the standalone ActiveMQ distribution, then installing the old web
>> console should be an easy step, such as unzipping a .zip file, or
>> copying a .war / .jar or something to a directory, and allowing to
>> editing a configuration file to configure the console (port / context
>> path / or other configurations). Then other 3rd party consoles could
>> have the *same* installation procedure, so there is even
>> playing-field.
>>
>> For the embedded ActiveMQ distribution for SMX/Karaf users, its
>> already easy to install the console, as its just like any other
>> installation using a feature. This is the same for other 3rd party
>> consoles, and thus there is already an even playing field.
>>
>>
>>
>>
>> [1] -
>> http://felix.apache.org/documentation/subprojects/apache-felix-web-console.html
>> [2] - http://karaf.apache.org/index/subprojects/webconsole.html
>>
>>
>> On Thu, Jan 2, 2014 at 10:59 AM, Robert Davies 
>> wrote:
>> > The old/original console is no longer fit for purpose, it is hard to
>> maintain, the source of a lot of security issues [1] over the last few
>> years.
>> >
>> > There is another thread about using hawtio as the console going forward,
>> and without going into all the gory details it is probably likely that
>> there may be no web console shipped at all in future releases of ActiveMQ.
>> The JMX naming hierarchy was improved for ActiveMQ 5.8, such that its easy
>> to view the running status of an ActiveMQ broker from 3rd party tools such
>> as jconsole, visualvm or hawtio. Regardless of the outcome of the other
>> discussion [2] - It doesn’t help the ActiveMQ project to try and maintain a
>> static web console any more.
>> >
>> > I propose we remove the old web console from the ActiveMQ 5.10 release -
>> thoughts ?
>> >
>> >
>> >
>> > [1]
>> https://issues.apache.org/jira/browse/AMQ-2714?jql=project%20%3D%20AMQ%20AND%20text%20~%20%22XSS%22
>> > [2]
>> http://activemq.2283324.n4.nabble.com/Default-Web-Console-td4675705.html
>> >
>> > Rob Davies
>> > 
>> > Red Hat, Inc
>> > http://hawt.io - #dontcha
>> > Twitter: rajdavies
>> > Blog: http://rajdavies.blogspot.com
>> > ActiveMQ in Action: http://www.manning.com/snyder/
>> >
>>
>>
>>
>> --
>> Claus Ibsen
>> -
>> Red Hat, Inc.
>> Email: cib...@redhat.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>> Make your Camel applications look hawt, try: http://hawt.io
>>

[jira] [Commented] (AMQ-4825) ConnectionFactory and ActiveMQCamelComponent should default to the right port if on OpenShift

[James Carman (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805550#comment-13805550
 ] 

James Carman commented on AMQ-4825:
---

Why should there be OpenShift/Fuse-specific logic in the ActiveMQ code?  Why 
not use AMQ_PORT environment variable?

> ConnectionFactory and ActiveMQCamelComponent should default to the right port 
> if on OpenShift
> -
>
> Key: AMQ-4825
> URL: https://issues.apache.org/jira/browse/AMQ-4825
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: james strachan
>
> our default is localhost:61616 out of the box. Though this doesn't work on 
> OpenShift - where we default to using 31313 so its in the allowable range.
> When Java is running in the openshift cartridge we can easily tell using an 
> environment variable; so it'd be nice if we automatically checked for that 
> and defaulted to it out of the box. Then a vanilla ActiveMQ connection 
> factory or camel component would automatically just use the right port on 
> openshift. (Then if we're using, say, a local broker or gateway, it'd just 
> work).
> Here's where the port/env var gets defined:
> https://github.com/jboss-fuse/fuse-openshift-cartridge/blob/master/metadata/manifest.yml#L94
> So we'd just need to check for the env value of OPENSHIFT_FUSE_AMQ_PORT and 
> use that if its defined otherwise default to 61616



--
This message was sent by Atlassian JIRA
(v6.1#6144)