[DISCUSS] Should camel enforce usage of proper URIs?

[hadrian]

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

[Łukasz Dywicki]

I think that proper data structures are always welcome. :) Many components do not use authority patt of uri to authenticate user, instead of that we have username/password parameters (for me these should be marked as deprecated).

+1 for having clean URIs in 3.0


Wiadomość napisana przez Hadrian Zbarcea w dniu 11 cze 2012, o godz. 16:32:

> 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

[iocanel]

Do we have a brief estimate of how many components do not use clean URIs?

--
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>

**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*

[Raul Kripalani-2]

I know that the discussion at hand is not exactly related to what I'm
going to propose. But I'll blurt out my idea just to enrich the debate
;)

Endpoint options can be applicable to producers, consumers or both.

Currently, the validation of the applicability is done in code - if
lucky. I even luckier, the component page will tag options according
to what they are applicable to. Unfortunately, it's not always the
case. Look at camel-jms for instance.

I suggest that we add annotations to the API to decorate the fields
representing the options in the Endpoint class, to indicate what they
are applicable to.

We can then add some automatic validation logic and reporting based on
the annotations.

WDYT?

Raúl.

On 19 Jun 2012, at 22:08, Ioannis Canellos <[hidden email]> wrote:

> Do we have a brief estimate of how many components do not use clean URIs?
>
> --
> *Ioannis Canellos*
> *
> FuseSource <http://fusesource.com>
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Twitter: iocanel
> *

[hadrian]

Raul,

I agree with your suggestion. Actually what you suggest is already
partially implemented, or at lest support for that (including support
for relatively painless migration).

However, before we discuss a solution we need to agree on the principle.
I don't think we did that, reason why this issue keeps popping up. The
lazy consensus from the past may not be sufficient.

Even now, I don't know if we should interpret the few +1s during the
past week in this thread as lazy consensus. I will start a vote and we
can start flashing out a solution.

Cheers,
Hadrian



On 06/19/2012 06:46 PM, Raul Kripalani wrote:

> I know that the discussion at hand is not exactly related to what I'm
> going to propose. But I'll blurt out my idea just to enrich the debate
> ;)
>
> Endpoint options can be applicable to producers, consumers or both.
>
> Currently, the validation of the applicability is done in code - if
> lucky. I even luckier, the component page will tag options according
> to what they are applicable to. Unfortunately, it's not always the
> case. Look at camel-jms for instance.
>
> I suggest that we add annotations to the API to decorate the fields
> representing the options in the Endpoint class, to indicate what they
> are applicable to.
>
> We can then add some automatic validation logic and reporting based on
> the annotations.
>
> WDYT?
>
> Raúl.
>
> On 19 Jun 2012, at 22:08, Ioannis Canellos<[hidden email]>  wrote:
>
>> Do we have a brief estimate of how many components do not use clean URIs?
>>
>> --
>> *Ioannis Canellos*
>> *
>> FuseSource<http://fusesource.com>
>>
>> **
>> Blog: http://iocanel.blogspot.com
>> **
>> Twitter: iocanel
>> *

[Guillaume Nodet]

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 <[hidden email]> 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

--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

[Łukasz Dywicki]

Lack of separation between consumer and producer configuration is really hard. Many of Configuration objects we have is one big bag with properties. Some of them are exclusive or similar and should not be set at the same type, eg. replyTo and replyToType in JmsConfiguration. Most of properties are not documented in code so for every property users must visit camel page to check what it does. For example with bean validation there is possibility to create groups of fields and valid against given group (Component, Producer or Consumer interface can be a group discriminator).

I can imagine also situation when we extend JSR 303 for conditional expressions (eg using simple dialect to don't bring additional dependencies) to check if there is no collision in properties set by user.

Best regards,
Lukasz Dywicki
--
Code-House
http://code-house.org

Wiadomość napisana przez Raul Kripalani w dniu 20 cze 2012, o godz. 00:46:

> I know that the discussion at hand is not exactly related to what I'm
> going to propose. But I'll blurt out my idea just to enrich the debate
> ;)
>
> Endpoint options can be applicable to producers, consumers or both.
>
> Currently, the validation of the applicability is done in code - if
> lucky. I even luckier, the component page will tag options according
> to what they are applicable to. Unfortunately, it's not always the
> case. Look at camel-jms for instance.
>
> I suggest that we add annotations to the API to decorate the fields
> representing the options in the Endpoint class, to indicate what they
> are applicable to.
>
> We can then add some automatic validation logic and reporting based on
> the annotations.
>
> WDYT?
>
> Raúl.
>
> On 19 Jun 2012, at 22:08, Ioannis Canellos <[hidden email]> wrote:
>
>> Do we have a brief estimate of how many components do not use clean URIs?
>>
>> --
>> *Ioannis Canellos*
>> *
>> FuseSource <http://fusesource.com>
>>
>> **
>> Blog: http://iocanel.blogspot.com
>> **
>> Twitter: iocanel
>> *

