Re: [DISCUSS] Artemis 2.0.0 target features

[Jean-Baptiste Onofré]

Agree with Christian. It's a bit unfortunate.

Regards
JB⁣​

On Dec 8, 2016, 07:53, at 07:53, Christian Schneider  
wrote:
>As artemis is an open source project I would not use a marketing like
>reason for a new major version (like a certain feature set).
>Instead I would use a major version to remove deprecated interfaces. So
>basically to remove stuff in a way that might be incompatible to older
>clients.
>For pure feature additions a minor version should be technically good
>enough.
>
>Christian
>
>2016-12-07 22:29 GMT+01:00 Matt Pavlovich :
>
>> *** Re-sending w/ [DISCUSS] subject tag
>>
>> Kicking off a discussion on what folks would like to see in 2.0.0
>release
>> for Artemis. My thought is that we should target ActiveMQ 5.x feature
>> parity in an effort to solidify Artemis in the product sense. I will
>detail
>> out specifics from my previous note on 5.x-Artemis feature gaps.
>>
>> Thoughts?
>>
>>
>
>
>-- 
>-- 
>Christian Schneider
>http://www.liquid-reality.de
>
>
>Open Source Architect
>http://www.talend.com
>

Re: [DISCUSS] Artemis 2.0.0 target features

[Christian Schneider]

As artemis is an open source project I would not use a marketing like
reason for a new major version (like a certain feature set).
Instead I would use a major version to remove deprecated interfaces. So
basically to remove stuff in a way that might be incompatible to older
clients.
For pure feature additions a minor version should be technically good
enough.

Christian

2016-12-07 22:29 GMT+01:00 Matt Pavlovich :

> *** Re-sending w/ [DISCUSS] subject tag
>
> Kicking off a discussion on what folks would like to see in 2.0.0 release
> for Artemis. My thought is that we should target ActiveMQ 5.x feature
> parity in an effort to solidify Artemis in the product sense. I will detail
> out specifics from my previous note on 5.x-Artemis feature gaps.
>
> Thoughts?
>
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Open Source Architect
http://www.talend.com

[DISCUSS] Questions: testing compatibility test with older version on a POJO

[Clebert Suconic]

I need to write a test where the binary output would need to be
checked against an older version of a class.


The test would be something like:


{
   MessageImpl currentMessage = new MessageImpl();
   setProperties(currentMessages); // some method that will generate
data on message

   // something that will encode the message
   currentMessage.encode(someBuffer);

   osgiMagic(someBuffer);
}

I'm looking for some OSGI Magic where I can then make comparissons
with MessageImpl from 1.5.0.


Is there any manageable way of doing this? Manageable = not so bad
that only me would understand the code.


I don't even know what to look for on google, hence the question here.



thanks for any help is appreciated!


Clebert

[GitHub] activemq-artemis issue #905: added unit test for setting the user and passwo...

[pgfox]

Github user pgfox commented on the issue:

https://github.com/apache/activemq-artemis/pull/905
  
@jbertram, 

as you suggested, enabled security on the test broker and add a role to 
ensure credentials passed with connection. Also enabled the default user to 
ensure existing tests passed without modification - I was trying to keep a 
small footprint. 

Thanks
Pat



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Artemis 2.0.0 target features

[Timothy Bish]

On 12/07/2016 04:29 PM, Matt Pavlovich wrote:

*** Re-sending w/ [DISCUSS] subject tag

Kicking off a discussion on what folks would like to see in 2.0.0 
release for Artemis. My thought is that we should target ActiveMQ 5.x 
feature parity in an effort to solidify Artemis in the product sense. 
I will detail out specifics from my previous note on 5.x-Artemis 
feature gaps.


Thoughts?




So you're looking to get 2.0 out by 2020 then?  ;)

--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

[DISCUSS] Artemis 2.0.0 target features

[Matt Pavlovich]

*** Re-sending w/ [DISCUSS] subject tag

Kicking off a discussion on what folks would like to see in 2.0.0 
release for Artemis. My thought is that we should target ActiveMQ 5.x 
feature parity in an effort to solidify Artemis in the product sense. I 
will detail out specifics from my previous note on 5.x-Artemis feature 
gaps.


Thoughts?

Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Matt Pavlovich]

Justin-

Agreed all around. I'm suggesting a separate thread on feature set for 
2.0 to allow around of input for those that don't have their eyes on 
this addressing thread. I wasn't sure if it had been discussed or not.


I'll kick off a new thread.

-Matt


On 12/7/16 3:31 PM, Justin Bertram wrote:

Essential feature parity with 5.x (where it makes sense) has been a goal all along, but I 
think waiting until such parity exists before the next major release means the community 
will be waiting quite a bit longer than they already have.  Meanwhile, new functionality 
that could benefit the community will remain unavailable.  In any event, "feature 
parity" is a bit vague.  If there is something specific with regards to 5.x parity 
that you're looking for then I think you should make that explicit so it can be evaluated.

I'm in favor of merging the addressing changes onto master, hardening things up 
a bit, and then releasing.


Justin

- Original Message -
From: "Matt Pavlovich" 
To: dev@activemq.apache.org
Sent: Wednesday, December 7, 2016 2:04:13 PM
Subject: Re: [DISCUSS] Artemis addressing improvements, JMS component removal 
and potential 2.0.0

IMHO, I think it would be good to kick up a thread on what it means to
be 2.0. It sounds like the addressing changes definitely warrant it on
its own, but I'm thinking having ActiveMQ 5.x feature parity would be a
good goal for the 2.0 release.  My $0.02

On 12/7/16 2:56 PM, Clebert Suconic wrote:

+1000


It needs one final cleanup before it can be done though.. these commit
messages need meaninful descriptions.

if Justin or Martyn could come up with that since they did most of the
work on the branch.

This will really require bumping the release to 2.0.0 (there's a
2.0.snapshot commit on it already).  I would merge this into master,
and fork the current master as 1.x.




On Wed, Dec 7, 2016 at 1:52 PM, Timothy Bish  wrote:

This would be a good time to move to master, would allow other to more
easily get onboard


On 12/07/2016 01:25 PM, Clebert Suconic wrote:

I have rebased ARTEMIS-780 in top of master. There was a lot of
conflicts...

I have aggregated/squashed most of the commits by chronological order
almost. So if Martyn had 10 commits in series I had squashed all of
them, since they were small comments anyways. The good thing about
this is that nobody would lose authorship of these commits.

We will need to come up with more meaningful messages for these
commits before we can merge into master. But this is getting into a
very good shape. I'm impressed by the amount of work I see done on
this branch. Very well done guys! I mean it!

