+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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
