camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Müller <christian.muel...@gmail.com>
Subject Re: [DISCUSS] Should camel enforce usage of proper URIs?
Date Thu, 28 Jun 2012 22:24:35 GMT
If instead of
<from
uri="file://inbox?move=backup/${date:now:yyyyMMdd}/${file:name}&amp;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&amp;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 <rajdavies@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<hzbarcea@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.
> >>>>
> >>>>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message