On Fri, May 8, 2009 at 10:21 AM, Robert Godfrey wrote:
> I think we need clarity about whether we are defining a format for
> *JMSDestination* or for some other AMQP abstraction of
> consumer/producer/link.
I was under the impression it was the former, and wasn't trying to be
a one-stop-solutio
Robert Godfrey wrote:
I think we need clarity about whether we are defining a format for
*JMSDestination* or for some other AMQP abstraction of
consumer/producer/link.
As I understood it, the idea was to try to define JMS Destinations over
AMQP in terms of some more general format for configur
>>
>> I was thinking the format for specifying queue properties would be
>> standard across languages regardless of whether the queue declaration is
>> separate or nested.
>>
>> If you're talking about something like this:
>>
>> dest.D = MyQueue; {auto-create=true, queue-definition={durable=true, .
Rafael Schloming wrote:
Gordon Sim wrote:
Rafael Schloming wrote:
Gordon Sim wrote:
I think you might actually want to control that explicitly, e.g.
have something like this:
queuex.MyQueue = {create-on-send=true, create-on-receive=false, ...}
Why could you not do this on a 'destinationx'
Sorry I forgot to update the proposal with the JIRA number.
The patch was attached to https://issues.apache.org/jira/browse/QPID-1831
Note this contains and impl for the first proposal.
Rajith
On Thu, May 7, 2009 at 11:28 AM, Gordon Sim wrote:
> Rajith Attapattu wrote:
>>
>> I think a single de
Gordon Sim wrote:
Rafael Schloming wrote:
Gordon Sim wrote:
I think you might actually want to control that explicitly, e.g.
have something like this:
queuex.MyQueue = {create-on-send=true, create-on-receive=false, ...}
Why could you not do this on a 'destinationx'? That would seem much
n
Rafael Schloming wrote:
Gordon Sim wrote:
I think you might actually want to control that explicitly, e.g. have
something like this:
queuex.MyQueue = {create-on-send=true, create-on-receive=false, ...}
Why could you not do this on a 'destinationx'? That would seem much
neater to me.
I co
Rajith Attapattu wrote:
I think a single destination impl should be able to handle any type
and I demonstrated that in the patch with AMQXDestination class.
We currently have a destination impl per exchange and I think that
restricts flexibility and IMO this sort of specialization is
unnecessary.
On Thu, May 7, 2009 at 8:57 AM, Rafael Schloming wrote:
> Gordon Sim wrote:
>>
>> Rafael Schloming wrote:
>>>
>>> Gordon Sim wrote:
Rajith Attapattu wrote:
>
> Gordon,
>
> Thanks for you feedback. Comments inline.
>
> On Tue, May 5, 2009 at 2:06 PM, Gordon Sim wr
On Thu, May 7, 2009 at 8:31 AM, Gordon Sim wrote:
> Rafael Schloming wrote:
>>
>> Gordon Sim wrote:
>>>
>>> Rajith Attapattu wrote:
Gordon,
Thanks for you feedback. Comments inline.
On Tue, May 5, 2009 at 2:06 PM, Gordon Sim wrote:
>>
>> Suggestions and criti
Gordon Sim wrote:
I think you might actually want to control that explicitly, e.g. have
something like this:
queuex.MyQueue = {create-on-send=true, create-on-receive=false, ...}
Why could you not do this on a 'destinationx'? That would seem much
neater to me.
I could see that you might wa
Rafael Schloming wrote:
Gordon Sim wrote:
Rafael Schloming wrote:
Gordon Sim wrote:
Rajith Attapattu wrote:
Gordon,
Thanks for you feedback. Comments inline.
On Tue, May 5, 2009 at 2:06 PM, Gordon Sim wrote:
Suggestions and criticisms are equally welcomed.
I am very much in favour of som
Rafael Schloming wrote:
Gordon Sim wrote:
Rafael Schloming wrote:
Gordon Sim wrote:
Rajith Attapattu wrote:
After from feedback on the thread as well as from Rob and Rafi I have
whipped up another proposal which should be good enough for AMQP 1.0
as well.
The proposal is located at
http://cwi
Gordon Sim wrote:
Rafael Schloming wrote:
Gordon Sim wrote:
Rajith Attapattu wrote:
After from feedback on the thread as well as from Rob and Rafi I have
whipped up another proposal which should be good enough for AMQP 1.0
as well.
The proposal is located at
http://cwiki.apache.org/confluence/
Gordon Sim wrote:
Rafael Schloming wrote:
Gordon Sim wrote:
Rajith Attapattu wrote:
Gordon,
Thanks for you feedback. Comments inline.
On Tue, May 5, 2009 at 2:06 PM, Gordon Sim wrote:
Suggestions and criticisms are equally welcomed.
I am very much in favour of some changes in the configur
Rafael Schloming wrote:
Gordon Sim wrote:
Rajith Attapattu wrote:
After from feedback on the thread as well as from Rob and Rafi I have
whipped up another proposal which should be good enough for AMQP 1.0
as well.
The proposal is located at
http://cwiki.apache.org/confluence/display/qpid/Propos
Rafael Schloming wrote:
Gordon Sim wrote:
Rajith Attapattu wrote:
Gordon,
Thanks for you feedback. Comments inline.
On Tue, May 5, 2009 at 2:06 PM, Gordon Sim wrote:
Suggestions and criticisms are equally welcomed.
I am very much in favour of some changes in the configuration of
destinatio
Gordon Sim wrote:
Rajith Attapattu wrote:
Gordon,
Thanks for you feedback. Comments inline.
On Tue, May 5, 2009 at 2:06 PM, Gordon Sim wrote:
Suggestions and criticisms are equally welcomed.
I am very much in favour of some changes in the configuration of
destinations and expanding the capa
Gordon Sim wrote:
Rajith Attapattu wrote:
After from feedback on the thread as well as from Rob and Rafi I have
whipped up another proposal which should be good enough for AMQP 1.0
as well.
The proposal is located at
http://cwiki.apache.org/confluence/display/qpid/Proposal+for+a+new+JMS+Destinat
Rajith Attapattu wrote:
After from feedback on the thread as well as from Rob and Rafi I have
whipped up another proposal which should be good enough for AMQP 1.0
as well.
The proposal is located at
http://cwiki.apache.org/confluence/display/qpid/Proposal+for+a+new+JMS+Destination+configuration2
Rajith Attapattu wrote:
Gordon,
Thanks for you feedback. Comments inline.
On Tue, May 5, 2009 at 2:06 PM, Gordon Sim wrote:
Suggestions and criticisms are equally welcomed.
I am very much in favour of some changes in the configuration of
destinations and expanding the capabilities in this re
Gordon,
Thanks for you feedback. Comments inline.
On Tue, May 5, 2009 at 2:06 PM, Gordon Sim wrote:
>> Suggestions and criticisms are equally welcomed.
>
> I am very much in favour of some changes in the configuration of
> destinations and expanding the capabilities in this regard. However I won
4. Code patch (attached with email)
>>
>> The proposal is located at,
>>
>> http://cwiki.apache.org/confluence/display/qpid/Proposal+for+a+new+JMS
>> +Destination+configuration
>>
>> Suggestions and criticisms are equally welcomed.
>
> I am very much in fa
. Complete list of options available
4. Code patch (attached with email)
The proposal is located at,
http://cwiki.apache.org/confluence/display/qpid/Proposal+for+a+new+JMS
+Destination+configuration
Suggestions and criticisms are equally welcomed.
I am very much in favour of some changes in the
I'm not sure that the form you have is more conveniant. It's harder to
parse from a qpid pov and somewhat more error prone to write,
primarily due to (users) having to keep count of quotes etc. The
client has to have a parser, which if it was just flat props we'd get
for free. I know properties fil
Conceptually it is what you put down in the more verbose format.
The more compact form is just a convenient way of expressing it in the
JNDI props file which is the only config mechanism we support.
So in some other config source the more verbose form could be used.
Regards,
Rajith
On Mon, May 4
On Mon, May 4, 2009 at 3:05 AM, Rajith Attapattu wrote:
> I have taken a non URL approach for the destination abstraction.
> The definitions are a bunch of key/value pairs for each component.
Ok, given that, would it make sense to do:
pub.link. = key1='value1';key2='value2';key3='value3'..
attached with email)
>>
>> The proposal is located at,
>>
>> http://cwiki.apache.org/confluence/display/qpid/Proposal+for+a+new+JMS
>> +Destination+configuration
>>
>> Suggestions and criticisms are equally welcomed.
>>
>>
>> Regard
atch (attached with email)
>
> The proposal is located at,
>
> http://cwiki.apache.org/confluence/display/qpid/Proposal+for+a+new+JMS
> +Destination+configuration
>
> Suggestions and criticisms are equally welcomed.
>
>
available
4. Code patch (attached with email)
The proposal is located at,
http://cwiki.apache.org/confluence/display/qpid/Proposal+for+a+new+JMS
+Destination+configuration
Suggestions and criticisms are equally welcomed.
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com
30 matches
Mail list logo
