On Wed, Feb 29, 2012 at 6:08 PM, Robbie Gemmell
wrote:
> Ok, so actually taking a closer look at the code (oh my eyes :p), and
> having been reminded of prior discussions around what a nice
> addressing implementation might look like, I may have moved a lot
> toward the idea of redoing things more
Ok, so actually taking a closer look at the code (oh my eyes :p), and
having been reminded of prior discussions around what a nice
addressing implementation might look like, I may have moved a lot
toward the idea of redoing things more comprehensively than I was
thinking earlier on. With the aim of
I understand that use of amq.topic does not imply something is a
Topic, we actually have lots of users using Queues on amq.topic.
However, the codebase has in many areas implied such a link and the
JNDI lookup is once such area; if you inspect the current code for the
JNDI stuff I think you you wil
On Wed, Feb 29, 2012 at 12:49 PM, Robbie Gemmell
wrote:
> Just to be clear, I have never been suggesting we remove
> 'destination.' entries from the equation. I think we should keep
> 'destination.' as we do have users already using it as its the only
> way to specify ADDRs in there,
The changes
Just to be clear, I have never been suggesting we remove
'destination.' entries from the equation. I think we should keep
'destination.' as we do have users already using it as its the only
way to specify ADDRs in there, and its also still an important entry
point for people using BURLs without the
Robbie,
My preference is also to just use "queue" and "topic" qualifiers and
deprecate "destination" , hence listed it as option #1 in a previous
email.
I agree with you, Rob and Gordon that the above approach is simple,
easy and more importantly less buggy.
The reason I had "destination" in my s
On 02/29/2012 01:29 PM, Rob Godfrey wrote:
On 29 February 2012 14:24, Gordon Sim wrote:
On 02/29/2012 12:46 PM, Robbie Gemmell wrote:
If a user specifies a type in their
address string, then I think thats the type of object they should get
I agree.
I think the scope for anyone getting a
On 29 February 2012 14:24, Gordon Sim wrote:
> On 02/29/2012 12:46 PM, Robbie Gemmell wrote:
>>
>> If a user specifies a type in their
>> address string, then I think thats the type of object they should get
>
>
> I agree.
>
>> I think the scope for anyone getting a Destination object that didnt
>
On 02/29/2012 12:46 PM, Robbie Gemmell wrote:
If a user specifies a type in their
address string, then I think thats the type of object they should get
I agree.
I think the scope for anyone getting a Destination object that didnt
actually form a concrete Queue or Topic implementation should b
On 28 February 2012 17:35, Rajith Attapattu wrote:
> Based on the discussion I would like to outline the following proposal.
> I believe it reflects the consensus so far. Please correct me if
> anything is amiss.
>
> 1. If the user wants to use the specialized interfaces (JMS 1.0) and
> pass in ei
Based on the discussion I would like to outline the following proposal.
I believe it reflects the consensus so far. Please correct me if
anything is amiss.
1. If the user wants to use the specialized interfaces (JMS 1.0) and
pass in either a Queue or a Topic, then they should be using "queue"
or "
Rob,
Addressing is indeed a pain point and most of it is due to grey areas
causing undesirable side effects.
I've got some work that I'm hoping to post today.
Let me first check that into a branch and then I will post a brief
outline of the design and the code in review board.
I'm hoping to wrap
On Tue, Feb 28, 2012 at 3:19 AM, Rob Godfrey wrote:
> On 28 February 2012 05:37, Rajith Attapattu wrote:
>> If the "queue" and "topic" qualifiers are used then I guess it makes
>> it really easy for us to work out the validation.
>>
>> What are we going to do with the "destination" qualifier ?
>>
On 02/28/2012 04:30 AM, Rajith Attapattu wrote:
As per the discussion on QPID-792, I'm moving the discussion onto the
dev list under.
I have attempted to summarise the current behaviour and some of the
comments expressed by Rob and Robbie.
Currently the clients (C++, python and JMS) resolves an
As an aside, I have been labeling the open Java Client JIRAs so its
easier to pick out clusters of JIRAs that can be worked on together /
see where the real pain points are. A quick report on open JIRAs per
label:
17 - addressing
9 - failover
9 - exception-handling
4 - deadlock
3 - timestamp
On 28 February 2012 05:37, Rajith Attapattu wrote:
> If the "queue" and "topic" qualifiers are used then I guess it makes
> it really easy for us to work out the validation.
>
> What are we going to do with the "destination" qualifier ?
> Ex destination.my-dest=
>
> 1. We deprecate this and get qp
If the "queue" and "topic" qualifiers are used then I guess it makes
it really easy for us to work out the validation.
What are we going to do with the "destination" qualifier ?
Ex destination.my-dest=
1. We deprecate this and get qpid users to use one of "queue" or
"topic" as the administrator w
17 matches
Mail list logo