Also, I have saved the old branch before I pushed -f into my fork as
old-ARTEMIS-780 in case I broke anything on the process. Please check
everything and let me know if I did.


And please rebase more often on this branch unless you merge it soon.


On Mon, Nov 28, 2016 at 2:36 PM, Clebert Suconic
 wrote:

If / when we do the 2.0 bump, I would like to move a few classes.
Mainly under server.impl... I would like to move activations under a
package for activation, replicationendpoints for a package for
replications...some small stuff like that just to reorganize
little things like this a bit.

We can't do that now as that would break API and compatibility, but if
we do the bump, I would like to make that simple move.

On Thu, Nov 24, 2016 at 4:41 AM, Martyn Taylor 
wrote:

Hi Matt,

Comments inline.

On Mon, Nov 21, 2016 at 7:02 PM, Matt Pavlovich 
wrote:


Martyn-

I think you nailed it here-- well done =)

My notes in-line--

On 11/21/16 10:45 AM, Martyn Taylor wrote:


1. Ability to route messages to queues with the same address, but
different
routing semantics.

The proposal outlined in ARTEMIS-780 outlines a new model that
introduces
an address object at the configuration and management layer. In the
proposal it is not possible to create 2 addresses with different
routing
types. This causes a problem with existing clients (JMS, STOMP and for
compatability with other vendors).

Potential Modification: Addresses can have multiple routing type
“endpoints”, either “multicast” only, “anycast” only or both. The
example
below would be used to represent a JMS Topic called “foo”, with a
single
subscription queue and a JMS Queue called “foo”. N.B. The actual XML
is
just an example, there are multiple ways this could be represented
that we
can define later.

<*addresses*>   <*address* *name**="foo"*>  <*anycast*>
<*queues*><*queue* *name**="**foo”* /> 
   <*mulcast*> <*queues*>
<*queue* *name**="my.topic.subscription" */> 
   


I think this solves it. The crux of the issues (for me) boils down to
auto-creation of destinations across protocols. Having this show up in
the
configs would give developers and admins more information to
troubleshoot
the mixed 

Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Christopher Shannon]

+1 for merging the branch into master after the cleanup is done and bumping
to 2.0 since it is a major architecture change.


On Wed, Dec 7, 2016 at 3:31 PM, Justin Bertram  wrote:

> Essential feature parity with 5.x (where it makes sense) has been a goal
> all along, but I think waiting until such parity exists before the next
> major release means the community will be waiting quite a bit longer than
> they already have.  Meanwhile, new functionality that could benefit the
> community will remain unavailable.  In any event, "feature parity" is a bit
> vague.  If there is something specific with regards to 5.x parity that
> you're looking for then I think you should make that explicit so it can be
> evaluated.
>
> I'm in favor of merging the addressing changes onto master, hardening
> things up a bit, and then releasing.
>
>
> Justin
>
> - Original Message -
> From: "Matt Pavlovich" 
> To: dev@activemq.apache.org
> Sent: Wednesday, December 7, 2016 2:04:13 PM
> Subject: Re: [DISCUSS] Artemis addressing improvements, JMS component
> removal and potential 2.0.0
>
> IMHO, I think it would be good to kick up a thread on what it means to
> be 2.0. It sounds like the addressing changes definitely warrant it on
> its own, but I'm thinking having ActiveMQ 5.x feature parity would be a
> good goal for the 2.0 release.  My $0.02
>
> On 12/7/16 2:56 PM, Clebert Suconic wrote:
> > +1000
> >
> >
> > It needs one final cleanup before it can be done though.. these commit
> > messages need meaninful descriptions.
> >
> > if Justin or Martyn could come up with that since they did most of the
> > work on the branch.
> >
> > This will really require bumping the release to 2.0.0 (there's a
> > 2.0.snapshot commit on it already).  I would merge this into master,
> > and fork the current master as 1.x.
> >
> >
> >
> >
> > On Wed, Dec 7, 2016 at 1:52 PM, Timothy Bish 
> wrote:
> >> This would be a good time to move to master, would allow other to more
> >> easily get onboard
> >>
> >>
> >> On 12/07/2016 01:25 PM, Clebert Suconic wrote:
> >>> I have rebased ARTEMIS-780 in top of master. There was a lot of
> >>> conflicts...
> >>>
> >>> I have aggregated/squashed most of the commits by chronological order
> >>> almost. So if Martyn had 10 commits in series I had squashed all of
> >>> them, since they were small comments anyways. The good thing about
> >>> this is that nobody would lose authorship of these commits.
> >>>
> >>> We will need to come up with more meaningful messages for these
> >>> commits before we can merge into master. But this is getting into a
> >>> very good shape. I'm impressed by the amount of work I see done on
> >>> this branch. Very well done guys! I mean it!
> >>>
> >>> Also, I have saved the old branch before I pushed -f into my fork as
> >>> old-ARTEMIS-780 in case I broke anything on the process. Please check
> >>> everything and let me know if I did.
> >>>
> >>>
> >>> And please rebase more often on this branch unless you merge it soon.
> >>>
> >>>
> >>> On Mon, Nov 28, 2016 at 2:36 PM, Clebert Suconic
> >>>  wrote:
>  If / when we do the 2.0 bump, I would like to move a few classes.
>  Mainly under server.impl... I would like to move activations under a
>  package for activation, replicationendpoints for a package for
>  replications...some small stuff like that just to reorganize
>  little things like this a bit.
> 
>  We can't do that now as that would break API and compatibility, but if
>  we do the bump, I would like to make that simple move.
> 
>  On Thu, Nov 24, 2016 at 4:41 AM, Martyn Taylor 
>  wrote:
> > Hi Matt,
> >
> > Comments inline.
> >
> > On Mon, Nov 21, 2016 at 7:02 PM, Matt Pavlovich 
> > wrote:
> >
> >> Martyn-
> >>
> >> I think you nailed it here-- well done =)
> >>
> >> My notes in-line--
> >>
> >> On 11/21/16 10:45 AM, Martyn Taylor wrote:
> >>
> >>> 1. Ability to route messages to queues with the same address, but
> >>> different
> >>> routing semantics.
> >>>
> >>> The proposal outlined in ARTEMIS-780 outlines a new model that
> >>> introduces
> >>> an address object at the configuration and management layer. In the
> >>> proposal it is not possible to create 2 addresses with different
> >>> routing
> >>> types. This causes a problem with existing clients (JMS, STOMP and
> for
> >>> compatability with other vendors).
> >>>
> >>> Potential Modification: Addresses can have multiple routing type
> >>> “endpoints”, either “multicast” only, “anycast” only or both. The
> >>> example
> >>> below would be used to represent a JMS Topic called “foo”, with a
> >>> single
> >>> subscription queue and a JMS Queue called “foo”. N.B. The actual
> XML
> >>> is
> >>> just 

Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Justin Bertram]