[hadrian]

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<[hidden email]>  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
>
>
>

[Guillaume Nodet]

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 <[hidden email]> 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<[hidden email]>
>>  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
>>
>>
>>
>>
>

--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

[hadrian]

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<[hidden email]>  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<[hidden email]>
>>>   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
>>>
>>>
>>>
>>>
>>
>
>
>

[Guillaume Nodet]

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 <[hidden email]> 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<[hidden email]>
>>  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<[hidden email]>
>>>>  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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>

--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

[hadrian]

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<[hidden email]>  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<[hidden email]>
>>>   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<[hidden email]>
>>>>>   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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>

[Christian Mueller]

+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 <[hidden email]> 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<[hidden email]>
>>  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<[hidden email]>
>>>>  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<[hidden email]>
>>>>>>  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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>

[hadrian]

+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<[hidden email]>  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<[hidden email]>
>>>   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<[hidden email]>
>>>>>   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<[hidden email]>
>>>>>>>   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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>

[Christian Mueller]

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 <[hidden email]>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<[hidden email]>
>>  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<[hidden email]>
>>>>  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<[hidden email]>
>>>>>>  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<[hidden email]
>>>>>>>> >
>>>>>>>>  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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>

[hadrian]

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<[hidden email]>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<[hidden email]>
>>>   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<[hidden email]>
>>>>>   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<[hidden email]>
>>>>>>>   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<[hidden email]
>>>>>>>>>>
>>>>>>>>>   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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>

[Christian Mueller]

Cool.
Thanks for letting me know.

Christian

On Wed, Jun 20, 2012 at 11:00 PM, Hadrian Zbarcea <[hidden email]>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<[hidden email]>**
>> 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<[hidden email]>
>>>>  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<[hidden email]>
>>>>>>  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<[hidden email]
>>>>>>>> >
>>>>>>>>  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<
>>>>>>>>>> [hidden email]
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>

[Willem.Jiang]

I think camel accepts the invalid URIs is a tread off for making the URI
readable for the human. As we develop the components in the old days we
don't have the rule to for the URI be validated.
So we added lots of extra codes to handle the camel URI separately.

I'm open to validate the URI in the camel core, but we still need to
think about how to make the user easy to use and read these URI not just
for the easy life of the tools. It is not acceptable we just show or let
the the user use an encoded URI which have lots of "%x%x".


On 6/11/12 10:32 PM, Hadrian Zbarcea 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
>

--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

[Claus Ibsen-2]

On Wed, Jun 20, 2012 at 6:29 PM, Hadrian Zbarcea <[hidden email]> 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<[hidden email]>
>>  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<[hidden email]>
>>>>  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<[hidden email]>
>>>>>>  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: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

[Keith Babo]

Reading through this discussion, it seems like there are actually two levels to what is being discussed:

1) The validation rules for a proper URI and whether they are respected and enforced in Camel core.
2) The presentation of an endpoint's configuration as a URI to the user.

The rules for #1 are clear and unmistakable as defined in RFC 2396.  A given URI conforms to the specification or it does not.  If it doesn't, then it's not a URI.  You could call it something else like a "quasi-URI", but then it seems like there's an obligation to define the additional syntax and semantics of characters allowed beyond what's in a proper URI.  Seems like a convention has developed over time for certain bits (e.g. properties), but without a concrete rule for what's allowed and whats not, consistency and validation get a little rough.  Having a formal set of rules around this seems like a good thing.

For #2, I think Guillaume's earlier comment on JSON as a representation of endpoint configuration is very appropriate.  There can be multiple presentations of an endpoint's configuration which eventually reduce down to a URI.   In our project, we use XML representations of endpoint config which reduce down to a URI representation under the covers.  Perhaps the quasi-URI syntax that enjoys popularity today is a similar type of situation in that it can be a presentation of config to the user, but is always reduced to a proper URI when it hits core.

cheers,
keith

On Jun 21, 2012, at 1:07 AM, Claus Ibsen wrote:

> On Wed, Jun 20, 2012 at 6:29 PM, Hadrian Zbarcea <[hidden email]> 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<[hidden email]>
>>>  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<[hidden email]>
>>>>>  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<[hidden email]>
>>>>>>>  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: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen