camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: camel spring xml restructure
Date Mon, 01 Sep 2008 13:14:46 GMT
Agreed with all that! For 2.0 I'd like to make the IDE completion for
Camel as good as we can make it!

Also worth mentioning is we should have nice XSDs for smart completion
for most of the common endpoint beans. e.g. so folks can do

<jms:endpoint transacted="true" queue="FOO.BAR" connectionFactory="foo"/>

or whatever - to make it easy to have nice smart IDE completion for
creating endpoints/components in Camel


2008/8/30 Claus Ibsen <ci@silverbullet.dk>:
> Hi
>
> I would suggest to restructure the camel spring xml format a bit.
>
> The overall goal is:
> ====================
> - ease of use
>
> Current situations:
> ===================
> - there are too many different types of xml tags possible that confuses end-users.
> - most list types don't have a parent "holder" so they are mixed with all the others
>
>
> IDE auto completion
> ===================
> Using the IDE auto complete reveals many of these problems. For instance in the root
camelContext tag, you get datatypes, endpoint, spring remoting, and other stuff and of course
the routes etc is a bit of mixed content.
>
> I would suggest to restructure the xml so you have some parent holder tags to ease end-users.
>
>
> Motivation behind
> =================
> I would love the spring xml to be more firm and structured before letting loose my programming
team on the spring xml instead of java DSL. Having IDE completion with less mixed type of
elements would help a lot.
>
>
>
> Camel 1.5
> =========
> We are nearly there I think the daatatypes must be restructure so they don't appear in
the tag list from the root tag. Now you get articDS, xmlBeans, string, hl7, xstram and others.
I think they should be child tags of a parent holder tag named dataTypes. This will help a
lot.
>
> I thing this change can be done in camel 1.5 without breaking to much. After all we have
a bug in Camel so datatypes configured as camel tags isn't useable from the marshal and unmarshal
tags. So it doesn't work (CAMEL-871).
>
>
> Camel 2.0
> =========
> For Camel 2.0 we can consider having parent holders for
> - endpoints
> - routes
> - the spring remote stuff
> - jmx
>
> And I also think the <package> tag should have a parent holder that better describes
what it does. As now it's a bit of magic for new users reading the spring xml. Package doesn't
hint that is the route builder and that is it a very important tag. Also we should consider
making it possible to configure <package> as classnames or spring bean ids. So you better
can get the link from camel context to what java class is the actual route builder.
>
> We could consider having a restructure for this and have it something on the way as:
>
> <routeBuilder>
>   <package>com.acme</package>
> </routeBuilder>
>
> Or even better I think:
>
> <routeBuilder>
>   <builder package="com.acme"/>
> </rouyteBuilder>
>
> <routeBuilder>
>   <builder class="com.acme.MyCheeseRoute"/>
>   <builder class="com.acme.MyBeerRoute"/>
> </rouyteBuilder>
>
>
> And the spring ref variation is also very great:
>
> <bean id="cheeseRoute" class="com.acme.MyCheeseRoute"/>
>
> <routeBuilder>
>   <builder ref="cheeseRoute/>
> </rouyteBuilder>
>
>
>
> 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

Mime
View raw message