Essential feature parity with 5.x (where it makes sense) has been a goal all 
along, but I think waiting until such parity exists before the next major 
release means the community will be waiting quite a bit longer than they 
already have.  Meanwhile, new functionality that could benefit the community 
will remain unavailable.  In any event, "feature parity" is a bit vague.  If 
there is something specific with regards to 5.x parity that you're looking for 
then I think you should make that explicit so it can be evaluated.

I'm in favor of merging the addressing changes onto master, hardening things up 
a bit, and then releasing.


Justin

- Original Message -
From: "Matt Pavlovich" 
To: dev@activemq.apache.org
Sent: Wednesday, December 7, 2016 2:04:13 PM
Subject: Re: [DISCUSS] Artemis addressing improvements, JMS component removal 
and potential 2.0.0

IMHO, I think it would be good to kick up a thread on what it means to 
be 2.0. It sounds like the addressing changes definitely warrant it on 
its own, but I'm thinking having ActiveMQ 5.x feature parity would be a 
good goal for the 2.0 release.  My $0.02

On 12/7/16 2:56 PM, Clebert Suconic wrote:
> +1000
>
>
> It needs one final cleanup before it can be done though.. these commit
> messages need meaninful descriptions.
>
> if Justin or Martyn could come up with that since they did most of the
> work on the branch.
>
> This will really require bumping the release to 2.0.0 (there's a
> 2.0.snapshot commit on it already).  I would merge this into master,
> and fork the current master as 1.x.
>
>
>
>
> On Wed, Dec 7, 2016 at 1:52 PM, Timothy Bish  wrote:
>> This would be a good time to move to master, would allow other to more
>> easily get onboard
>>
>>
>> On 12/07/2016 01:25 PM, Clebert Suconic wrote:
>>> I have rebased ARTEMIS-780 in top of master. There was a lot of
>>> conflicts...
>>>
>>> I have aggregated/squashed most of the commits by chronological order
>>> almost. So if Martyn had 10 commits in series I had squashed all of
>>> them, since they were small comments anyways. The good thing about
>>> this is that nobody would lose authorship of these commits.
>>>
>>> We will need to come up with more meaningful messages for these
>>> commits before we can merge into master. But this is getting into a
>>> very good shape. I'm impressed by the amount of work I see done on
>>> this branch. Very well done guys! I mean it!
>>>
>>> Also, I have saved the old branch before I pushed -f into my fork as
>>> old-ARTEMIS-780 in case I broke anything on the process. Please check
>>> everything and let me know if I did.
>>>
>>>
>>> And please rebase more often on this branch unless you merge it soon.
>>>
>>>
>>> On Mon, Nov 28, 2016 at 2:36 PM, Clebert Suconic
>>>  wrote:
 If / when we do the 2.0 bump, I would like to move a few classes.
 Mainly under server.impl... I would like to move activations under a
 package for activation, replicationendpoints for a package for
 replications...some small stuff like that just to reorganize
 little things like this a bit.

 We can't do that now as that would break API and compatibility, but if
 we do the bump, I would like to make that simple move.

 On Thu, Nov 24, 2016 at 4:41 AM, Martyn Taylor 
 wrote:
> Hi Matt,
>
> Comments inline.
>
> On Mon, Nov 21, 2016 at 7:02 PM, Matt Pavlovich 
> wrote:
>
>> Martyn-
>>
>> I think you nailed it here-- well done =)
>>
>> My notes in-line--
>>
>> On 11/21/16 10:45 AM, Martyn Taylor wrote:
>>
>>> 1. Ability to route messages to queues with the same address, but
>>> different
>>> routing semantics.
>>>
>>> The proposal outlined in ARTEMIS-780 outlines a new model that
>>> introduces
>>> an address object at the configuration and management layer. In the
>>> proposal it is not possible to create 2 addresses with different
>>> routing
>>> types. This causes a problem with existing clients (JMS, STOMP and for
>>> compatability with other vendors).
>>>
>>> Potential Modification: Addresses can have multiple routing type
>>> “endpoints”, either “multicast” only, “anycast” only or both. The
>>> example
>>> below would be used to represent a JMS Topic called “foo”, with a
>>> single
>>> subscription queue and a JMS Queue called “foo”. N.B. The actual XML
>>> is
>>> just an example, there are multiple ways this could be represented
>>> that we
>>> can define later.
>>>
>>> <*addresses*>   <*address* *name**="foo"*>  <*anycast*>
>>> <*queues*><*queue* *name**="**foo”* /> 
>>>   <*mulcast*> <*queues*>
>>> <*queue* *name**="my.topic.subscription" */> 
>>>
>>>
>> I think this solves it. The crux of the 

Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Matt Pavlovich]

IMHO, I think it would be good to kick up a thread on what it means to 
be 2.0. It sounds like the addressing changes definitely warrant it on 
its own, but I'm thinking having ActiveMQ 5.x feature parity would be a 
good goal for the 2.0 release.  My $0.02


On 12/7/16 2:56 PM, Clebert Suconic wrote:

+1000


It needs one final cleanup before it can be done though.. these commit
messages need meaninful descriptions.

if Justin or Martyn could come up with that since they did most of the
work on the branch.

This will really require bumping the release to 2.0.0 (there's a
2.0.snapshot commit on it already).  I would merge this into master,
and fork the current master as 1.x.




On Wed, Dec 7, 2016 at 1:52 PM, Timothy Bish  wrote:

This would be a good time to move to master, would allow other to more
easily get onboard


On 12/07/2016 01:25 PM, Clebert Suconic wrote:

I have rebased ARTEMIS-780 in top of master. There was a lot of
conflicts...

I have aggregated/squashed most of the commits by chronological order
almost. So if Martyn had 10 commits in series I had squashed all of
them, since they were small comments anyways. The good thing about
this is that nobody would lose authorship of these commits.

We will need to come up with more meaningful messages for these
commits before we can merge into master. But this is getting into a
very good shape. I'm impressed by the amount of work I see done on
this branch. Very well done guys! I mean it!

Also, I have saved the old branch before I pushed -f into my fork as
old-ARTEMIS-780 in case I broke anything on the process. Please check
everything and let me know if I did.


And please rebase more often on this branch unless you merge it soon.


On Mon, Nov 28, 2016 at 2:36 PM, Clebert Suconic
 wrote:

