camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: [DISCUSS] Should camel enforce usage of proper URIs?
Date Wed, 20 Jun 2012 21:00:59 GMT
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<hzbarcea@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<hzbarcea@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<hzbarcea@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<hzbarcea@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<hzbarcea@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>

Mime
View raw message