You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Claus Ibsen <ci...@silverbullet.dk> on 2008/05/12 09:30:29 UTC
Camel 1.4 - Improved URI validation - (Component Writers pay attention) - Feedback please
Hi
In Camel 1.4 we are improving the validation when Camel creates endpoints (CAMEL-433) regarding the given URI string.
Use-case
========
As of now Camel will throw a ResolveEndpointFailedException if the validation failed with a message what is the problem.
Camel will now validate out-of-the-box:
1) Simple URI syntax
2) No more lost parameters
Ad 1)
The simple syntax validation is eg. If the end-user has forgotten that the parameters separator is a ? marker and to use & for further parameters.
So this invalid URI: timer://foo&fixedRate=true&delay=0&period=500
Will fail since there are no ? marker.
Failed to resolve endpoint: timer://foo&fixedRate=true&delay=0&period=500 due to: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: timer://foo&fixedRate=true&delay=0&period=500 due to: Invalid uri syntax: no ? marker however the uri has & parameter separators. Check the uri if its missing a ? marker.
Ad 2)
This is the most serious problem that bites most people. If they have mistyped an optional parameter Camel will ignore it and go on. This can lead to users thinking that Camel runs with that parameter but it does not.
Now Camel barfs and throws a ResolveEndpointFailedException with the list of unknown parameters.
The example from above but with a mistype in the parameter: "timer://foo?delay=250&perid=500"
Failed to resolve endpoint: timer://foo?delay=250&perid=500 due to: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: timer://foo?delay=250&perid=500 due to: There are 1 parameters that couldn't be set on the endpoint. Check the uri if the parameters are spelt correctly and that they are properties of the endpoint. Unknown parameters=[{perid=500}]
Component Writers
=================
Only in rare cases your component will not work out-of-the-box with Camel 1.4. In these conditions you need to make sure that you handle the parameters your component support.
Ïf you have code that handles parameters manually by such as: parameters.get("size");
You should get and remove the parameter such as:
parameters.get("size");
parameters.remove("size");
or in one-line
Object size = parameters.remove("size");
In Camel 1.4 we have added convenient methods to do this trick; one with a fallback to a default value if the parameter does not exists. This method does also the converTo to the requested type. These methods are added on the DefaultComponent, that most components extend:
public <T> T getAndRemoveParameter(Map parameters, String key, Class<T> type)
public <T> T getAndRemoveParameter(Map parameters, String key, Class<T> type, T defaultValue)
Feedback
========
Feedback is most welcome. Any native English speakers could proof read the exception message as I am sure it "smells".
Also I considered naming the methods getAndRemoveParameter just getParameter
And do you some ideas for even better URI validation that Camel should do out-of-the-box please feel free to comment here or on the CAMEL-433.
Med venlig hilsen
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
Re: Camel 1.4 - Improved URI validation - (Component Writers pay attention) - Feedback please
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Tue, May 13, 2008 at 10:03 AM, James Strachan
<ja...@gmail.com> wrote:
> Another thing I've wanted for a while is for folks who like using
> spring.xml to configure things, a nicer way to create endpoint
> instances in the spring.xml.
>
> I raised a JIRA to track this...
> https://issues.apache.org/activemq/browse/CAMEL-505
>
> I've added a bunch more constructors so most endpoints are a bit
> easier to create as a stand alone bean (without necessarily using the
> component as a factory) and a little example of it in use - see
> SpringFileRouteTest.java.
> http://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-spring/src/test/java/org/apache/camel/component/file/SpringFileRouteTest.java
>
> the spring XML is here
> http://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/component/file/SpringFileRouteTest-context.xml
>
>
> I've tinkered with the File endpoint so that it can be created with no
> constructor parameters then configured via properties which makes it a
> bit easier to work with in spring.xml.
>
> Its gonna be a bit of work to extend this to all endpoints. Plus some
> endpoints will require a component too. Its gonna be even harder to
> then add the endpoints into the XSD easily (without loads of error
> prone hand coding), so that we can do things like
>
> <fileEndpoint file="/tmp/foo" noop="true"/>
> <jmsQueueEndpoint destination="foo.bar"/>
>
I think what would be ideal is the components implemented spring
namespace handlers so that we could do stuff like:
<camelContext xmlns="http://activemq.apache.org/camel/schema/spring">
<template id="camelTemplate"/>
<route>
<from ref="inputFile"/>
<to uri="activemq:foo"/>
</route>
</camelContext>
<activemq:component brokerUrl="tcp://foo:61616">
<endpoint name="foo" file="queue:foo/>
</activemq:component>
<file:component>
<endpoint name="inputFile" file="target/test-default-inbox"/>
</file:component>
Not sure about the element names.. having them standardize to
component / endpoint might be confusing to folks but it would make
the configuration look more consistent across components. And yeah
each component would need it's own namespace definition which make
setting up xml a bit hard if your using alot of components...
Thoughts?
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
Re: Camel 1.4 - Improved URI validation - (Component Writers pay attention) - Feedback please
Posted by James Strachan <ja...@gmail.com>.
Another thing I've wanted for a while is for folks who like using
spring.xml to configure things, a nicer way to create endpoint
instances in the spring.xml.
I raised a JIRA to track this...
https://issues.apache.org/activemq/browse/CAMEL-505
I've added a bunch more constructors so most endpoints are a bit
easier to create as a stand alone bean (without necessarily using the
component as a factory) and a little example of it in use - see
SpringFileRouteTest.java.
http://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-spring/src/test/java/org/apache/camel/component/file/SpringFileRouteTest.java
the spring XML is here
http://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/component/file/SpringFileRouteTest-context.xml
I've tinkered with the File endpoint so that it can be created with no
constructor parameters then configured via properties which makes it a
bit easier to work with in spring.xml.
Its gonna be a bit of work to extend this to all endpoints. Plus some
endpoints will require a component too. Its gonna be even harder to
then add the endpoints into the XSD easily (without loads of error
prone hand coding), so that we can do things like
<fileEndpoint file="/tmp/foo" noop="true"/>
<jmsQueueEndpoint destination="foo.bar"/>
etc
I've created a JIRA to track this effort - its maybe a bit too hard :)
https://issues.apache.org/activemq/browse/CAMEL-506
2008/5/12 James Strachan <ja...@gmail.com>:
> Awesome stuff! I've wanted something like this for a while - great work Claus!
>
> 2008/5/12 Claus Ibsen <ci...@silverbullet.dk>:
>
>
> > Hi
> >
> > In Camel 1.4 we are improving the validation when Camel creates endpoints (CAMEL-433) regarding the given URI string.
> >
> > Use-case
> > ========
> >
> > As of now Camel will throw a ResolveEndpointFailedException if the validation failed with a message what is the problem.
> > Camel will now validate out-of-the-box:
> > 1) Simple URI syntax
> > 2) No more lost parameters
> >
> >
> > Ad 1)
> > The simple syntax validation is eg. If the end-user has forgotten that the parameters separator is a ? marker and to use & for further parameters.
> >
> > So this invalid URI: timer://foo&fixedRate=true&delay=0&period=500
> > Will fail since there are no ? marker.
> >
> > Failed to resolve endpoint: timer://foo&fixedRate=true&delay=0&period=500 due to: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: timer://foo&fixedRate=true&delay=0&period=500 due to: Invalid uri syntax: no ? marker however the uri has & parameter separators. Check the uri if its missing a ? marker.
> >
> >
> > Ad 2)
> > This is the most serious problem that bites most people. If they have mistyped an optional parameter Camel will ignore it and go on. This can lead to users thinking that Camel runs with that parameter but it does not.
> >
> > Now Camel barfs and throws a ResolveEndpointFailedException with the list of unknown parameters.
> >
> > The example from above but with a mistype in the parameter: "timer://foo?delay=250&perid=500"
> >
> >
> > Failed to resolve endpoint: timer://foo?delay=250&perid=500 due to: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: timer://foo?delay=250&perid=500 due to: There are 1 parameters that couldn't be set on the endpoint. Check the uri if the parameters are spelt correctly and that they are properties of the endpoint. Unknown parameters=[{perid=500}]
> >
> >
> > Component Writers
> > =================
> >
> > Only in rare cases your component will not work out-of-the-box with Camel 1.4. In these conditions you need to make sure that you handle the parameters your component support.
> >
> > Ïf you have code that handles parameters manually by such as: parameters.get("size");
> >
> > You should get and remove the parameter such as:
> > parameters.get("size");
> > parameters.remove("size");
> >
> > or in one-line
> > Object size = parameters.remove("size");
> >
> >
> > In Camel 1.4 we have added convenient methods to do this trick; one with a fallback to a default value if the parameter does not exists. This method does also the converTo to the requested type. These methods are added on the DefaultComponent, that most components extend:
> >
> > public <T> T getAndRemoveParameter(Map parameters, String key, Class<T> type)
> >
> > public <T> T getAndRemoveParameter(Map parameters, String key, Class<T> type, T defaultValue)
> >
> >
> > Feedback
> > ========
> > Feedback is most welcome. Any native English speakers could proof read the exception message as I am sure it "smells".
> >
> > Also I considered naming the methods getAndRemoveParameter just getParameter
> >
> > And do you some ideas for even better URI validation that Camel should do out-of-the-box please feel free to comment here or on the CAMEL-433.
> >
> >
> >
> >
> > Med venlig hilsen
> >
> > Claus Ibsen
> > ......................................
> > Silverbullet
> > Skovsgårdsvænget 21
> > 8362 Hørning
> > Tlf. +45 2962 7576
> > Web: www.silverbullet.dk
> >
> >
>
>
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Camel 1.4 - Improved URI validation - (Component Writers pay attention) - Feedback please
Posted by James Strachan <ja...@gmail.com>.
Awesome stuff! I've wanted something like this for a while - great work Claus!
2008/5/12 Claus Ibsen <ci...@silverbullet.dk>:
> Hi
>
> In Camel 1.4 we are improving the validation when Camel creates endpoints (CAMEL-433) regarding the given URI string.
>
> Use-case
> ========
>
> As of now Camel will throw a ResolveEndpointFailedException if the validation failed with a message what is the problem.
> Camel will now validate out-of-the-box:
> 1) Simple URI syntax
> 2) No more lost parameters
>
>
> Ad 1)
> The simple syntax validation is eg. If the end-user has forgotten that the parameters separator is a ? marker and to use & for further parameters.
>
> So this invalid URI: timer://foo&fixedRate=true&delay=0&period=500
> Will fail since there are no ? marker.
>
> Failed to resolve endpoint: timer://foo&fixedRate=true&delay=0&period=500 due to: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: timer://foo&fixedRate=true&delay=0&period=500 due to: Invalid uri syntax: no ? marker however the uri has & parameter separators. Check the uri if its missing a ? marker.
>
>
> Ad 2)
> This is the most serious problem that bites most people. If they have mistyped an optional parameter Camel will ignore it and go on. This can lead to users thinking that Camel runs with that parameter but it does not.
>
> Now Camel barfs and throws a ResolveEndpointFailedException with the list of unknown parameters.
>
> The example from above but with a mistype in the parameter: "timer://foo?delay=250&perid=500"
>
>
> Failed to resolve endpoint: timer://foo?delay=250&perid=500 due to: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: timer://foo?delay=250&perid=500 due to: There are 1 parameters that couldn't be set on the endpoint. Check the uri if the parameters are spelt correctly and that they are properties of the endpoint. Unknown parameters=[{perid=500}]
>
>
> Component Writers
> =================
>
> Only in rare cases your component will not work out-of-the-box with Camel 1.4. In these conditions you need to make sure that you handle the parameters your component support.
>
> Ïf you have code that handles parameters manually by such as: parameters.get("size");
>
> You should get and remove the parameter such as:
> parameters.get("size");
> parameters.remove("size");
>
> or in one-line
> Object size = parameters.remove("size");
>
>
> In Camel 1.4 we have added convenient methods to do this trick; one with a fallback to a default value if the parameter does not exists. This method does also the converTo to the requested type. These methods are added on the DefaultComponent, that most components extend:
>
> public <T> T getAndRemoveParameter(Map parameters, String key, Class<T> type)
>
> public <T> T getAndRemoveParameter(Map parameters, String key, Class<T> type, T defaultValue)
>
>
> Feedback
> ========
> Feedback is most welcome. Any native English speakers could proof read the exception message as I am sure it "smells".
>
> Also I considered naming the methods getAndRemoveParameter just getParameter
>
> And do you some ideas for even better URI validation that Camel should do out-of-the-box please feel free to comment here or on the CAMEL-433.
>
>
>
>
> Med venlig hilsen
>
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
>
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com