If / when we do the 2.0 bump, I would like to move a few classes.
Mainly under server.impl... I would like to move activations under a
package for activation, replicationendpoints for a package for
replications...some small stuff like that just to reorganize
little things like this a bit.

We can't do that now as that would break API and compatibility, but if
we do the bump, I would like to make that simple move.

On Thu, Nov 24, 2016 at 4:41 AM, Martyn Taylor 
wrote:

Hi Matt,

Comments inline.

On Mon, Nov 21, 2016 at 7:02 PM, Matt Pavlovich 
wrote:


Martyn-

I think you nailed it here-- well done =)

My notes in-line--

On 11/21/16 10:45 AM, Martyn Taylor wrote:


1. Ability to route messages to queues with the same address, but
different
routing semantics.

The proposal outlined in ARTEMIS-780 outlines a new model that
introduces
an address object at the configuration and management layer. In the
proposal it is not possible to create 2 addresses with different
routing
types. This causes a problem with existing clients (JMS, STOMP and for
compatability with other vendors).

Potential Modification: Addresses can have multiple routing type
“endpoints”, either “multicast” only, “anycast” only or both. The
example
below would be used to represent a JMS Topic called “foo”, with a
single
subscription queue and a JMS Queue called “foo”. N.B. The actual XML
is
just an example, there are multiple ways this could be represented
that we
can define later.

<*addresses*>   <*address* *name**="foo"*>  <*anycast*>
<*queues*><*queue* *name**="**foo”* /> 
  <*mulcast*> <*queues*>
<*queue* *name**="my.topic.subscription" */> 
   


I think this solves it. The crux of the issues (for me) boils down to
auto-creation of destinations across protocols. Having this show up in
the
configs would give developers and admins more information to
troubleshoot
the mixed address type+protocol scenario.

2. Sending to “multicast”, “anycast” or “all”

As mentioned earlier JMS (and other clients such as STOMP via
prefixing)
allow the producer to identify the type of end point it would like to
send
to.

If a JMS client creates a producer and passes in a topic with address
“foo”. Then only the queues associated with the “multicast” section of
the
address. A similar thing happens when the JMS producer sends to a
“queue”
messages should be distributed amongst the queues associated with the
“anycast” section of the address.

There may also be a case when a producer does not identify the
endpoint
type, and simply sends to “foo”. AMQP or MQTT may want to do this. In
this
scenario both should happen. All the queues under the multicast
section
get
a copy of the message, and one queue under the anycast section gets
the
message.

Modification: None Needed. Internal APIs would need to be updated to
allow
this functionality.


I think the "deliver to all" scenario should be fine. This seems
analogous
to a CompositeDestination in ActiveMQ 5.x. I'll map through some
scenarios
and report back any gotchas.

3. Support for prefixes to identify endpoint types

Many 

Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Matt Pavlovich]

+1


On 12/7/16 1:52 PM, Timothy Bish wrote:
This would be a good time to move to master, would allow other to more 
easily get onboard


On 12/07/2016 01:25 PM, Clebert Suconic wrote:
I have rebased ARTEMIS-780 in top of master. There was a lot of 
conflicts...


I have aggregated/squashed most of the commits by chronological order
almost. So if Martyn had 10 commits in series I had squashed all of
them, since they were small comments anyways. The good thing about
this is that nobody would lose authorship of these commits.

We will need to come up with more meaningful messages for these
commits before we can merge into master. But this is getting into a
very good shape. I'm impressed by the amount of work I see done on
this branch. Very well done guys! I mean it!

Also, I have saved the old branch before I pushed -f into my fork as
old-ARTEMIS-780 in case I broke anything on the process. Please check
everything and let me know if I did.


And please rebase more often on this branch unless you merge it soon.


On Mon, Nov 28, 2016 at 2:36 PM, Clebert Suconic
 wrote:

If / when we do the 2.0 bump, I would like to move a few classes.
Mainly under server.impl... I would like to move activations under a
package for activation, replicationendpoints for a package for
replications...some small stuff like that just to reorganize
little things like this a bit.

We can't do that now as that would break API and compatibility, but if
we do the bump, I would like to make that simple move.

On Thu, Nov 24, 2016 at 4:41 AM, Martyn Taylor  
wrote:

Hi Matt,

Comments inline.

On Mon, Nov 21, 2016 at 7:02 PM, Matt Pavlovich 
 wrote:



Martyn-

I think you nailed it here-- well done =)

My notes in-line--

On 11/21/16 10:45 AM, Martyn Taylor wrote:


1. Ability to route messages to queues with the same address, but
different
routing semantics.

The proposal outlined in ARTEMIS-780 outlines a new model that 
introduces

an address object at the configuration and management layer. In the
proposal it is not possible to create 2 addresses with different 
routing
types. This causes a problem with existing clients (JMS, STOMP 
and for

compatability with other vendors).

Potential Modification: Addresses can have multiple routing type
“endpoints”, either “multicast” only, “anycast” only or both. The 
example
below would be used to represent a JMS Topic called “foo”, with a 
single
subscription queue and a JMS Queue called “foo”. N.B. The actual 
XML is
just an example, there are multiple ways this could be 
represented that we

can define later.

<*addresses*>   <*address* *name**="foo"*>  <*anycast*>
<*queues*><*queue* *name**="**foo”* /> 


 <*mulcast*> <*queues*>
<*queue* *name**="my.topic.subscription" */> 
 


I think this solves it. The crux of the issues (for me) boils down to
auto-creation of destinations across protocols. Having this show 
up in the
configs would give developers and admins more information to 
troubleshoot

the mixed address type+protocol scenario.

2. Sending to “multicast”, “anycast” or “all”
As mentioned earlier JMS (and other clients such as STOMP via 
prefixing)
allow the producer to identify the type of end point it would 
like to send

to.

If a JMS client creates a producer and passes in a topic with 
address
“foo”. Then only the queues associated with the “multicast” 
section of the
address. A similar thing happens when the JMS producer sends to a 
“queue”
messages should be distributed amongst the queues associated with 
the

“anycast” section of the address.

There may also be a case when a producer does not identify the 
endpoint
type, and simply sends to “foo”. AMQP or MQTT may want to do 
this. In this
scenario both should happen. All the queues under the multicast 
section

get
a copy of the message, and one queue under the anycast section 
gets the

message.

Modification: None Needed. Internal APIs would need to be updated 
to allow

this functionality.

I think the "deliver to all" scenario should be fine. This seems 
analogous
to a CompositeDestination in ActiveMQ 5.x. I'll map through some 
scenarios

and report back any gotchas.

