Hi Ràul,
Now the other ticket (CAMEL-7370) has been fixed as well.
And regarding the reason why I went for ReadPreference#valueOf() instead of
ReadPreference#[primary/secondary/nearest/etc.] (that's the +0.5 points you
gave about it):
- The logic to be implemented in this way is much easier, as
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
