On Fri, Jun 29, 2012 at 3:37 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote:
> Christian, I agree, but it's already done. Camel has that already, it's a
> method called preProcessUri.
>
> However, while I fully agree that encoding is ugly I will remind everybody
> that one of Camel's goals is to make integration simple! Forcing users to
> encode uris is definitely not helping. My point was that if component
> designers would be more careful with their design of URIs, we would not be
> in this mess. So my proposal was provide an alternative URI configuration
> for those components that today use invalid URIs. Encoding is not the only
> solution!
>
Honestly, I think that was not very well communicated in the vote thread.
I can't bind myself to a very loose proposition without knowing the
consequences. I agree it would be better to have valid uris, but not at
all costs. Anyway, it had the nice benefit of getting everyone involved
though :-)
> My proposal was also to remove the current (old) URIs in Camel 3.0,
> Hiram's counter proposal was to leave it as is and support both. I am not
> against that, so it looks like we have a path forward, we only need a more
> concrete proposal.
>
I think forward compatibility is just something bound to break. We should
have backward compatibility, i.e. when we release something, ensure, that
it supports the old stuff and deprecate it. To be clear, I think it's
better to have 3.0 being uri compatible with 2.x, deprecate the old
support, then have 3.1 or 4.0 remove support for old uris, instead of
having 2.11 with new uri and 3.0 not supporting the old ones.
> If other tools were to inter-operate with Camel (and that is more and more
> the case in my experience) we *must* enforce the standards. We can be
> lenient with the input we accept, but we must be strict in what we produce.
> To me the test is simple, if new java.net.URI(str) throws an exception,
> we've got work to do.
Well, what really matters in that case is where the string comes from when
you build the uri from it. The xml / java DSL could accept invalid uri and
those be encoded later, however, this may have side effects, as people may
expect to able to use what they gave earlier in various places.
>
>
> Hadrian
>
>
>
> On 06/28/2012 06:24 PM, Christian Müller wrote:
>
>> If instead of
>> <from
>> uri="file://inbox?move=backup/**${date:now:yyyyMMdd}/${file:**name}&*
>> *idempotentRepository=#myStore"
>> />
>> or
>> from("file://inbox?move=**backup/${date:now:yyyyMMdd}/${**file:name}&**
>> idempotentRepository=#myStore"**)
>>
>> I'm forced to write
>> <from
>> uri="file://inbox?move=backup%**2F$%7Bdate%3Anow%3AyyyyMMdd%**
>> 7D%2F%24%7Bfile%3Aname%7D&**idempotentRepository=%**23myStore"
>> />
>> or
>> from("file://inbox?move=**backup%2F$%7Bdate%3Anow%**
>> 3AyyyyMMdd%7D%2F%24%7Bfile%**3Aname%7D&**idempotentRepository=%**
>> 23myStore")
>>
>> this isn't a good user experience and a way I would like going down.
>>
>>
>> By thinking about a solution, I got some ideas:
>> <from uri="xxx" /> for valid URIs
>> <from endpoint="" /> for quasi URIs (change "endpoint" for whatever we
>> agreed)
>>
>> and in Java, we could have:
>> fromUri() for valid URIs (I didn't really it, because we have to do the
>> same with to, inOut, inOnly, ...)
>> from("") for quasi URIs
>>
>> But at the end, we still have to deal with not valid RFC-2396 URIs (like
>> Google it does). By writing this, I think we have to have some kind of
>> URI/endpoint string preprocessing which make sure the component/endpoint
>> receives a valid URI (and do not encode encoded URIs twice). And by
>> writing
>> this, I'm sure it's possible to handle this without introducing new DSL
>> elements or options. It may need some changes in the DefaultComponent (not
>> sure), but it should not be a big deal for Camel 3.0.0 where we can break
>> the API. Than we have one central place which is responsible for encoding
>> the given endpoint string and forward a valid URI for further processing.
>>
>> WDYT?
>>
>> Best,
>> Christian
>>
>>
>>
>> On Thu, Jun 21, 2012 at 8:09 PM, Rob Davies <rajdav...@gmail.com> wrote:
>>
>> This sounds reasonable to me
>>> On 21 Jun 2012, at 18:36, Hadrian Zbarcea wrote:
>>>
>>> Sounds perfect. That's exactly what I had in mind. You are proposing the
>>>>
>>> extra setting, which I am perfectly fine with.
>>>
>>>>
>>>> Thanks a bunch,
>>>> Hadrian
>>>>
>>>> On 06/21/2012 01:00 PM, Hiram Chirino wrote:
>>>>
>>>>> How about we add setting to the camel context which controls if the
>>>>> 'UnsafeUriCharactersEncoder.**encode' method is used or not?
>>>>>
>>>>> That way folks that feel that their camel configurations MUST always
>>>>> use
>>>>> valid URI syntax can enable it. And the rest can continue to use the
>>>>> current behavior.
>>>>>
>>>>> Users are then in control.
>>>>>
>>>>> On Thu, Jun 21, 2012 at 8:53 AM, Hadrian Zbarcea<hzbar...@gmail.com>
>>>>>
>>>> wrote:
>>>
>>>>
>>>>> In theory yes, that's how it kinda worked for many years. In practice
>>>>>>
>>>>> it
>>>
>>>> fails for all sorts of edge cases. The code that actually could be very
>>>>>> simple and clear is riddled with all sorts hacks. Look at the code.
>>>>>>
>>>>>> Hadrian
>>>>>>
>>>>>>
>>>>>> On 06/21/2012 07:46 AM, Henryk Konsek wrote:
>>>>>>
>>>>>> It seems that you want to force incompatibly between Camel 2.x and
>>>>>>> 3.0
>>>>>>>
>>>>>>>> which is a NOT "a no brainer" for me.
>>>>>>>>
>>>>>>>>
>>>>>>> Good point. We will end up with ugly and backward incompatible URIs.
>>>>>>>
>>>>>>> What about introducing "implicit URI encoding" term? Can't we just
>>>>>>> assume that semi-URIs strings passed to the Camel DSLs are in fact
>>>>>>> decoded URIs?
>>>>>>>
>>>>>>> In such case:
>>>>>>>
>>>>>>> import org.springframework.web.util.****UriUtils;
>>>>>>> // Decoded URI passed to the component.
>>>>>>> String decodedUri =
>>>>>>>
>>>>>>> "file://inbox?expression=****backup/${date:now:yyyyMMdd}/${**
>>> **file:name}";
>>>
>>>> // If we encode this URI we will end up with valid URI:
>>>>>>> // file://inbox?expression=****backup/$%7Bdate:now:yyyyMMdd%****
>>>>>>> 7D/$%7Bfile:name%7D
>>>>>>> String encodedUri = UriUtils.encodeUri(decodedUri, "UTF-8");
>>>>>>>
>>>>>>> Maybe we just could validate that URI passed to the component is
>>>>>>> valid
>>>>>>> AFTER encoding it?
>>>>>>>
>>>>>>> String decodedUriFromDsl = ...
>>>>>>> String encodedUri = UriUtils.encodeUri(****decodedUriFromDsl,
>>>>>>> "UTF-8");
>>>>>>> assertValidUri(encodedUri);
>>>>>>>
>>>>>>> This will guarantee that Camel uses valid URIs but won't break
>>>>>>> contract of many existing components.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
