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 <[EMAIL PROTECTED]>: > Awesome stuff! I've wanted something like this for a while - great work Claus! > > 2008/5/12 Claus Ibsen <[EMAIL PROTECTED]>: > > > > 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
