Cool. Thanks for letting me know. Christian
On Wed, Jun 20, 2012 at 11:00 PM, Hadrian Zbarcea <hzbar...@gmail.com>wrote: > Yes, it is :). > > Hadrian > > > > > On 06/20/2012 04:52 PM, Christian Müller wrote: > >> Hadrian, do you know whether >> jetty:http://... >> is a valid URI? >> >> I'm to lazy to go through the entire spec. May you know it? >> >> Christian >> >> On Wed, Jun 20, 2012 at 10:40 PM, Hadrian Zbarcea<hzbar...@gmail.com>** >> wrote: >> >> +1. Agree on all counts. All valid points. On the second bullet I think >>> we >>> have even better options. >>> Thanks >>> Hadrian >>> >>> >>> On 06/20/2012 03:47 PM, Christian Müller wrote: >>> >>> +1 for forcing valid URI from Camel 3.0 on warts if: >>>> - we can still support all options (if this is not the case, we have >>>> to >>>> discuss the concrete cases) >>>> - communicate this API breaking change in the Camel 3.0 release notes >>>> and provide the escaped char sequence for the most used chars (for >>>> convenience for our users) >>>> - URI's like jetty:http://...are valid (if not, we have to discuss >>>> this) >>>> - no change in Camel 2.x to force valid URI's (I think we all agree >>>> on >>>> this) >>>> >>>> If an influential number of users prefer to use invalid URI's for >>>> readability reasons, we could provide a converter utility class for >>>> their >>>> convenience (it's not my favor). But the DefaultComponent should assume >>>> valid URI's. >>>> >>>> And I also think validating options is an important, but different topic >>>> for a different thread... >>>> >>>> My 0.02$, >>>> Christian >>>> >>>> On Wed, Jun 20, 2012 at 6:29 PM, Hadrian Zbarcea<hzbar...@gmail.com> >>>> wrote: >>>> >>>> Guillaume, you pay a price no matter what, if you do something or if >>>> you >>>> >>>>> don't. I really don't want to talk about a solution, but the >>>>> DefaultComponent already has a @Deprecated preProcessUri(String uri) >>>>> intended to convert a current uri like String to an equivalent valid >>>>> form >>>>> (and log the new form, so that users can update their code without much >>>>> pain). The only thing we need to do is to go through each component, >>>>> define >>>>> a valid form and implement preProcessUri (hopefully in 2.11.0) and then >>>>> remove it altogether in 3.0 (and only leave an external tool maybe for >>>>> those who migrate from old versions straight to 3.0). In your example, >>>>> it's >>>>> just a matter of using parenthesis vs curlies and $ sign. >>>>> >>>>> And by the way, nothing should be affected in 2.x, tests should >>>>> continue >>>>> to work without changes, current syntax will be supported along a new, >>>>> valid syntax (and preProcessUri would provide the conversion >>>>> internally). >>>>> >>>>> There are solutions. Is there willingness? Lazy consensus doesn't seem >>>>> to >>>>> cut it, because discussions are avoided and then we come back to the >>>>> same >>>>> thing over and over again. Now we have a vote, so hopefully we'll put >>>>> this >>>>> issue to rest soon. >>>>> >>>>> Cheers, >>>>> Hadrian >>>>> >>>>> >>>>> On 06/20/2012 11:31 AM, Guillaume Nodet wrote: >>>>> >>>>> Wouldn't it affect basic things such as the file component which uses >>>>> >>>>>> endpoints such as >>>>>> file://inbox?expression=******backup/${date:now:yyyyMMdd}/${**** >>>>>> >>>>>> **file:name} >>>>>> >>>>>> and also the properties component and all camel placeholders such as >>>>>> properties:{{cool.end}} >>>>>> >>>>>> I don't really think the change is worth it if those kind of things >>>>>> are affected. >>>>>> >>>>>> On Wed, Jun 20, 2012 at 4:02 PM, Hadrian Zbarcea<hzbar...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> As I mentioned before, to me this is a no-brainer. We all advertised >>>>>> >>>>>>> for >>>>>>> almost 5 years that Camel uses URIs. That is not true, it doesn't >>>>>>> really. >>>>>>> >>>>>>> Next there is the problem of parsing. In Camel it is ambiguous how a >>>>>>> configuration string (a la URI) looks like. You could say it's ok if >>>>>>> the >>>>>>> parsing were done by a component, but it's not, it's done in the >>>>>>> core, >>>>>>> it's >>>>>>> error prone and issues creep in all the time. A couple of more recent >>>>>>> ones >>>>>>> related to the use of '%' were the trigger for this discuss. There >>>>>>> is a >>>>>>> log >>>>>>> of unnecessary code (and buggy too) we could get rid of and make >>>>>>> things >>>>>>> more >>>>>>> predictable. >>>>>>> >>>>>>> I understand the readability argument. I think however that if a >>>>>>> component >>>>>>> designer payed attention to the spec when defining the URI, we >>>>>>> wouldn't >>>>>>> be >>>>>>> in this mess and URIs could be readable too. In parenthesis (pun >>>>>>> intended), >>>>>>> parenthesis are unreserved chars (and hence safe to use), while >>>>>>> square >>>>>>> and >>>>>>> curly brackets are not. My suggestion: read the spec. >>>>>>> >>>>>>> For edge cases encoding may be necessary, but that's known and >>>>>>> expected >>>>>>> for >>>>>>> any other technology out there, most notably REST that uses URLs left >>>>>>> and >>>>>>> right. I don't see users being frustrated with Camel doing what's >>>>>>> pretty >>>>>>> much expected and unambiguous. >>>>>>> >>>>>>> Then there is the issue of tools and other libs using URIs. It is >>>>>>> impossible >>>>>>> to generate a URI consumed by camel, because by using URIs, the >>>>>>> String >>>>>>> form >>>>>>> is encoded. That totally throws Camel (that encodes once more) off. >>>>>>> >>>>>>> Now validation. Yes, it's not completely separate. I meant it's >>>>>>> separate >>>>>>> for >>>>>>> the purpose of this discussion. Actually validating URIs is much >>>>>>> easier >>>>>>> than >>>>>>> validating Strings with an unknown syntax. >>>>>>> >>>>>>> Hadrian >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 06/20/2012 08:43 AM, Guillaume Nodet wrote: >>>>>>> >>>>>>> >>>>>>> Well, I'm not sure why you consider that separate. I don't see the >>>>>>>> point in forcing the user to use encoded characters which lessen the >>>>>>>> readability if the uri is not correct at the end. >>>>>>>> Also what's the drawback in encoding the uri ? At the end, the uri >>>>>>>> encoding is correct, but it gives the user more ease of use. >>>>>>>> Can you point to such drawbacks or problems using such uris ? (sorry >>>>>>>> if I missed some previous discussions). >>>>>>>> >>>>>>>> On Wed, Jun 20, 2012 at 2:27 PM, Hadrian Zbarcea<hzbar...@gmail.com >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Proper uri syntax and validation are 2 separate issues. This >>>>>>>>> discussion >>>>>>>>> is >>>>>>>>> about the syntax. Since it's just syntax (proper encoding) I don't >>>>>>>>> see >>>>>>>>> any >>>>>>>>> risk of loosing features and I agree we shouldn't. >>>>>>>>> >>>>>>>>> Hadrian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 06/20/2012 03:02 AM, Guillaume Nodet wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Do you have any particular example ? >>>>>>>>>> I know for example activemq uses uri in an extended way with >>>>>>>>>> parenthesis and commas and I'm not sure they are completely valid. >>>>>>>>>> If getting back to real uris means loosing some features, that >>>>>>>>>> needs >>>>>>>>>> to be made clear. >>>>>>>>>> >>>>>>>>>> On Mon, Jun 11, 2012 at 4:32 PM, Hadrian Zbarcea< >>>>>>>>>> hzbar...@gmail.com >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> This is not a new topic, but it looks like it's coming back in >>>>>>>>>>> different >>>>>>>>>>> threads. Since this is is the underlying issue, I'd suggest >>>>>>>>>>> clarifying >>>>>>>>>>> this >>>>>>>>>>> first. >>>>>>>>>>> >>>>>>>>>>> At the core of the issue is a call to >>>>>>>>>>> UnsafeUriCharactersEncoder.******encode(uri) >>>>>>>>>>> in DefaultComponent.******createEndpoint(String), that made >>>>>>>>>>> camel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> silently >>>>>>>>>>> accept >>>>>>>>>>> invalid URIs and then opened the gates to component writers using >>>>>>>>>>> URIs >>>>>>>>>>> that >>>>>>>>>>> are not URIs. This behavior was there from the very beginning of >>>>>>>>>>> Camel. >>>>>>>>>>> (I >>>>>>>>>>> refactored that code to introduce a deprecated from start >>>>>>>>>>> preProcessUri >>>>>>>>>>> that >>>>>>>>>>> provided a path for cleaning up before camel-3.0, but that's a >>>>>>>>>>> separate >>>>>>>>>>> topic). >>>>>>>>>>> >>>>>>>>>>> To me, personally, using valid URIs for endpoints is a >>>>>>>>>>> no-brainer, >>>>>>>>>>> but >>>>>>>>>>> I >>>>>>>>>>> sense that there is disagreement on that. >>>>>>>>>>> >>>>>>>>>>> Thoughts? >>>>>>>>>>> Hadrian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>
