Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of hekonsek@gmail.com designates
 209.85.160.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGB5yNnCAGH7zBkoJs99kZRMBnLkAUpAO6om_o3bTN=RyyeMaA@mail.gmail.com>
References: <4FD60168.5090009@gmail.com>
	<CAEQV+EGBEE3ev_YqGxw_DuMSY9KAS0Yi_yNw5GqYLhOtg5jBwQ@mail.gmail.com>
	<4FE1C1A9.3030701@gmail.com>
	<CAEQV+EEgU0gFi-iQjwLcOvpzydDjqv2n4JVBDDCPmZ3sSi21QQ@mail.gmail.com>
	<4FE1D7FD.9000601@gmail.com>
	<CAEQV+EHqvab5RSkUu0EMv-QNY1ZhxmM8JyO+rza3gu9Ov4hSBg@mail.gmail.com>
	<4FE1FA60.3030603@gmail.com>
	<CAGB5yNnCAGH7zBkoJs99kZRMBnLkAUpAO6om_o3bTN=RyyeMaA@mail.gmail.com>
Date: Thu, 21 Jun 2012 13:46:26 +0200
Message-ID: 
 <CALhQg-bMZFvp7k=7gQ5OpBJM+a+MfAK-Mf_cVi2qxm4ayL9-uw@mail.gmail.com>
Subject: Re: [DISCUSS] Should camel enforce usage of proper URIs?
From: Henryk Konsek <hekonsek@gmail.com>
To: dev@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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

-- 
Henryk Konsek
http://henryk-konsek.blogspot.com