3. Support for prefixes to identify endpoint types
Many clients, ActiveMQ 5.x, STOMP and potential clients from 
alternate
vendors, identify the endpoint type (in producer and consumer) 
using a

prefix notation.

e.g. queue:///foo

Which would identify:

<*addresses*>   <*address* *name**="foo"*>  <*anycast*>
<*queues*><*queue* *name**="my.foo.queue" */>
   

Modifications Needed: None to the model. An additional parameter 
to the

acceptors should be added to identify the prefix.

Just as a check point in the syntax+naming convention in your 
provided

example... would the name actually be:

<*queue* *name**="foo" .. vs "my.foo.queue" ?


The queue name can be anything.  It's the address that is used by

Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Clebert Suconic]

+1000


It needs one final cleanup before it can be done though.. these commit
messages need meaninful descriptions.

if Justin or Martyn could come up with that since they did most of the
work on the branch.

This will really require bumping the release to 2.0.0 (there's a
2.0.snapshot commit on it already).  I would merge this into master,
and fork the current master as 1.x.




On Wed, Dec 7, 2016 at 1:52 PM, Timothy Bish  wrote:
> This would be a good time to move to master, would allow other to more
> easily get onboard
>
>
> On 12/07/2016 01:25 PM, Clebert Suconic wrote:
>>
>> I have rebased ARTEMIS-780 in top of master. There was a lot of
>> conflicts...
>>
>> I have aggregated/squashed most of the commits by chronological order
>> almost. So if Martyn had 10 commits in series I had squashed all of
>> them, since they were small comments anyways. The good thing about
>> this is that nobody would lose authorship of these commits.
>>
>> We will need to come up with more meaningful messages for these
>> commits before we can merge into master. But this is getting into a
>> very good shape. I'm impressed by the amount of work I see done on
>> this branch. Very well done guys! I mean it!
>>
>> Also, I have saved the old branch before I pushed -f into my fork as
>> old-ARTEMIS-780 in case I broke anything on the process. Please check
>> everything and let me know if I did.
>>
>>
>> And please rebase more often on this branch unless you merge it soon.
>>
>>
>> On Mon, Nov 28, 2016 at 2:36 PM, Clebert Suconic
>>  wrote:
>>>
>>> If / when we do the 2.0 bump, I would like to move a few classes.
>>> Mainly under server.impl... I would like to move activations under a
>>> package for activation, replicationendpoints for a package for
>>> replications...some small stuff like that just to reorganize
>>> little things like this a bit.
>>>
>>> We can't do that now as that would break API and compatibility, but if
>>> we do the bump, I would like to make that simple move.
>>>
>>> On Thu, Nov 24, 2016 at 4:41 AM, Martyn Taylor 
>>> wrote:

 Hi Matt,

 Comments inline.

 On Mon, Nov 21, 2016 at 7:02 PM, Matt Pavlovich 
 wrote:

> Martyn-
>
> I think you nailed it here-- well done =)
>
> My notes in-line--
>
> On 11/21/16 10:45 AM, Martyn Taylor wrote:
>
>> 1. Ability to route messages to queues with the same address, but
>> different
>> routing semantics.
>>
>> The proposal outlined in ARTEMIS-780 outlines a new model that
>> introduces
>> an address object at the configuration and management layer. In the
>> proposal it is not possible to create 2 addresses with different
>> routing
>> types. This causes a problem with existing clients (JMS, STOMP and for
>> compatability with other vendors).
>>
>> Potential Modification: Addresses can have multiple routing type
>> “endpoints”, either “multicast” only, “anycast” only or both. The
>> example
>> below would be used to represent a JMS Topic called “foo”, with a
>> single
>> subscription queue and a JMS Queue called “foo”. N.B. The actual XML
>> is
>> just an example, there are multiple ways this could be represented
>> that we
>> can define later.
>>
>> <*addresses*>   <*address* *name**="foo"*>  <*anycast*>
>> <*queues*><*queue* *name**="**foo”* /> 
>>  <*mulcast*> <*queues*>
>> <*queue* *name**="my.topic.subscription" */> 
>>
>>
> I think this solves it. The crux of the issues (for me) boils down to
> auto-creation of destinations across protocols. Having this show up in
> the
> configs would give developers and admins more information to
> troubleshoot
> the mixed address type+protocol scenario.
>
> 2. Sending to “multicast”, “anycast” or “all”
>>
>> As mentioned earlier JMS (and other clients such as STOMP via
>> prefixing)
>> allow the producer to identify the type of end point it would like to
>> send
>> to.
>>
>> If a JMS client creates a producer and passes in a topic with address
>> “foo”. Then only the queues associated with the “multicast” section of
>> the
>> address. A similar thing happens when the JMS producer sends to a
>> “queue”
>> messages should be distributed amongst the queues associated with the
>> “anycast” section of the address.
>>
>> There may also be a case when a producer does not identify the
>> endpoint
>> type, and simply sends to “foo”. AMQP or MQTT may want to do this. In
>> this
>> scenario both should happen. All the queues under the multicast
>> section
>> get
>> a copy of the message, and one queue under the anycast section gets
>> the
>> message.
>>
>> Modification: None 

Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Timothy Bish]

This would be a good time to move to master, would allow other to more 
easily get onboard


On 12/07/2016 01:25 PM, Clebert Suconic wrote:

I have rebased ARTEMIS-780 in top of master. There was a lot of conflicts...

I have aggregated/squashed most of the commits by chronological order
almost. So if Martyn had 10 commits in series I had squashed all of
them, since they were small comments anyways. The good thing about
this is that nobody would lose authorship of these commits.

We will need to come up with more meaningful messages for these
commits before we can merge into master. But this is getting into a
very good shape. I'm impressed by the amount of work I see done on
this branch. Very well done guys! I mean it!

Also, I have saved the old branch before I pushed -f into my fork as
old-ARTEMIS-780 in case I broke anything on the process. Please check
everything and let me know if I did.


And please rebase more often on this branch unless you merge it soon.


On Mon, Nov 28, 2016 at 2:36 PM, Clebert Suconic
 wrote:

If / when we do the 2.0 bump, I would like to move a few classes.
Mainly under server.impl... I would like to move activations under a
package for activation, replicationendpoints for a package for
replications...some small stuff like that just to reorganize
little things like this a bit.

We can't do that now as that would break API and compatibility, but if
we do the bump, I would like to make that simple move.

On Thu, Nov 24, 2016 at 4:41 AM, Martyn Taylor  wrote:

Hi Matt,

Comments inline.

On Mon, Nov 21, 2016 at 7:02 PM, Matt Pavlovich  wrote:


