On 5/1/07, dr.jeff <[EMAIL PROTECTED]> wrote:
It would help to avoid these kind of errors if there was some mechanism in
place to refer to URIs by reference, somewhat in the way that Spring refs
work. If I have:
<!-- constants -->
<bean name="xslt" class="java.lang.String">
<constructor-arg value="./xslt/InputToOutput.xslt"/>
</bean>
then I can do:
<bean id="transformBrook" class="com.syys.camel.interceptor.Transformer"
init-method="init">
<property name="xslt" ref="xslt"/>
</bean>
<bean id="transformTini" class="com.syys.camel.interceptor.Transformer"
init-method="init">
<property name="xslt" ref="xslt"/>
</bean>
...
because I have more than one flow using transformers.
My suggestion is to extend this to the camel-spring.
Yeah, we could definitely have some kinda mechanism like that. Maybe
<camelContext>
<endpoint id="foo" uri="jms:queue:cheese.bar"/>
<endpoint id="bar" uri="jms:queue:cheese.bar"/>
....
<from ref="foo"/>
<to ref="bar"/>
etc
This does complicate the grammar a little in that every uri can be
specified by a "uri" or a "ref" parameter - but this could maybe help
the XML tooling (as hopefully the IDE will understand the type of
'ref' so do smart completion?).
Another option is to allow URIs themselves to be references. e.g. we
could have some kinda way of making an alias to a URI (using some
kinda syntax as above), then we could use a uri of the form
ref:referenceName to refer to it?
<camelContext>
<endpoint id="foo" uri="jms:queue:cheese.bar"/>
<endpoint id="bar" uri="jms:queue:cheese.bar"/>
....
<from uri="ref:foo"
<to uri="ref:bar"/>
The latter is cleaner from the implementation perspective (as we just
need to write a RefComponent to deal with aliases and there's no need
to litter the schema with optional "uri or ref" logic), but maybe the
former is better on the tooling front?
BTW in Java code its easy to do this today
Endpoint foo = endpoint("jms:queue:foo.bar.whanot");
Endpoint bar = endpoint("file:cheese/bar");
from(foo).to(bar);
etc
--
James
-------
http://macstrac.blogspot.com/
