I know I'm late to this discussion, but I wanted to throw my 2 cents
in. I do not see the value in enforcing valid URIs within Camel. I
fully agree that, in this case, ease of use trumps strictly adhering to
a standard.
At Raytheon, we're using Camel as mediation between UIs, power
electronics, and databases. All over the codebase, RouteBuilders create
URI argument values that most definitely do not conform to the URI
spec. Part of why we chose Camel was that it was *easy*.
Take camel-twitter as another example. Users, including myself, would
much rather be able to search for tweets using the straight text, rather
than having to encode it.
Since the URI is isolated to the internal workings of Camel, I'd beg you
guys to consider it only as a tailorable guideline. As someone who uses
Camel frequently in multiple contexts, the product's allure is in its
simplicity.
Brett Meyer
3RiverDev.com
br...@3riverdev.com
260-349-5732
On 06/29/2012 10:34 AM, Guillaume Nodet wrote:
On Fri, Jun 29, 2012 at 4:14 PM, Hadrian Zbarcea<hzbar...@gmail.com> wrote:
Seriously Guillaume?
You may have noticed that *this* [discuss] thread was opened 8 days
*prior* to the vote. Initially that very few commented on. It's just that I
learned history all to well to know how lazy consensus works in this
community.
I do regret I have too many incoming emails every day to closely follow
everything, I try to keep up the way I can.
Honestly, I think that was not very well communicated in the vote thread.
I can't bind myself to a very loose proposition without knowing the
consequences. I agree it would be better to have valid uris, but not at
all costs. Anyway, it had the nice benefit of getting everyone involved
though :-)
You're welcome! The [vote] did the trick didn't it?
Surely it did.
I think forward compatibility is just something bound to break. We should
have backward compatibility, i.e. when we release something, ensure, that
it supports the old stuff and deprecate it. To be clear, I think it's
better to have 3.0 being uri compatible with 2.x, deprecate the old
support, then have 3.1 or 4.0 remove support for old uris, instead of
having 2.11 with new uri and 3.0 not supporting the old ones.
Maybe, maybe not. Depends on a few things, including for how long the two
syntax flavors coexisted and what the users@ community would prefer. I
admit making some assumptions about that, implicit in my proposal, that may
prove wrong in the future. I repeat, I am not against supporting both, I
only hoped at that time it would become unnecessary. But then again, I may
be wrong, we'll see.
If other tools were to inter-operate with Camel (and that is more and more
the case in my experience) we *must* enforce the standards. We can be
lenient with the input we accept, but we must be strict in what we
produce.
To me the test is simple, if new java.net.URI(str) throws an exception,
we've got work to do.
Well, what really matters in that case is where the string comes from when
you build the uri from it. The xml / java DSL could accept invalid uri
and
those be encoded later, however, this may have side effects, as people may
expect to able to use what they gave earlier in various places.
A URI is, well, a URI, there's a spec for that that everybody understands.
As there are specs for XML. Let's not talk hypothetically and focus on a
solution instead.
Well, there aren't many solutions. Either users need to encode uri or we
need to change the components to not use reserved characters. I don't
really see any other solution for now, and both are not backward
compatible. But I'm still not sure what you have really have in mind as a
technical solution.
Also I don't think we've ever transformed any endpoint uri into a
java.net.URI, so as it was already stated, one solution is also to say
those are not uris anymore (and I don't say I want this solution, but that
still is one to consider).
Cheers,
Hadrian
Hadrian
On 06/28/2012 06:24 PM, Christian Müller wrote:
If instead of
<from
uri="file://inbox?move=backup/****${date:now:yyyyMMdd}/${file:**
**name}&*
*idempotentRepository=#**myStore"
/>
or
from("file://inbox?move=****backup/${date:now:yyyyMMdd}/${**
**file:name}&**
idempotentRepository=#myStore"****)
I'm forced to write
<from
uri="file://inbox?move=backup%****2F$%7Bdate%3Anow%3AyyyyMMdd%****
7D%2F%24%7Bfile%3Aname%7D&****idempotentRepository=%****23myStore"
/>
or
from("file://inbox?move=****backup%2F$%7Bdate%3Anow%**
3AyyyyMMdd%7D%2F%24%7Bfile%****3Aname%7D&****
idempotentRepository=%**
23myStore")
this isn't a good user experience and a way I would like going down.
By thinking about a solution, I got some ideas:
<from uri="xxx" /> for valid URIs
<from endpoint="" /> for quasi URIs (change "endpoint" for whatever we
agreed)
and in Java, we could have:
fromUri() for valid URIs (I didn't really it, because we have to do the
same with to, inOut, inOnly, ...)
from("") for quasi URIs
But at the end, we still have to deal with not valid RFC-2396 URIs (like
Google it does). By writing this, I think we have to have some kind of
URI/endpoint string preprocessing which make sure the component/endpoint
receives a valid URI (and do not encode encoded URIs twice). And by
writing
this, I'm sure it's possible to handle this without introducing new DSL
elements or options. It may need some changes in the DefaultComponent
(not
sure), but it should not be a big deal for Camel 3.0.0 where we can
break
the API. Than we have one central place which is responsible for
encoding
the given endpoint string and forward a valid URI for further
processing.
WDYT?
Best,
Christian
On Thu, Jun 21, 2012 at 8:09 PM, Rob Davies<rajdav...@gmail.com>
wrote:
This sounds reasonable to me
On 21 Jun 2012, at 18:36, Hadrian Zbarcea wrote:
Sounds perfect. That's exactly what I had in mind. You are proposing
the
extra setting, which I am perfectly fine with.
Thanks a bunch,
Hadrian
On 06/21/2012 01:00 PM, Hiram Chirino wrote:
How about we add setting to the camel context which controls if the
'UnsafeUriCharactersEncoder.****encode' method is used or not?
That way folks that feel that their camel configurations MUST always
use
valid URI syntax can enable it. And the rest can continue to use the
current behavior.
Users are then in control.
On Thu, Jun 21, 2012 at 8:53 AM, Hadrian Zbarcea<hzbar...@gmail.com>
wrote:
In theory yes, that's how it kinda worked for many years. In
practice
it
fails for all sorts of edge cases. The code that actually could be
very
simple and clear is riddled with all sorts hacks. Look at the code.
Hadrian
On 06/21/2012 07:46 AM, Henryk Konsek wrote:
It seems that you want to force incompatibly between Camel 2.x and
3.0
which is a NOT "a no brainer" for me.
Good point. We will end up with ugly and backward incompatible
URIs.
What about introducing "implicit URI encoding" term? Can't we just
assume that semi-URIs strings passed to the Camel DSLs are in fact
decoded URIs?
In such case:
import org.springframework.web.util.******UriUtils;
// Decoded URI passed to the component.
String decodedUri =
"file://inbox?expression=******backup/${date:now:yyyyMMdd}/${****
**file:name}";
// If we encode this URI we will end up with valid URI:
// file://inbox?expression=******backup/$%7Bdate:now:yyyyMMdd%******
7D/$%7Bfile:name%7D
String encodedUri = UriUtils.encodeUri(decodedUri, "UTF-8");
Maybe we just could validate that URI passed to the component is
valid
AFTER encoding it?
String decodedUriFromDsl = ...
String encodedUri = UriUtils.encodeUri(******decodedUriFromDsl,
"UTF-8");
assertValidUri(encodedUri);
This will guarantee that Camel uses valid URIs but won't break
contract of many existing components.