Martyn-

I think you nailed it here-- well done =)

My notes in-line--

On 11/21/16 10:45 AM, Martyn Taylor wrote:


1. Ability to route messages to queues with the same address, but
different
routing semantics.

The proposal outlined in ARTEMIS-780 outlines a new model that introduces
an address object at the configuration and management layer. In the
proposal it is not possible to create 2 addresses with different routing
types. This causes a problem with existing clients (JMS, STOMP and for
compatability with other vendors).

Potential Modification: Addresses can have multiple routing type
“endpoints”, either “multicast” only, “anycast” only or both. The example
below would be used to represent a JMS Topic called “foo”, with a single
subscription queue and a JMS Queue called “foo”. N.B. The actual XML is
just an example, there are multiple ways this could be represented that we
can define later.

<*addresses*>   <*address* *name**="foo"*>  <*anycast*>
<*queues*><*queue* *name**="**foo”* /> 
 <*mulcast*> <*queues*>
<*queue* *name**="my.topic.subscription" */> 
   


I think this solves it. The crux of the issues (for me) boils down to
auto-creation of destinations across protocols. Having this show up in the
configs would give developers and admins more information to troubleshoot
the mixed address type+protocol scenario.

2. Sending to “multicast”, “anycast” or “all”

As mentioned earlier JMS (and other clients such as STOMP via prefixing)
allow the producer to identify the type of end point it would like to send
to.

If a JMS client creates a producer and passes in a topic with address
“foo”. Then only the queues associated with the “multicast” section of the
address. A similar thing happens when the JMS producer sends to a “queue”
messages should be distributed amongst the queues associated with the
“anycast” section of the address.

There may also be a case when a producer does not identify the endpoint
type, and simply sends to “foo”. AMQP or MQTT may want to do this. In this
scenario both should happen. All the queues under the multicast section
get
a copy of the message, and one queue under the anycast section gets the
message.

Modification: None Needed. Internal APIs would need to be updated to allow
this functionality.


I think the "deliver to all" scenario should be fine. This seems analogous
to a CompositeDestination in ActiveMQ 5.x. I'll map through some scenarios
and report back any gotchas.

3. Support for prefixes to identify endpoint types

Many clients, ActiveMQ 5.x, STOMP and potential clients from alternate
vendors, identify the endpoint type (in producer and consumer) using a
prefix notation.

e.g. queue:///foo

Which would identify:

<*addresses*>   <*address* *name**="foo"*>  <*anycast*>
<*queues*><*queue* *name**="my.foo.queue" */>
 

Modifications Needed: None to the model. An additional parameter to the
acceptors should be added to identify the prefix.


Just as a check point in the syntax+naming convention in your provided
example... would the name actually be:

<*queue* *name**="foo" .. vs "my.foo.queue" ?


The queue name can be anything.  It's the address that is used by
consumer/producer.  The protocol handler / broker will decided which queue
to connect to.

Re: [ActiveMQ-5.14.1] QueueBrowser can view messages being processed by consumers which are not yet unacknowledged

[Christopher Shannon]

I don't think we want to change the default behavior in 5.x since it has
been like that for a long time so it would need to be something
configurable.  You can create the Jira and see if someone has time to work
on it.

On Sat, Dec 3, 2016 at 8:51 PM, yogu13  wrote:

> Hello Matt,
>
> I have already put a fix in place. Its kind of ugly but should work for
> now.
>
> Matt / Christopher,
>
> Out of curiosity I took ActiveMQ Artemis for a spin for the same scenario
> and Artemis seems to be inline with the implementation i have seen with
> other brokers i.e. does not show the message which is currently being
> processed by a consumer.
>
> This difference in QueueBrowser approach might cause an issue for Users
> Migrating to ActiveMQ 5.x to Artemis.
>
> Would this be a driving reason for ActiveMQ accepting this change, What do
> you think ?
>
> Regards,
> -Yogesh
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/ActiveMQ-5-14-1-QueueBrowser-can-view-
> messages-being-processed-by-consumers-which-are-not-yet-
> unacknd-tp4719662p4719737.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0

[Clebert Suconic]

I have rebased ARTEMIS-780 in top of master. There was a lot of conflicts...

I have aggregated/squashed most of the commits by chronological order
almost. So if Martyn had 10 commits in series I had squashed all of
them, since they were small comments anyways. The good thing about
this is that nobody would lose authorship of these commits.

We will need to come up with more meaningful messages for these
commits before we can merge into master. But this is getting into a
very good shape. I'm impressed by the amount of work I see done on
this branch. Very well done guys! I mean it!

Also, I have saved the old branch before I pushed -f into my fork as
old-ARTEMIS-780 in case I broke anything on the process. Please check
everything and let me know if I did.


And please rebase more often on this branch unless you merge it soon.


On Mon, Nov 28, 2016 at 2:36 PM, Clebert Suconic
 wrote:
> If / when we do the 2.0 bump, I would like to move a few classes.
> Mainly under server.impl... I would like to move activations under a
> package for activation, replicationendpoints for a package for
> replications...some small stuff like that just to reorganize
> little things like this a bit.
>
> We can't do that now as that would break API and compatibility, but if
> we do the bump, I would like to make that simple move.
>
> On Thu, Nov 24, 2016 at 4:41 AM, Martyn Taylor  wrote:
>> Hi Matt,
>>
>> Comments inline.
>>
>> On Mon, Nov 21, 2016 at 7:02 PM, Matt Pavlovich  wrote:
>>
>>> Martyn-
>>>
>>> I think you nailed it here-- well done =)
>>>
>>> My notes in-line--
>>>
>>> On 11/21/16 10:45 AM, Martyn Taylor wrote:
>>>
 1. Ability to route messages to queues with the same address, but
 different
 routing semantics.

 The proposal outlined in ARTEMIS-780 outlines a new model that introduces
 an address object at the configuration and management layer. In the
 proposal it is not possible to create 2 addresses with different routing
 types. This causes a problem with existing clients (JMS, STOMP and for
 compatability with other vendors).

 Potential Modification: Addresses can have multiple routing type
 “endpoints”, either “multicast” only, “anycast” only or both. The example
 below would be used to represent a JMS Topic called “foo”, with a single
 subscription queue and a JMS Queue called “foo”. N.B. The actual XML is
 just an example, there are multiple ways this could be represented that we
 can define later.

 <*addresses*>   <*address* *name**="foo"*>  <*anycast*>
 <*queues*><*queue* *name**="**foo”* /> 
 <*mulcast*> <*queues*>
 <*queue* *name**="my.topic.subscription" */> 


