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).
At first I though you was talking about Camel 3.0 changes only. But reading this made me worry. It seems that you want to force incompatibly between Camel 2.x and 3.0 which is a NOT "a no brainer" for me. > In your example, it's just a matter of using parenthesis vs curlies and $ > sign. I dont understand this. Guillaume pointed out a very valid example of today with the file component. This component has since Camel 1.5 supported specifying expression in the uri configuration. http://camel.apache.org/file Are you saying that file://inbox?expression=backup/${date:now:yyyyMMdd}/${file:name} Is consider invalid, and that people need to type this differently? And what about the JBI component, the operation parameter is a JBI naming style that uses curly brackets http://camel.apache.org/jbi.html > 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
