Hi Keith,
The system properties are documented here
http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch03s06.html
It would be nice if you can add them here as well. These docs are version
controlled and is released along with the code/binaries.
So if you are planning any documen
On Thu, Sep 22, 2011 at 12:19 PM, Oleksandr Rudyy wrote:
> Thanks Rajith for your commentaries.
> I have discussed them with Robbie, our comments inline.
>
>>> Qpid Java Client Failover Policy
>>>
>>> 1. Qpid client failover basic principles.
>>> ===
On Thu, Sep 29, 2011 at 12:02 PM, Oleksandr Rudyy wrote:
> Rajith,
>
> Thanks a lot for your feedback.
>
> Could you also have a look into the Failover Behaviour WIKI we created
> to summarize the failover behaviour?
Alex nice work to get the wiki page up and running.
I added my comments/question
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2366/
---
Review request for qpid, Gordon Sim, Robbie Gemmell, Weston Price, and Keith
Wall
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2364/
---
(Updated 2011-10-12 21:09:40.553855)
Review request for qpid, Gordon Sim, Robbie
tests for it?
It does work with the existing functionality. testDurableSubscriber() in
AddressBasedDestinationTest.java
However we should have destination syntax independent tests so we could
leverage the existing durable subscriber tests (all though they themselves are
a
. That it is possible to create a Destination using the JMS API or
> > a properties file from what is effectively just a String, and that this
> > String value is sufficient to identify the Destination for use by someone
> > else, suggests the level of mutating operations we currently have
. That it is possible to create a Destination using the JMS API or
> > a properties file from what is effectively just a String, and that this
> > String value is sufficient to identify the Destination for use by someone
> > else, suggests the level of mutating operations we currently have
> http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageProducer_0_10.java,
> > lines 229-230
> > <https://reviews.apache.org/r/2364/diff/1/?file=49771#file49771line229>
> >
> > TODO ?
Yes, correct
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2366/#review2549
-------
On 2011-10-12 21:02:31, rajith attapattu wrote:
>
> -
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2366/#review2551
-------
On 2011-10-12 21:02:31, rajith attapattu wrote:
>
> ---
are created, they also require details about the
behaviour of a specific syntax.
But if you hide them behind Destination implementations, then the Sessions can
be easily used with any Destination implementation without code changes.
That is a main goal of this refactor.
-
. That it is possible to create a Destination using the JMS API or
> > a properties file from what is effectively just a String, and that this
> > String value is sufficient to identify the Destination for use by someone
> > else, suggests the level of mutating operations we currently have
On Mon, Oct 17, 2011 at 5:54 AM, Robbie Gemmell
wrote:
> Why do we resolve Address node types? This question arose during
> review of proposed updates to the Address syntax implementation for
> the Java client, but ultimately looks to be a wider question for all
> the clients and so I am asking it
On Mon, Oct 17, 2011 at 12:39 PM, Robbie Gemmell
wrote:
> On 17 October 2011 16:01, Rajith Attapattu wrote:
>> On Mon, Oct 17, 2011 at 5:54 AM, Robbie Gemmell
>> wrote:
>>> Why do we resolve Address node types? This question arose during
>>> review of propo
iment with a different idea and see. I felt there was
more flexibility in that model.
But clearly I'm in the minority and most people think it's a bad idea
and I'm happy to go with the majority decision.
I'm happy to work on a solution that everybody feels is appropriate
and desira
On Thu, Oct 20, 2011 at 12:38 PM, Robbie Gemmell
wrote:
> On 20 October 2011 16:36, Rajith Attapattu wrote:
>> On Thu, Oct 20, 2011 at 6:05 AM, Rob Godfrey wrote:
>>> Sorry for being a little late responding to this thread...
>>>
>>> Stepping back for a secon
On Mon, Oct 31, 2011 at 9:18 AM, Robbie Gemmell
wrote:
> Hi all,
>
> Over the weekend I made a change to the 0-10 Java client so that using
> prefetch=1 with transacted sessions and an OnMessage() listener would
> result in the client only getting 1 message at a time, by moving the
> sending of co
ly makes any difference to asynchronous consumers.
I'm fine with the current change you've made.
Lets actually look at this credit issue in more detail after the release.
> Robbie
>
> On 31 October 2011 15:19, Rajith Attapattu wrote:
>> On Mon, Oct 31, 2011 at 9:18 AM,
Hi All,
Pavel has raised QPID-3575, where connections are not being closed
properly when session exceptions are raised via exception listeners.
He has also observed that, explicit closing of the session (after
receiving the exception) as a workaround doesn't work either.
We should investigate the
Hi Robbie (and co),
I noticed at least one behavioural changes that warrants a prominent
release note.
I've added a comment in QPID-3583 to cover the change of acking
behaviour for the AUTO_ACK case. See [1]
Could you guys help with some of the changes made in the failover side.
I'd let you folks
TCP_NODELAY makes a considerable improvement in synchronous cases
(sync pub, sync ack etc) and small tx cases and we generally recommend
that as a tuning option to our users/customers.
The reason for making TCP_NODELAY false by default is based on the
assumption that in most cases people will want
The upcoming java client work will have this mind (in fact a requirement).
The core client will have minimum (if not any) dependencies to
facilitate mobile environments.
We expect to do something in the 0.16 (release) time frame, if not
0.18 for sure.
(We are currently about to release 0.14 and th
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2832/
---
Review request for qpid, Gordon Sim, Robbie Gemmell, Weston Price, and
Oleksandr
r why this is needed.
- rajith
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2832/#review3264
---
On 2011-11
> > Are there any other locks acquired as part of the block here? If so are
> > there any lock ordering issues where you could be introducing a deadlock?
>
> rajith attapattu wrote:
> Not that I could think of. The message-delivery-lock is taken to ensure
> that no
to edit this on the command line before I do the
final commit :)
- rajith
-------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2832/#review3294
---
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2853/
---
Review request for qpid, Gordon Sim, Robbie Gemmell, Weston Price, Keith Wall,
an
> >
> > Could this make use of AMQSession#rejectMessage?
> >
> > I wonder also if this logic sit better in AMQSession#notifyConsumer().
> > It already rejects messages if the consumer is closed. Could it not also
> > reject messages if t
On Thu, Nov 17, 2011 at 12:03 PM, Gordon Sim wrote:
> On 11/17/2011 04:57 PM, Ken Giusti wrote:
>>
>> Hi Justin,
>>
>> Would it be possible to include the fix for QPID-3626 in the upcoming rc?
>>
>> https://issues.apache.org/jira/browse/QPID-3626
>>
>> Without it, any python client that would like
> >
> > Could this make use of AMQSession#rejectMessage?
> >
> > I wonder also if this logic sit better in AMQSession#notifyConsumer().
> > It already rejects messages if the consumer is closed. Could it not also
> > reject messages if t
> >
> > What case(s) is this code required for? You are releasing a message you
> > have just received, right? When is that required?
>
> rajith attapattu wrote:
> See the above for an explanation for why this is needed.
>
> Gordon Sim wrote:
> You me
ne173>
> >
> > Some onMessage() tests would be good, given recent disparity between
> > its behaviour and receive() for things like this.
Definitely this is in the cards for sure!
I'm going to spend some time to see how best I can reuse the test code to make
it more compact
rs or not because they ignore the session acknowledge mode and go
> > with NO_ACK behaviour. Looking it over I think it seems fine due to the
> > processCompletions call in postDeliver(), but its possibly still worth a
> > check.
>
> rajith attapattu wrote:
>
it:
https://reviews.apache.org/r/2853/#review3330
-------
On 2011-11-16 18:31:12, rajith attapattu wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/2853/
>
You could use -Dqpid.heartbeat=x or use heartbeat as a broker url property.
Btw, Please don't use the AMQ** classes. These are internal classes
that will not be there going forward.
It's better to use the JMS interfaces.
Rajith
On Fri, Nov 18, 2011 at 11:17 AM, Gaston Quezada
wrote:
> Dear Frie
As Robbie mentioned, most of the git fans are already using git-svn
(I'm one of them).
So we could perhaps wait for a bit to see how the trial unfolds.
My concern is, that not everybody may be ready to use git at this
point, so if we switch, then we will be disrupting the work for some
folks.
Rath
+1 to include this.
This error msg was really annoying :)
Rajith
On Wed, Nov 30, 2011 at 5:14 PM, Robbie Gemmell
wrote:
> I would like to request merging the fix for QPID-3582: Client
> reporting "Unable to load custom SASL providers" during connection.
>
> The client logs out an error level mes
On Tue, Dec 6, 2011 at 11:02 AM, Alan Conway wrote:
> On 12/06/2011 10:59 AM, Carl Trieloff wrote:
>>
>> On 12/06/2011 10:56 AM, acon...@apache.org wrote:
>>>
>>> NOTE 1: If you are using an ACL, the cluster-username must be allowed to
>>> publish to the qpid.cluster-credentials exchange. E.g. in
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3041/
---
Review request for qpid, Alan Conway, Gordon Sim, and Kim van der Riet.
Summary
copy, update & validate the model
inside one block after acquiring the lock.
- rajith
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3041/#review3701
----
Yes Gordon alerted me to it last evening.
Weston and I are looking into it.
Rajith
On Fri, Dec 9, 2011 at 3:26 AM, Keith Wall (Reopened) (JIRA)
wrote:
>
> [
> https://issues.apache.org/jira/browse/QPID-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Keith Wal
I've added "JCA" as a component in JIRA.
Regards,
Rajith
On Tue, Dec 20, 2011 at 8:08 AM, Weston M. Price wrote:
> With the completion of
>
> https://issues.apache.org/jira/browse/QPID-3044
>
> there is a new JCA component (actually a sub-component of Java). I was
> wondering if it would make
Assuming your Queue name is "my-queue" and is already bound to
TopicExchange with an appropriate binding, you can do the following.
destination.my-queue = my-queue
destination.topicExchange = TopicExchange/usa.news
You create your consumer with "my-queue" and your producer with "topicExchange".
Y
On Wed, Dec 21, 2011 at 5:59 AM, eugene wrote:
> Hello Rajith,
>
> Thank you for your answers indeed it helped a lot.
>
> I still have a few questions if I may :-)
>
> 1. Why isn't this documented? I mean may be it is but I googled a lot
> yesterday and did not find much :(
Have you looked at ?
h
On Thu, Dec 22, 2011 at 4:10 AM, eugene wrote:
> Aha - thx for the link. So a subject is really a routing key, right? That is
> why I missed it, cause I was looking for a routing key and not subject.
Eugene, sorry for the late reply.
The subject is mapped to the routing key when using AMQP 0-10
T
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2832/
---
(Updated 2012-01-09 19:27:40.039273)
Review request for qpid, Gordon Sim, Robbie
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2832/
---
(Updated 2012-01-10 03:52:44.305560)
Review request for qpid, Gordon Sim, Robbie
Robbie, you beat me to it :)
Rajith
On Tue, Jan 10, 2012 at 9:09 AM, Robbie Gemmell
wrote:
> I was literally going to send the same email when i started reading
> the thread. The way to set thigns like TTL, priority, deliveryMode is
> on the MessageProducer either via the setters or the send met
.apache.org>
References: <20120124232647.014952388...@eris.apache.org>
Date: Tue, 24 Jan 2012 18:47:36 -0500
Message-ID:
Subject: Re: svn commit: r1235550 - in
/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client:
AMQSession.java AMQSession_0_10.java
From: Rajith Attapattu
To:
Valid point !
Let me add a note there.
Rajith
On Wed, Jan 25, 2012 at 12:36 PM, Robbie Gemmell
wrote:
> Can we please ensure to add reasons for tests being excluded from
> particular profiles. While its obvious now, after a while it often
> becomes less clear which tests should really be exclude
IIRC the no-local argument is passed on during queue-declare.
But if you create a subscription with no-local=true on an existing
queue how should we handle this situation ?
Perhaps there is also a way to pass no-local in the arguments map when
creating a subscription ?
Regards,
Rajith
-
st get away with Topics and not worry about Queues.
Rajith
> Robbie
>
> On 13 February 2012 17:36, Rajith Attapattu wrote:
>> IIRC the no-local argument is passed on during queue-declare.
>> But if you create a subscription with no-local=true on an existing
>> queue
On Sun, Feb 19, 2012 at 6:59 PM, Robbie Gemmell
wrote:
> Hi everyone,
>
> As you may or may not have noticed from the hundreds of emails I have
> no doubt generated (I kept some of the traffic off the dev list with
> bulk changes, but you cant fix some things in bulk without losing
> data), I have
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 address (with
the 0-10 protocol) as follows.
1. I
ased on
the current behaviour (as described in my first email) and then
convert it a Queue or Topic if the Destination object is passed to any
methods that require a Queue/Topic interface.
Regards,
Rajith
On Mon, Feb 27, 2012 at 11:30 PM, Rajith Attapattu wrote:
> As per the discussion on QPI
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
examples
> 1 - browsing
> 1 - amqp_compliance
>
> Addressing covers anything to do with Destinations (ADDR or BURL) but
> is clearly the major pain point... Rajith - I know you were working on
> a patch for this... what is the status of this work?
>
> Cheers,
> Rob
>
&g
this sound reasonable ? Please feel free to add/change anything I
have missed.
Regards,
Rajith
On Tue, Feb 28, 2012 at 9:53 AM, Rajith Attapattu wrote:
> Rob,
>
> Addressing is indeed a pain point and most of it is due to grey areas
> causing undesirable side effects.
> I've got s
post the code soon for review.
Gentlemen, Thanks again for sharing your thoughts on this.
Regards,
Rajith
On Wed, Feb 29, 2012 at 7:46 AM, Robbie Gemmell
wrote:
> On 28 February 2012 17:35, Rajith Attapattu wrote:
>> Based on the discussion I would like to outline the following prop
x27;m
strongly in favour of deprecating "destination" and making it quite
clear in release notes and documentation.
Again the pain of having to deal with Queue vs Topic is best handled
at configuration time by an administrator than us trying to do the
magic in the code.
Regards,
Rajith
>
;> or Topics given the way they are usually specified (i.e exhange and
>> routing key, which is the same whether the thing on the other end is
>> actually a Queue or a Topic) and constructed/used (again, check the
>> JNDI related code), I think we simply leave the behaviour of
+1 on the dir structure.
I'm not too excited about the name 'amp', but it's not a big deal either :)
It seems this is going to be treated more like a sub project of Qpid
with it's own release schedule, which I believe is the right approach.
Perhaps we should also add a /doc dir to contain the vers
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4189/
---
Review request for qpid and Robbie Gemmell.
Summary
---
Patch provided by K
Robbie,
Would you happen to know if we can have a quick look in our dir space to
see if there are any core files.
Do you have access? could either myself or Gordon get the user/pass to have
a look ?
Regards,
Rajith
P.S These are machines run ubuntu ?
On Mon, Mar 12, 2012 at 9:34 AM, Gordon Sim
test run is tied to the various Ubuntu nodes, yes.
>
> Robbie
>
> On 12 March 2012 13:52, Rajith Attapattu wrote:
> > Robbie,
> >
> > Would you happen to know if we can have a quick look in our dir space to
> see
> > if there are any core files.
> >
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4658/
---
Review request for qpid, Gordon Sim, Robbie Gemmell, Weston Price, Rafael
Schlomi
Once we get agreement on the destination work, the next step is to
integrate it into the code base.
I see the following options. Please feel free to provide your feedback on
the options provide or even suggest new options.
I'm quite happy to work with any option the majority feels the best.
1. Int
now. At the end of this process there should really be less
> > arbitrary segregation of codepaths and less legacy cruft lying around,
> > not more of it.
> >
> > Robbie
> >
> > On 5 April 2012 16:34, Rajith Attapattu wrote:
> >> Once we get agreement on
n/src/main/java/org/apache/qpid/messaging/address/Link.java,
> > lines 63-74
> > <https://reviews.apache.org/r/4658/diff/2/?file=100205#file100205line63>
> >
> > Using 'protected' for a reason?
> > Naming convention.
Initially thought about subclassing for a protocol version specific child
class, b
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/5015/#review7644
---
>From a functionality pov, this is a very welcome addition. The max qu
> On 2012-05-07 15:43:12, Alan Conway wrote:
> > Definitely needs to replicate state in a cluster. Shout if you need
> > pointers.
This more of a general problem where ACL doesn't play well with the clustered
setup.
Perhaps we could work on a case by case for the time being to get certain
fun
y wrote:
> > http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/address/Node.java,
> > lines 66-84
> > <https://reviews.apache.org/r/4658/diff/2/?file=100206#file100206line66>
> >
> > Use Enum.valueOf(...) ?
A
+1
On Mon, May 14, 2012 at 8:53 AM, Rob Godfrey wrote:
> +1
>
> On 14 May 2012 13:50, Weston M. Price wrote:
> > +1
> >
> > On May 9, 2012, at 8:57 PM, Justin Ross wrote:
> >
> >> Hi. I've now produced 0.16-rc4 at the following location:
> >>
> >> http://people.apache.org/~jross/qpid-0.16-rc4/
Hi All,
I'm trying to compile an exhaustive list of all the valid options for
binding URL.
Some of the options make sense while others a lot is left to be desired.
I'd really appreciate some help in agreeing to a proper list and also
updating the wiki for accuracy.
The wiki page here
https://cwik
ing
> Maximum redelivery number the client should set
> reject_behaviour=server either as a connection option or a queue
> Binding URL option.
>
> Kind Regards,
> Alex
>
>
>
> On 14 May 2012 22:36, Rajith Attapattu wrote:
> > Hi All,
> >
> > I'm
I just lost by a few mins :( ... damn it.
Rajith
On Tue, May 15, 2012 at 5:52 PM, Rob Godfrey wrote:
> QPID-1000 : Martin Ritchie
> QPID-2000 : Robbie Gemmel
> QPID-3000 : Gordon Sim
> QPID-4000 : Robert Godfrey
>
> 4-0 to the Brits so far in the grabbing meaningless trophy JIRA
> numbers compet
Kind Regards,
> Alex
>
> On 15 May 2012 14:24, Rajith Attapattu wrote:
> > Alex,
> >
> > Thanks for the explanation.
> > I assume this is passed as a queue-declare argument ?
> >
> > Regards,
> >
> > Rajith
> >
> >
> > On Tue
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/5151/
---
Review request for qpid, Robbie Gemmell, Weston Price, Rafael Schloming, and
Rob
suggested here.
In addition I have also made further changes based on more comments received by
Rob Godfrey.
The only missing piece (a critical one at that) is the testing. I'm planning to
add the unit tests soon.
- rajith
On 2012-04-05 15:03:30, rajith attapattu
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/5151/
---
(Updated 2012-05-17 04:34:35.003307)
Review request for qpid, Robbie Gemmell, We
I'll wait for Robbie to respond as he is the one who will push the maven
bits :D
If he is busy then I will help out.
I'd also take this opportunity to thank Justin for yet another gruelling
release. We've been doing at least two a year now, and it's a lot more
organized and planned out.
Good job!
Thanks Robbie !!
Rajith
On Fri, May 18, 2012 at 4:36 AM, Robbie Gemmell wrote:
> I promoted the staging repo for the maven artefacts about an hour ago
> on the ASF Nexus instance, they should sync to central soon.
>
> I will allow them some time to sync (and more time for the main
> distribution
Andrew, I did the following,
mkdir qpid-build
cd qpid-build
cmake ../qpid/qpid/cpp
make
Anything missing ?
Rajith
On Wed, May 23, 2012 at 8:07 PM, Andrew Stitcher wrote:
> On Wed, 2012-05-23 at 18:43 -0400, Rajith Attapattu wrote:
> > I'm getting compile errors when trying
Ok that was the issue. I have run an auto tools build before.
How do I clean up ? or do I have to nuke the dir and checkout again ?
Rajith
On Wed, May 23, 2012 at 8:24 PM, Andrew Stitcher wrote:
> On Wed, 2012-05-23 at 20:19 -0400, Rajith Attapattu wrote:
> > Andrew, I did the
I use git, so I will try git clean first :D
Failing which I will remove my local copy and go from scratch.
Thanks again for your help.
Rajith
On Wed, May 23, 2012 at 8:36 PM, Andrew Stitcher wrote:
> On Wed, 2012-05-23 at 20:27 -0400, Rajith Attapattu wrote:
> > Ok that was the issu
git clean didn't really do the trick, so had to remove the cpp dir.
After that the build worked !
As you correctly pointed out, remnants from the auto make build is what
caused this issue.
Thx for your help.
Rajith
On Wed, May 23, 2012 at 8:43 PM, Rajith Attapattu wrote:
> I use git, s
Hi All,
I've been working on providing a Java version of the Qpid API (QPID-4001)
For starters I have experimented on implementing this API over the
existing C++ client via SWIG/JNI until we get a pure Java
implementation based on Rob Godfrey's proton-j work.
There are some unique benefits provid
Hi Justin,
I would like to get the work I have done on the Qpid Java API
implementation over the c++ client into trunk for the 0.18 release.
This is a completely independent piece and would like to include as an
experimental feature for the 0.18 release.
I'm putting up the pieces for review as we
a developers.
>
> Perfectly happy to have this in some sort of sandbox for people to
> download and try out (if they really need a JMS over RDMA client or
> something)... but I think adding it to the main release artefacts for
> 0.18 would be confusing and likely to leave us
us in the past.
>
> I think that we need to avoid repeating our past mistakes and
> concentrate on building the quality into the client up front. As such
> I'd personally rather hold off on landing the experimental code just
> yet, but I do think it makes sense to make these ar
Justin,
As agreed on the other thread, I agree with Rob that it's better to
hold on to the work I'm doing until we get more discussion/review.
Most of my work (barring the C++/JNI code) are going to be used for
the future client work and it's best we take more time to settle that
down.
Since we w
;t sure how this would work.
Thanks,
rajith attapattu
od if I could add some unit testing
to some of the c++ code. Currently they are embedded in the swig files, so I
wasn't sure how this would work.
Thanks,
rajith attapattu
Seems reasonable to me.
What about versioning?
Are the bindings going to have an independent release cycle compared
to the main Qpid components ?
Rajith
On Tue, Jun 19, 2012 at 11:59 AM, Darryl L. Pierce wrote:
> Last week Ted and I talked about moving the language bindings out from
> under the
On Wed, Jun 20, 2012 at 6:50 PM, Andrew Stitcher wrote:
> On Wed, 2012-06-20 at 15:34 -0400, Darryl L. Pierce wrote:
>> On Wed, Jun 20, 2012 at 03:24:52PM -0400, Andrew Stitcher wrote:
>> > On Tue, 2012-06-19 at 16:05 -0400, Darryl L. Pierce wrote:
>> > > On Tue, Jun 19, 2012 at 02:11:51PM -0400,
Hi All,
Since we are trying to provide a consistent API for all our clients,
it would be beneficial to have a connection string that can be used
across all clients.
This is a topic that has been widely discussed but without much consensus.
The c++ client and python uses a simple scheme.
It specif
On Thu, Jun 21, 2012 at 10:15 AM, Gordon Sim wrote:
> On 06/21/2012 02:19 PM, Rajith Attapattu wrote:
>>
>> For the Java binding, the generated code (compiled into a jar file) is
>> checked into the java lib dir.
>
>
> Generating it and compiling it is a
On Thu, Jun 21, 2012 at 10:32 AM, Gordon Sim wrote:
> On 06/21/2012 03:25 PM, Rajith Attapattu wrote:
>>
>> Does the above answer your questions sufficiently ?
>
>
> Yes, but I still don't understand why you need to check the built jar into
> svn.
How else would
On Thu, Jun 21, 2012 at 10:57 AM, Andrew Stitcher wrote:
> On Thu, 2012-06-21 at 10:08 -0400, Rajith Attapattu wrote:
>> Hi All,
>>
>> Since we are trying to provide a consistent API for all our clients,
>> it would be beneficial to have a connection string that can be
1 - 100 of 1060 matches
Mail list logo