>>> I think this solves it. The crux of the issues (for me) boils down to
>>> auto-creation of destinations across protocols. Having this show up in the
>>> configs would give developers and admins more information to troubleshoot
>>> the mixed address type+protocol scenario.
>>>
>>> 2. Sending to “multicast”, “anycast” or “all”

 As mentioned earlier JMS (and other clients such as STOMP via prefixing)
 allow the producer to identify the type of end point it would like to send
 to.

 If a JMS client creates a producer and passes in a topic with address
 “foo”. Then only the queues associated with the “multicast” section of the
 address. A similar thing happens when the JMS producer sends to a “queue”
 messages should be distributed amongst the queues associated with the
 “anycast” section of the address.

 There may also be a case when a producer does not identify the endpoint
 type, and simply sends to “foo”. AMQP or MQTT may want to do this. In this
 scenario both should happen. All the queues under the multicast section
 get
 a copy of the message, and one queue under the anycast section gets the
 message.

 Modification: None Needed. Internal APIs would need to be updated to allow
 this functionality.

>>> I think the "deliver to all" scenario should be fine. This seems analogous
>>> to a CompositeDestination in ActiveMQ 5.x. I'll map through some scenarios
>>> and report back any gotchas.
>>>
>>> 3. Support for prefixes to identify endpoint types

 Many clients, ActiveMQ 5.x, STOMP and potential clients from alternate
 vendors, identify the endpoint type (in producer and consumer) using a
 prefix notation.

 e.g. queue:///foo

 Which would identify:

 <*addresses*>   <*address* *name**="foo"*>  <*anycast*>
 <*queues*><*queue* *name**="my.foo.queue" */>
  

 Modifications Needed: None to the model. An additional parameter to the
 acceptors should be added to identify the prefix.

>>> Just as a check point in the syntax+naming convention in your provided
>>> 

[GitHub] activemq pull request #202: Fixes AMQ-6441 where a negative value can be ret...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [VOTE] Apache ActiveMQ Artemis 1.5.1

[Fabio Gomes dos Santos]

Already in production ...
Desired Resolution >> ARTEMIS-748

Thank you Clebert

2016-12-07 15:38 GMT-02:00 Martyn Taylor :

