Well, I don't see any extra advantage when using
ReadPreference#[primary/secondary/nearest/etc.] utilities compared to
ReadPreference#valueOf() as:
- ReadPreference#valueOf() is also part of the public API, the same as
ReadPreference#[primary/secondary/nearest/etc.] API
- ReadPreference#[primary/s
Hi Babak,
You're right. On revisiting this logic it seems like this functionality was
indeed unfinished. Even in the case where the Read Preference could be
resolved, we would still throw an exception.
I don't think there's much discussion here. Backwards-compatibility is not
beneficial here becau
Hi Raúl,
Thanks a lot for your feedback but it's still not clear to me how this URI
option used to work properly in the previous versions as from very first day
(Camel 2.10.0) the preexisting logic used to throw an
IllegalArgumentException *unconditionally* in all cases at the end of the
method, s
Hello Babak,
Thanks for pointing this out!
Just some background... The ReadPreference class in the MongoDB Java API
has changed substantially between the driver versions:
* The initial contribution of camel-mongodb was done against driver version
2.7.3 [1].
* Currently we are on driver version 2
Hi,
what if... the error of this comes out of the blue again, since using Camel
2.13.
It doesn't matter, if I "allowStAX" or not.
I have a simple xslt-endpoint which worked before with an "older"
Camel-Version 2.12.2. I also needed to update jaxen from 1.1 to 1.1.6 out of
a dependency-issue with
Hi
There was a flaw by MongoDbEndpoint#setReadPreference() I tried to fix last
week. See also the documentation about the readPreference option:
https://camel.apache.org/mongodb.html
In the meanwhile I've noticed that this option doesn't work *at all* anyway
because:
- For example if you try to