> +1 Thanks Clebert
>
> On Wed, Dec 7, 2016 at 11:30 AM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > +1
> >
> > On Tue, Dec 6, 2016 at 5:51 PM, Jim Gomes  wrote:
> >
> > > +1
> > >
> > > On Tue, Dec 6, 2016, 2:16 PM Timothy Bish  wrote:
> > >
> > > > +1
> > > >
> > > > * Validated signatures and sums
> > > > * Checked license and notice files
> > > > * built from source and ran some of the tests
> > > > * ran the binary broker and ran some of the examples against it.
> > > >
> > > > On 12/06/2016 01:38 PM, Clebert Suconic wrote:
> > > > > I have cut a 1.5.1 release of Artemis and it's ready for Vote.
> > > > >
> > > > > The list for the complete changes (release notes) is here:
> > > > >
> > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > projectId=12315920=12338661
> > > > >
> > > > >
> > > > > We have about 9 bug fixes on this release along with other
> > > > > improvements, including a critical fix for systems constantly using
> > > > > paging:
> > > > >
> > > > > [https://issues.apache.org/jira/browse/ARTEMIS-748] - AddressSize
> > show
> > > > > a negative number.
> > > > >
> > > > >
> > > > >
> > > > > There is also an improvement where a broker can check the network
> > > > > health and decide the life cycle of the server based on the network
> > > > > connection:
> > > > >
> > > > > [https://issues.apache.org/jira/browse/ARTEMIS-863] - The broker
> > > > > should deal with Network Failures.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Different from previous Artemis releases, this time I'm not staging
> > > > > the website as it will be orthogonal to the release. (It can be
> > > > > updated independently of the release process).
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Binary and source distributions are here:
> > > > >
> > > > https://repository.apache.org/content/repositories/
> > > orgapacheactivemq-/org/apache/activemq/apache-artemis/1.5.1/
> > > > >
> > > > > Maven repository is at:
> > > > >
> > > > https://repository.apache.org/content/repositories/
> > > orgapacheactivemq-
> > > > >
> > > > > Just for reference, in case you want to use the maven repo as a
> test
> > > > > and validate examples, there is a useful doc here:
> > > > >
> > > > http://activemq.apache.org/artemis/docs/1.5.0/hacking-
> > > guide/validating-releases.html
> > > > >
> > > > > Source tag:
> > > > >
> > > > https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
> > > git;a=tag;h=refs/tags/1.5.1
> > > > >
> > > > >
> > > > >
> > > > > Please vote to approve this release. The vote will remain open for
> 72
> > > > hours.
> > > > >
> > > > > [ ] +1 Aprove the release as Apache Artemis 1.5.1
> > > > > [ ] -1 (provide specific comments)
> > > > > [ ] 0  (no opinion)
> > > > >
> > > > >
> > > > >
> > > > > Here's my +1 (Binding).
> > > > > .
> > > > >
> > > >
> > > >
> > > > --
> > > > Tim Bish
> > > > twitter: @tabish121
> > > > blog: http://timbish.blogspot.com/
> > > >
> > > >
> > >
> >
>



-- 
Fábio Santos
supergr...@gmail.com

Re: [VOTE] Apache ActiveMQ Artemis 1.5.1

[Martyn Taylor]

+1 Thanks Clebert

On Wed, Dec 7, 2016 at 11:30 AM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> +1
>
> On Tue, Dec 6, 2016 at 5:51 PM, Jim Gomes  wrote:
>
> > +1
> >
> > On Tue, Dec 6, 2016, 2:16 PM Timothy Bish  wrote:
> >
> > > +1
> > >
> > > * Validated signatures and sums
> > > * Checked license and notice files
> > > * built from source and ran some of the tests
> > > * ran the binary broker and ran some of the examples against it.
> > >
> > > On 12/06/2016 01:38 PM, Clebert Suconic wrote:
> > > > I have cut a 1.5.1 release of Artemis and it's ready for Vote.
> > > >
> > > > The list for the complete changes (release notes) is here:
> > > >
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > projectId=12315920=12338661
> > > >
> > > >
> > > > We have about 9 bug fixes on this release along with other
> > > > improvements, including a critical fix for systems constantly using
> > > > paging:
> > > >
> > > > [https://issues.apache.org/jira/browse/ARTEMIS-748] - AddressSize
> show
> > > > a negative number.
> > > >
> > > >
> > > >
> > > > There is also an improvement where a broker can check the network
> > > > health and decide the life cycle of the server based on the network
> > > > connection:
> > > >
> > > > [https://issues.apache.org/jira/browse/ARTEMIS-863] - The broker
> > > > should deal with Network Failures.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Different from previous Artemis releases, this time I'm not staging
> > > > the website as it will be orthogonal to the release. (It can be
> > > > updated independently of the release process).
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Binary and source distributions are here:
> > > >
> > > https://repository.apache.org/content/repositories/
> > orgapacheactivemq-/org/apache/activemq/apache-artemis/1.5.1/
> > > >
> > > > Maven repository is at:
> > > >
> > > https://repository.apache.org/content/repositories/
> > orgapacheactivemq-
> > > >
> > > > Just for reference, in case you want to use the maven repo as a test
> > > > and validate examples, there is a useful doc here:
> > > >
> > > http://activemq.apache.org/artemis/docs/1.5.0/hacking-
> > guide/validating-releases.html
> > > >
> > > > Source tag:
> > > >
> > > https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
> > git;a=tag;h=refs/tags/1.5.1
> > > >
> > > >
> > > >
> > > > Please vote to approve this release. The vote will remain open for 72
> > > hours.
> > > >
> > > > [ ] +1 Aprove the release as Apache Artemis 1.5.1
> > > > [ ] -1 (provide specific comments)
> > > > [ ] 0  (no opinion)
> > > >
> > > >
> > > >
> > > > Here's my +1 (Binding).
> > > > .
> > > >
> > >
> > >
> > > --
> > > Tim Bish
> > > twitter: @tabish121
> > > blog: http://timbish.blogspot.com/
> > >
> > >
> >
>

CachedLDAPAuthorizationMap in blueprint....

[Daniel Kulp]

While debugging an issue for a client, I discovered that the 
CachedLDAPAuthorizationMap isn’t working “correctly” with blueprint and would 
like advice on how to fix it.  Basically, in Spring, the 
CachedLDAPAuthorizationMap implements the InitializingBean and DisposableBean 
interfaces so Spring will call the afterPropertiesSet method right after 
creation so it can query the LDAP server and get the ACL’s.   In blueprint, 
however, nothing calls the afterPropertiesSet method so it’s not until the 
first “update” that the ACL’s are queried so any attempt to create topics or 
anything before then would be denied.   

I can think of a few options to fix it:
1) Least potential for impact:   add a atomic boolean flag of “queried” that is 
set to false at creation, set to true on first query, and any attempt to read 
ACL’s will call the query method if it hasn’t been called before.   

2) Add @PostContruct and @PreDestroy annotations to CachedLDAPAuthorizationMap 
so blueprint will call the methods.  Not sure what spring would do if an object 
implements the interfaces AND has the annotations though.

3) Create a separate blueprint subclass and somehow get blueprint to create the 
subclass version which has the annotations on it.   Not sure how to do this 
though.


Anyway, thoughts?

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

[GitHub] activemq-artemis issue #905: added unit test for setting the user and passwo...

[pgfox]

Github user pgfox commented on the issue:

https://github.com/apache/activemq-artemis/pull/905
  
@jbertram sure, I will give that a go


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis issue #905: added unit test for setting the user and passwo...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/905
  
Thanks for the test!

For the sake of thoroughness it would be best if security was enabled on 
the test broker and the test ensured the credentials set in the URL actually 
resulted in an authenticated session.  If you don't think you can add that I'll 
go ahead and merge what you have and try to get to it later.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #905: added unit test for setting the user and...

[pgfox]

GitHub user pgfox opened a pull request:

https://github.com/apache/activemq-artemis/pull/905

added unit test for setting the user and password in the uri for tcp …

…transport, used in JNDI. 

Could not find an example in the existing unit tests. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pgfox/activemq-artemis user_password_url_jndi

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/905.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #905


commit 47a6882e156357abf97969aafc2c076e82c32dab
Author: Pat Fox 
Date:   2016-12-07T13:22:20Z

added unit test for setting the user and password in the uri for tcp 
transport, used in JNDI




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [VOTE] Apache ActiveMQ Artemis 1.5.1

[Christopher Shannon]

+1

On Tue, Dec 6, 2016 at 5:51 PM, Jim Gomes  wrote:

> +1
>
> On Tue, Dec 6, 2016, 2:16 PM Timothy Bish  wrote:
>
> > +1
> >
> > * Validated signatures and sums
> > * Checked license and notice files
> > * built from source and ran some of the tests
> > * ran the binary broker and ran some of the examples against it.
> >
> > On 12/06/2016 01:38 PM, Clebert Suconic wrote:
> > > I have cut a 1.5.1 release of Artemis and it's ready for Vote.
> > >
> > > The list for the complete changes (release notes) is here:
> > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12315920=12338661
> > >
> > >
> > > We have about 9 bug fixes on this release along with other
> > > improvements, including a critical fix for systems constantly using
> > > paging:
> > >
> > > [https://issues.apache.org/jira/browse/ARTEMIS-748] - AddressSize show
> > > a negative number.
> > >
> > >
> > >
> > > There is also an improvement where a broker can check the network
> > > health and decide the life cycle of the server based on the network
> > > connection:
> > >
> > > [https://issues.apache.org/jira/browse/ARTEMIS-863] - The broker
> > > should deal with Network Failures.
> > >
> > >
> > >
> > >
> > >
> > > Different from previous Artemis releases, this time I'm not staging
> > > the website as it will be orthogonal to the release. (It can be
> > > updated independently of the release process).
> > >
> > >
> > >
> > >
> > >
> > > Binary and source distributions are here:
> > >
> > https://repository.apache.org/content/repositories/
> orgapacheactivemq-/org/apache/activemq/apache-artemis/1.5.1/
> > >
> > > Maven repository is at:
> > >
> > https://repository.apache.org/content/repositories/
> orgapacheactivemq-
> > >
> > > Just for reference, in case you want to use the maven repo as a test
> > > and validate examples, there is a useful doc here:
> > >
> > http://activemq.apache.org/artemis/docs/1.5.0/hacking-
> guide/validating-releases.html
> > >
> > > Source tag:
> > >
> > https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.
> git;a=tag;h=refs/tags/1.5.1
> > >
> > >
> > >
> > > Please vote to approve this release. The vote will remain open for 72
> > hours.
> > >
> > > [ ] +1 Aprove the release as Apache Artemis 1.5.1
> > > [ ] -1 (provide specific comments)
> > > [ ] 0  (no opinion)
> > >
> > >
> > >
> > > Here's my +1 (Binding).
> > > .
> > >
> >
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
> >
>